After some more macro pre-processing, I now have a version of zexdoc that my assembler is happy with, so now I can try to narrow down the daa issue.
2 Likes
Curious what you find out. I looked at that thing, and boy, is it opaque.
Hi Will
Here is an example of a test descriptor with macros:
; hl, (38,912 cycles)
adc16: db 0c7h ; flag mask
tstr <0edh,042h>,0832ch,04f88h,0f22bh,0b339h,07e1fh,01563h,0d3h,089h,0465eh
tstr <0,038h>,0,0,0,0f821h,0,0,0,0,0 ; (1024 cycles)
tstr 0,0,0,0,-1,-1,-1,0d7h,0,-1 ; (38 cycles)
db 0f8h,0b4h,0eah,0a9h ; expected crc
tmsg ' hl,'
and here is the a test descriptor with macros expanded:
; hl, (38,912 cycles)
adc16: db 0c7h ; flag mask
db 0edh,042h,0,0
dw 0832ch,04f88h,0f22bh,0b339h,07e1fh,01563h
db 0d3h
db 089h
dw 0465eh
db 0,038h,0,0 ; (1024 cycles)
dw 0,0,0,0f821h,0,0
db 0
db 0
dw 0
db 0,0,0,0 ; (38 cycles)
dw 0,0,0,-1,-1,-1
db 0d7h
db 0
dw -1
db 0f8h,0b4h,0eah,0a9h ; expected crc
db ' hl,'
db '....$'
Yea, thanks, I appreciate that, but I didnāt see (and I didnāt study it in any detail for any length of time) a basic theory of operations. It seems that it takes each group of instructions and somehow iterates through several generations of them, and then CRCs the results they generate. But itās not clear to me how the environment is manifest for each instruction thatās being iterated against.
Hi Will,
There is some info here that I found useful:
http://jeffavery.ca/computers/macintosh_z80exerciser.html
1 Like
I modified zexdoc to split out the <daa,cpl,scf, and ccf> test into 4 separate tests and I then discovered that daa was not the problem after all. The problem was with the ccf instruction which has a very weird flag side effect. In addition to complementing the C flag, the H flag is set to the old C flag value. After making this change to the Verilog, all of the zexdoc tests are now passing. WooHoo !!
3 Likes
I guess that explains why itās in the same test group as DAA! Very interesting conclusion, thanks for bringing us along.