[Coco] CoCo 3 display offset question.

[jdaggett at gate.net]

On 14 Sep 2006 at 21:14, William Astle wrote:

> jdaggett at gate.net wrote:
> > The registers (Vertical offset) at $FF9D and $FF9E are affected by the COCO bit. 
> > Bits#7,6, and 5 of $FF9D should be set to "one" when the Coco bit is set. There is 
> > the no hard requirements that they need to be. Not doing so is the at progammers 
> > own risk. The rest of the bits in the register at $FF0D and the upper two bits of 
> > $FF9E are mapped to $FFC6 to $FFD3. Setting the lower 6 bits of $FF9E other 
> > than "zero" is at the programmer's risk. 
> > 
> > 
> > Yes if you take the 19 bit address and divide by 8 you get a 16 bit or two byte 
> > code that is programmed into the registers at $FF9D and $FF9E. Division by 8 is 
> > simply a shift right three times and ignore any carry. Register $FF9C is the 
> > vertical scroll register.  
> 
> I would think the "risk" to the programmer is confusion more than 
> anything since it would make sense that the GIME actually uses the same 
> circuitry to identify the starting address of the screen regardless of 
> the COCO bit. After all, it would hardly be "COCO Compatible" if the 
> screen didn't map into the CPU's 64K memory map as expected or if it 
> were offset by some number of bytes. So it would seem to me that if the 
> programmer were doing so intentionally and understood the expected 
> result, there would be no problem with doing so. (Of course, it would be 
> fundamentally incompatible with the BASIC ROM then.)
> 
> Quite frankly, though, I don't see the need to do that. After all, if 
> you're futzing at that level, you might as well drop the COCO bit and 
> use the GIME fully. About the only thing where I could see this being 
> vaguely useful is if one were trying to run multiple versions of a COCO2 
> style BASIC ROM, each having it's memory in a 64K "segment". Then 
> adjusting the high order bits of the vertical offset register might make 
> sense. But, really, why would we need to do that? :)
> 
***********************
William 

By "risk" I mean that while a function on teh GIME chip may work, it may  not be supported 
by the chip maker officially. Kind of like a feature that was not intended but due to the way 
the chip was designed it does work. 


james