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

[jdaggett at gate.net]

On 22 Jan 2008 at 16:11, Darren A. wrote:

> 
> >> 
> >> 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)

No read. Address buss is tri-stated that is why $FFFF.

AVMA is a signal that tells a peripheral processor that the CPU will use the buss after the 
current cycle is completed. 
> cycle 5: Load data from effective address

LDB 0,X on the last two cycles loads the X register one byte at a time into the ALU along 
with the data from the post byte and adds the two together. The result is then latched to the 
EA register and then to the address buss on the last instruction cycle, #5.

> 
> 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.
> 

On the coco 3 I believe $FFFF will be $27. That should not be your problem. 

try studting the GIME chip and the sch ematic a bit more. I still think it is the GIME chip. 
Changing the code by entering a NOP or changing the instructions is curing a problem in the 
GIME chip.


james