[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