In an earlier post, I described how I can now load software on to the Zolatron 64 6502 homebrew computer. The LOAD command was pretty basic – you couldn’t specify a file. Instead it just loaded the same file (zd.bin) which I’d have to overwrite if I wanted to load different code.
Well, those days are over, and the Zolatron 64 (Z64) now has a proper LOAD command.
The method uses a Raspberry Pi Zero 2 W as persistent storage, connecting via its GPIO pins to a 65C22 VIA board on the Z64
I develop user code for the machine on my Macs, using VS Code. A script assembles the 6502 assembler source into binary code and uploads it (using SCP) to the Raspberry Pi – named Imp.
The files on the Imp all end with ‘.BIN’. But to save typing, in order to load, say, TESTA.BIN on to the Z64 I simply type: LOAD TESTA into the terminal connected to the Z64. This feels more like a real disk operating system (which is why I call it, somewhat ambitiously, ZolaDOS).
The process is necessarily more complex now. The Z64 initiates it by taking the /CA line low (it was called /INIT in an earlier incarnation, but it is more multi-function now). It loads a process code on the data bus (the value 8 for a LOAD operation) and takes the /CR line low. The Raspberry Pi server takes this as a hint to read the code and acknowledges that it has done so.
That much is the same as before. But now there’s an extra step in which the Z64 sends the desired filename. This is done byte-by-byte over the data bus with the end of the sending process being indicated by the Z64 taking the /CA line high (inactive).
Control then largely passes to the server. The Raspberry Pi checks to see if a file of that name exists in its ‘files for the Z64’ folder (actually called zd_files). It sends a response code – 0 for success, with anything else being an error code).
Then the Raspberry Pi starts sending the file contents, byte-by-byte.
The whole process is encapsulated here. Note that is this is not a timing diagram, so the horizontal axis is not to scale.
It breaks down into four stages, which is handy because I’ve been able to modularise these. Each is handled by individual subroutines/functions in both the 6502 assembler code on the Z64 (check out the ‘unstable’ branch for the most recent version) and the Go code on the Raspberry Pi.
I’ve also implemented an LS command, in vague emulation of the *nix version, to provide a list of available files. That’s all it does – no other file information – but it’s handy all the same.
The ZolaDOS program running on the Raspberry Pi is now a bit more informative and, after a file is loaded, tells me how many bytes were sent. And I now have a slightly longer file to play with – the early stages of a game called ‘Hunt the Zumpus’ (more on that soon). Using my logic analyser, I can see that the 1223 bytes of the current Zumpus file took 2.6 secs to transfer – a rate of 474 bytes/sec. That’s pretty much what I’d estimated from earlier observations. It’s not blisteringly fast, but it works.
And having got to this point, I’ve achieved many of the things I set out to do with this project. It was never about creating a usable machine. It was about learning – stuff like memory addressing, controlling peripherals, assembly langauge coding and more.
That said, the Zolatron 64 journey doesn’t end here. I’m working on a printer board, a dedicated plug-in board to house the Raspberry Pi Zero and more user code.
This is how my environment looks now.
I don’t even have to be in the same room as the Z64 to work on it. I code on my MacBook Air, upload that code to the Imp and also SSH to the Imp to run a terminal session with the Z64, all from the comfort of my sofa. I’ve even implemented a reset command in the terminal program that causes the Z64 to do a hard reset, just in case my Z64 software crashes and freezes the machine, or goes into an infinite loop.
Now for a game…