[Coco] "Reading" non-readable bytes with PEEK vs ZBUG
Robert Gault
robert.gault at worldnet.att.net
Tue Jan 22 07:56:09 EST 2008
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.
More information about the Coco
mailing list