[Coco] "Reading" non-readable bytes with PEEK vs ZBUG

[Darren A.]

>> 
>> I can reproduce this reliably on my 128K CoCo3. So far, nobody else has
>> reported their results.
>> 
>> In all my tests, when a LDB ,X instruction is executed with $FFA0 in X, bits
>> 6-7 of the value loaded into B match bits 6-7 of the next instruction
>> opcode.
>> 
> So, are you saying that it makes no difference whether LDB ,X or LDB 0,X is
> used, because it's the opcode AFTER this instruction that is the critical one,
> rather than the postbyte?
> 
> Art
> 
---

It DOES make a difference. The opcode after the LDB ,X postbyte is providing the 'missing bits' for the value read from $FFA0. This is not the case with LDB 0,X. I think it is due to the fact that LDB 0,X executes in 5 cycles, whereas LDB ,X executes in 4. From reading the cycle-by-cycle flowchart in the 6809 datasheet, the following may be occuring (pure speculation):

LDB ,X
cycle 1: Opcode fetch
cycle 2: Postbyte fetch
cycle 3: Internal processing / read next instruction byte
cycle 4: Load data from effective address

LDB 0,X
cycle 1: Opcode fetch
cycle 2: Postbyte fetch
cycle 3: Internal processing / read next instruction byte
cycle 4: Internal processing / read from address $FFFF  (VMA cycle)
cycle 5: Load data from effective address

With LDB ,X the byte placed on the data bus prior to loading from the effective address is the next instruction's opcode. On a LDB 0,X the prior byte placed on the data bus is the value read from $FFFF (which is $1B on a CoCo 3).

Unfortunately, the ROM in my CoCo 3 is not socketed, so I can't easily replace it with a modified EPROM to see if changing the reset vector at FFFE:FF would produce a different result when executing LDB 0,X.

Darren


_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/