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

[jdaggett at gate.net]

On 22 Jan 2008 at 7:56, Robert Gault wrote:

> The last message in the original thread suggested that ZBUG (or
> EDTASM) might have introduced errors in reading non or partially
> readable bytes such as the MMUs. That does not seem to be the case as
> you can see from the following test.
> 
> Source code
>                org $E00
>                rmb  2
>         start  ldx #$FFA0
> E6 00         ldb  0,x
> A6 84         lda   ,x
> FD 0E 00      std  $E00
>                rts
>                end  start
> 
> This was assembled and run from Basic, not used under EDTASM control.
> 
> Results
> ?PEEK(&HE00)
> 248                ie. $F8
> ?PEEK(&HE01)
> 56                 ie. $38
> 
> Source code #2
>                org $E00
>                rmb  2
>         start  ldx #$FFA0
> E6 84         ldb   ,x
> A6 84         lda   ,x
> FD 0E 00      std  $E00
>                rts
>                end  start
> 
> Results
> ?PEEK(&HE00)
> 248                ie. $F8
> ?PEEK(&HE01)
> 184                ie. $B8
>
> Source code #3
>                org $E00
>                rmb  2
>         start  ldx #$FFA0
> E6 00         ldb  0,x
> A6 84         lda   ,x
> 12            nop
> FD 0E 00      std  $E00
>                rts
>                end  start
> 
> Results
> ?PEEK(&HE00)
> 56                 ie. $38
> ?PEEK(&HE01)
> 56                 ie. $38
> 


This suggests that the corruption occurs external to the CPU, as I suspected, and that the 
CPU is reading in the wrong data. If the contents of the accumaltors is changing with the 
next cycle data, then the 6809 has a major major major major flaw. This should have been 
detected decades ago in regression testing. The chip has been in production from 1979 to 
1999. Motorola sold million s of these chips and this errata should have been caught in 
service. 



>   EDTASM does generate correct code or very few if any of our
>   assembled
> programs would run correctly. The above was run from Basic so ZBUG was
> not involved. The results were changed by both the byte preceding the
> Load instruction and that following the Load instruction. In fact, ex.
> #3 had both preceding Loads changed by the first post byte.
>   It is a good thing that this only happens when reading non or 
> partially readable bytes or one could not write code using the
> 6809/6309 cpu.
> 

Agreed that the assembler is producing the correct code and the CPU is operating per 
specification. 

> What this means I'll leave up to the hardware guys. Note that the msn
> gets changed but not the lsn of the info read from $FFA0. Installed
> memory for the tested Coco is 512K so $FFA0 bits 6&7 are not
> meaningful. Above we have seen these bits filled in with 11, 10, and
> 00. There probably is code that sees the bits filled with 01.

What it means is that the value of the floating bits internal to the GIME are being 
determined by the next byte read into the GIME chip. This means the corruption is the 
taking place inside the GIME chip and not the 6809. The only mechanism that now makes 
sense.

james