[Coco] Strange results reading the palette registers on Coco3

[William Astle]

On 11-12-05 05:51 PM, Arthur Flexser wrote:
> Are you using a 6809?  I expect a 6309 might possibly behave
> differently in some respects from a 6809 with regard to this weird
> stuff.

I can see some variation between the 6309 and 6809 here because the 6309 
prefetches the next opcode while processing the current instruction (in 
native mode anyway). Thus, I would expect that on a 6309 in native mode, 
all cases will have bits 6&7 come from the next opcode since that will 
be the data on the bus (no VMA cycle in that case). Without the 
prefetch, though, I would expect the behaviour to be identical to the 
6809 case.

It's better to treat those bits as completely undefined since then any 
variation in CPU implementation will not cause bugs. Also, variations in 
the device/bus implementations then cannot make any latent bugs appear.

Quite frankly, the check in LOADM (it's in CLOADM too) is dumb. The 
theory was to give the user feedback when they loaded a binary somewhere 
that is not RAM, but, quite frankly, it serves no useful purpose.

>
> 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
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>