[Coco] Strange results reading the palette registers on Coco3

[Arthur Flexser]

The way this works for the undefined bits is more than  little
bizarre, (though definitely NOT random) and was a topic of discussion
here about 2 years ago.  Here's a message I saved from back then, with
the detailed reply by Darren A.:

On 1/18/10, Arthur Flexser wrote:
> Care to explain in more detail why the reset vector (on a read CoCo) would
> affect it?  I understand that the value the palette register returns for
> bits 6 and 7 depends on some register contents at the time it is read, but
> beyond that I'm a bit vague....
>

---

Whenever you read from an un-mapped hardware address or from an
address where some of the bits are undefined (like the GIME's palette
and MMU registers), the value obtained for those undefined bits is
predictable on the CoCo.

There are two possibilites which depend on the addressing mode you use
to read from such an address.  If you use the "no-offset" indexed mode
(as in LDA ,X) the undefined bits will come from the first byte of the
next instruction.  For any other addressing mode, the undefined bits
will come from the byte at $FFFF (LSB of the Reset vector).

When you use BASIC's PEEK command to read from an un-mapped address
(such as $FF70), you get a value of 126.  This is because PEEK reads
the address with a LDA ,X instruction, so the value returned is the
opcode of the next instruction (JMP Extended = $7E = 126).  If you
patch the PEEK command to use a 5-bit offset (LDA 0,X), the value
returned for an un-mapped address will instead come from $FFFF (27 on
a CoCo 3 or 39 on a CoCo 1/2).

The reason for this behavior is that the 6809 normally does a VMA
cycle just before reading the instruction's effective address. The
exception is the "no-offset" indexed mode in which case the next
instruction byte is read just prior to the effective address.  During
a VMA cycle the address bus goes to Hi Impedance and the R/W line is
HI.  This has the effect of loading the value from $FFFF onto the data
bus.  This stale data from the previous cycle supplies the value for
the undefined bits.

Here is a small routine which will demonstrate this behavior:

  ldx   #$FF70
  lda   ,x
  ldb   $FF70
  std   $400
  rts

On a CoCo 3, you should end up with the value $F61B at $400-401.  On a
CoCo 1/2 you should get $F627 instead.

On Sun, Dec 4, 2011 at 11:08 PM, Robert Gault <robert.gault at att.net> wrote:
> Has anyone seen this on their own systems?
> Coco3 with or without MPI, with or without disk controller
> POKE&HFFB0,0:PRINT PEEK(&HFFB0)
> result is $40
> POKE&HFFB0,255:PRINT PEEK(&HFFB0)
> result is $7F
>
> However if memory is read with an ml program, the result is different.
>
> START   CLRA
>        STA     $FFB0
>        LDB     $FFB0
>        LDA     #255
>        STA     $FFB0
>        LDA     $FFB0
>        STD     DATA
>        RTS
> DATA    RMB     2
>        END     START
>
> If the above is run with appropriate values for DATA and from Basic you:
> PRINT PEEK(DATA), PEEK(DATA+1)
> the result is $3F and 0.
>
> Just to confuse matters more:
> LPOKE&HFFB0,0:PRINT LPEEK(&HFFB0)
> result is 0
> LPOKE&HFFB0,255:LPEEK(&HFFB0)
> result is 255
>
> No matter how you look at this, something is very wrong.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco