That’s good to see! I do encourage you to release your HDL source too.
1 Like
Today I ported a Tiny Basic to the x820.
1 Like
Here’s a Pi calculation benchmark running on the x820 
The 90 seconds is misleading because it includes all the serial I/O time.
Edit: I did a test and the I/O takes less than a second, so I can’t blame I/O…
The Pi algorithm does lots of 32-bit divisions which is pretty slow on an 8-bit CPU.
2 Likes
Nicely done! One of my favourite numbers. I like this bit especially:
1 Like
Really really close … With 32-bit integer arithmetic, this algorithm can accurately compute up to 9674 digits of Pi. I haven’t tried that though. My main purpose for porting and running this calculation is as another z80 compatibility test.
Are you familiar with the work on this page - source for a Z80 pi spigot can be found within, which might contain some interesting ideas.
Congratulations indeed! I don’t think I’ve ever managed to touch down safely in one of these! (The graphical ones, I have.)
Speaking of “retro” lunar lander.
My friend used to play this game.
It was written in Fortran. And it was a card deck. You’d run it and just keep adding burn cards to it and run it again.
Thankfully, the college paid for the computer paper.
Hi Everyone,
The most challenging part of this project has been testing and validation. I have written or ported several test and demo programs, and I am overall happy with the current level of functionality and compatibility but the project could still use more testing and validation. If anyone wants to help/collaborate on writing or porting tests or demo programs, please let me know.
Thanks,
I’d be kind of interested in what bugs remain after passing ZXDOC - I dare say there could be some, and yet, what might they be?
I mostly use 6502, myself. I do run z80 in an Acorn second processor context, where I’m most likely to run BBC Basic - that might be worth porting - and then there’s CP/M, for which I have a small collection of games and applications but no great familiarity with them.
Are you running CP/M, or loading programs directly from your monitor?
Hi Ed,
At this point I have not run the full zexdoc test. That’s one area I could use some help with. I made a number of hacks to the zexdoc source (mainly I expanded the macros using a Perl script pre-processor) so it would assemble with my assembler. A set of CRC-based tests have been run (and passed) as well as other tests that I have written or ported. I also have written or ported several demo programs including Palo Alto Basic. I have not tried porting BBC Basic. I have also not tried getting CP/M to run, mainly because I do not have a convenient way to attach mass storage. I load all programs via a monitor program-load command which reads hex files over the serial/console connection.
1 Like
I have all of the zexdoc tests passing except for the daa test. I have done extensive testing of the daa instruction with other test suites and they all pass, so I don’t know what zexdoc is doing differently. (Note: zexdoc bundles daa with cpl,scf, and ccf but those are very simple instructions so I’m assuming the problem is in daa. I don’t currently have an assembler that will assemble zexdoc, so I can’t modify it to test that assumption.)
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.