Current status of zeST
I’m taking profit from this new website to summarize the current status of the zeST project.
The zeST project is based on the Xilinx Zynq-7000 family of FPGA-based SoCs, with a FPGA, a two-core 32-bit ARM CPU, and a number of hardware controllers, all that in a single chip.
For the moment, I am working on a MyIR Z-Turn board, whose availability seems to be decreasing with time, so I’m looking for a replacement board that would serve as the new reference board.
I am currently investigating another family of Zynq 7000-based boards, the Microphase Z7 lite that seems to be only available on AliExpress (no website, no European reseller found). I have ordered one, so we know soon enough if it’s suitable for our needs. If I am successful, this board would be a better choice than the Z-Turn board, as it is cheaper and apparently with better availability and other advantages, like a USB host port which does not require an adapter, directly-accessible GPIO pins or an integrated JTAG platform cable interface, very useful for FPGA developers.
So far, all the components of a ST have been implemented. They work at different levels of accuracy wrt. the original hardware. Further work is necessary to improve the compatibility.
The whole zeST project has been developed around Ijor’s fx68k open-source cycle-accurate implementation of the MC68000 processor. This implementation is meant to be undistinguishable from the original chip, so it is by design the most compatible version of a 68000 processor we can get.
For now, video display is just compatible enough to allow simple color effects like rasters, but don’t expect anything fancy about full screen effects or hardware scrolling. There is ongoing work to make that part more compatible with the original hardware.
The current implementation of the YM2149 is one of the most recently implemented parts, but it does sound good already. It was designed to be as simple as possible, like the original chip was designed. It is accurate enough to make digisound code work as good as on the original hardware. Heavy tests are still necessary. What’s unknown yet, is how it behaves with those new CPU/YM effects that are currently being experimented by some crazy YM enthousiasts.
As many peripherals, keyboard is handled partly by hardware on the FPGA, and partly by software on the Arm CPU in the chip.
The hardware part contains exactly what is in the original ST keyboard : the HD6301 chip with its integrated serial interface to the ST mainboard, the key switch matrix, and the mouse and joystick “connectors”. I replaced each of the original mechanical contact switches with one binary (on/off) input signal, and a logic gate that performs the same matrix connection as the switch. All the input signals for the keys and the mouse/joystick connectors are made accessible to the CPU.
The software part waits for key presses and releases from the USB keyboard, or mouse or joystick events and enables and disables the input signals accordingly.
This clearly introduces at least a bit of delay between the keyboard/mouse/joystick events, but the general feeling does remain quite the same as the original.
Floppy disk drive
Just like the keyboard, the floppy drive is composed of one part in hardware and one part in software. The hardware part provides the same interface as that which is made available on the connector of a real floppy drive. It makes it possible to connect to the WD1772 floppy controller that was reimplemented for the occasion. The “only” difference between the real and reimplemented versions are that the FPGA version spins at a perfect rotating speed of 300 rpm, while the original always fluctuates within a interval around this theoretical speed. This makes the reimplementation of the WD1772 a lot simpler as well, but it has the drawback that it will not be possible to reproduce some types of floppy copy protections for instance.
The problem here is that motor speed variation is a very analog behavior, and WD1772 is in charge of taking that into account when converting the analog signal coming from the floppy drive at imprecise speeds, to a stream of bytes that can be processed by a fully-digital architecture. Implementing this on a FPGA, if not impossible, would be a very tricky part because FPGAs are fully digital and synchronous.
On the software side, floppies are managed as image files, and the CPU is responsible for exchanging small blocks of data between the hardware part and the image file. For the moment, only images in raw track format are supported, but it will not be difficult to fully support files in MSA or ST formats.
There seems to be occasional losses of data between the CPU and FPGA. In general this is not a problem, because the WD1772 controller performs sanity checks to ensure all the data are correct, and can decide to read a sector again if a previous read resulted in an error.
However, on some circumstances, some demos or games read the floppy data using a specific WD1772 command named “read track”, that completely disables the sanity checks, leading to a need for improving the fiability of floppy data transfers.
For the moment, there is no user interface for choosing settings, selecting floppy images, etc. zeST is booted using a setup program that runs on Linux, on the CPU side, from the command line on the serial port. Of course, user friendlyness requires to auto run the setup program at power on, and to properly implement a setup menu to avoid the user the need to deal with the command line at all.
That’s all for now
I’ve presented a very rough overview of the current status of the project. I didn’t go into much of detail concerning the internal components, synchronization between them, and so on. There is a lot more to say about that; that will be the subject of further posts on this website.
I will also post updates on my progress on the development.
If you don’t want to miss any updates in the future, you can follow my Twitter account.
For any questions, comments, don’t hesitate to reply to the dedicated post on Twitter.