I have blogged in the past. Here's an archive mirror of my old site:
http://www.russelldavis.org/CamputersLynx/PALE/
But I have been told I don't blog enough.
In part this is now due to medical issues (so please excuse any small typos herein) but mostly it's due to me being pretty introverted (apart from the circus persona). Maybe also I just don't report on 'almost there' projects, of which like many engineers I have nnnn or so (where nnnn is base-16).
I will try harder.
Here is a blog about olde Camputers Lynx Z80 interfacing to a modern ESP32 microcontroller.
oh, btw I'm not known for waffle.
So to start, the Camputers Lynx from 1982- is a Z80 based UK micro with a range of addons icluding a 1793 based disk drive.
Camputers Lynx 128 from 1983
The floppy disk controller comes in two parts - an EPROM expansion box and the green FDC board which usually lives in the first drive of the system. Here it is hooked up to an HxC floppy emulation device.
The original Camputers disk drives for the machine
I programmed an emulator for this system back in 2004 including the FDC 1793 disk controller.
It's called PALE, you can get it from Russ's site:
http://www.russelldavis.org/CamputersLynx/PALE/
The sourcecode for PALE (on many platforms) is here along with some other ZX Spectrum related code.
https://github.com/retrogubbins
At the time I had a debug version just using a big array disk[200kBytes] in RAM for a disk.
So recently I thought maybe I can run this code to emulate the Lynx disk chain using an ESP32. Plus all the other things the ESP brings to the banquet.
The Lynx (Z80) bus is presented as the expansion bus as a 40-way connector. The address bus is multiplexed down to 8 bits in a particularly convoluted fashion... which I won't bore you with.
So I need to emulate a range of ports from 0x50-0x58 which are the original Lynx FDC port addresses.
The internal FDC emulation brought over from the PALE emulator emulates these commands:
I will not emulate the disk ROM itself at present though I have tried this and it seems workable within the refresh constraints.
But as is usual in these projects I need ns timing where us is the norm (unless you are into Parallax Propeller or Pi Pico more later...)
So. How to link up an 80's micro with the (relatively slow) ESP32.
Here's the plan of action...
Don't try catching IOREQ drop, instead use the original LS TTL hardware (there's a reason for this later to do with the HH Tiger.. stay tuned).
From this decode we can apply /WAIT and then take as much time on the ESP side as we like (subject to dynamic refresh requirements.. !)
1. For Z80 port writes
a) the esp seems able to keep up with this without WAIT
b) but I use it anyway and clear it after I read the Z80 bus with the ESP input pins
2. For Z80 port reads
Use a trick I saw somewhere with BUSREQ (on the EEVBlog forums).
a) drop WAIT on addressed IO space
b) service IO request (including decoding of the 16 ports in the 0x5x address space)
c) enable output latches to send data to the Z80 (and change direction of ESP32 data pins to output)
d) drop BUSREQ
e) clear the WAIT condition - but Z80 runs into the BUSREQ so stays in the current instruction)
f) re-arrange the ESP32 data bus pine as inputs
g) stop the output buffers on the ESP32
h) clear BUSREQ
*in the actual code I abuse a lot of the order due to time constraints and hardcoded delays.
With Byte-banging from the ESP32 side this yields a robust 66kBps ESP->Z80 transfer rate. Or YNXVADERS (3kB) loaded in around 1/10th of a second versus ?a minute over tape. It peaks at near 200kBps for known txfers.
Here's the big-mess-of-wires on the bench:
In the next post - Schemas and Code...
http://www.retrogubbins.co.uk/2-uncategorised/5-thegolem
