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

[Arthur Flexser]

Interesting results.  Just to clarify, these results are 100% reproducable from
one trial to the next right, so we're not talking about any sort of random
fluctuations?

Art


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