I realized that the last post on this project was nearly two months ago, so here’s an update.
The project is still alive! I’ve had other projects that took some time away from me for the time being.
I have performed some more hardware testing on the Z80 SBC using AttoBASIC. I wrote a small Z80 program and loaded it into RAM for the Z80 to run and it works as expected. The program is simple, stuff some bytes to the AVR’s I/O port address and do the same for the 82C55’s I/O port address. The intention was to be able to test the I/O port decoding in the ATF16V8 PLD and test the programmable wait-state generator, which is triggered by the Z80’s access to the AVR’s I/O address. These functions work as expected and I will post on that later.
Meanwhile, I am still mulling over which software development method to use for the AVR host. Although I have written code for one project in “C”, I am not “C” fluent, thus I am leaning towards pure assembly language, which I am quite comfortable developing in. Even so, there are some pros and cons to using “C” or ASM.
- Not fluent, thus steep learning curve (again) to implement and comprehend the nuances of “C” on the AVR.
- SDcard library is written in “C”, so easier to interface with.
- DS3231 RTC library is written in “C”, so easier to interface with.
- Very fluent, no learning curve.
- Can use AttoBASIC as a starting point but that requires deletion of most commands, addition of Z80-specific commands and modification to some of the existing commands, including support for 16-bit numbers as parameters. I have already done this for another project and it supports 32-bit numbers as parameters to the commands. Still, its a bit of a task and I would not merge this into the AttoBASIC source code.
- Interface to the SDcard library requires reverse engineering the resulting ASM code, determining library API absolute addresses and the absolute locations of data in RAM. I’ve done this before BUT the SDcard library uses a lot of local variables and internal management.
- Interface to the DS3231 library requires reverse engineering the resulting ASM code, determining library API absolute addresses and the absolute locations of data in RAM. However, the DS3231 interface is simple enough that it would be easier to write my own code for it.
So that’s it in a nutshell.
Stay tuned as I am making progress.
Peace and blessings.