[Coco] CoCo 3 display offset question.
jdaggett at gate.net
jdaggett at gate.net
Fri Sep 15 08:20:56 EDT 2006
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? :)
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.
More information about the Coco