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

[jdaggett at gate.net]

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

> I am no hardware expert, but it seems to me that this would infer that
> the next instruction opcode is appearing on the data bus prior to the
> read of $FFA0. Is it possible that the 6809 does a "look ahead" when
> executing an indexed instruction with a zero-displacement postbye?
> Something like:
> 
> Cycle 1:  Fetch LDB opcode
> Cycle 2:  Fetch Indexing postbyte
> Cycle 3:  Peek at the next instruction byte
> Cycle 4:  Read data from [X]
> 
> Darren

The 6809 does prcalculate the next address but I am not certain that is an issue here. 
	
I am a hardware engineer and I have spent numerous years in the failure analysis on 
hardware and software. I have extensive experience using Motorola processors from the 
6809, the 68HC05, and the 68HC11. 

Data must be present on the data buss and stable 40nS prior to the falling edge of the E 
Clock at 2 MHz buss rate. The address for the next instruction is not placed on the address 
buss until 100nS after the falling edge of the E Clock in the cycle that the data was read. 
The data has to be corrupted prior to being latched in and the major culprit is the GIME 
Chip. 

I refuse to believe that the data loaded into the accumalator is being corrupted by a load to 
the instruction register on a following machine cycle. As I stated in a earlier post if this is 
true then it is a major major major issue and should have been caught decdaes ago.  I 
still believe the data is being corrupted external to the CPU and is being clocked in on the 
falling edge of the E clock. 

The GIME chip does a double byte read, even then odd address. Depending on the state of 
the A0 line the odd or even byte is latched to the CPU data buss. There in probably lies the 
problem. The GIME chip floats the two highest bits from the MMU register and the 
corruption may occur then the GIME chip dumps the register data to the cpu data buss and  
previous data is there.

james