[Coco] Strange results reading the palette registers on Coco3

[Arthur Flexser]

Actually, that result seems perfectly in accord with Darren's
explanation:  when using the ,X indexed mode to read the palette
address, the undefined bits get taken from the opcode of the following
instruction, the BEQ.  If memory serves, this family of branch
instructions have opcodes of $2x, which means bits 6 and 7 are zero,
just as you found.

Art

On Mon, Dec 5, 2011 at 4:54 PM, Robert Gault <robert.gault at att.net> wrote:
> Art, that's a very interesting explanation but testing indicates additional
> results with different code. One critical section of code, is that which
> runs during LOADM. I've a CER-COMP program which sets the palette registers
> during the LOADM process and part of the Disk ROM checks to see if the
> process was successful.
>
> Disk 1.1
> $D004   sta     ,x
>        cmpa    ,x+
>        beq     $D00D
>        jmp     I/O error on bad store
>
> When regX=$FFBn, the result becomes contentX&$3F. That is bits 6&7 are
> ignored and effective values range from 0-$3F.
> This is somewhat different from the result quoted in your message.
>
> Anyway, the main point is that recent changes to the MESS source code had an
> effect on how the palette registers were read. Programs like my CER-COMP
> program stopped loading with an I/O error because the comparison above
> failed.
>
> Looks like there is no practical way to fully emulate the Coco3 hardware in
> emulators regards un-mapped bits or bytes.
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco