After a two month absence, I can reveal that the CPC2 has another component almost ready for prime time. The past few weeks have been spent writing the Verilog RTL code for the uPD765 floppy disk controller, from scratch. It was one of the more interesting and sophisticated functions that I’ve written. Take a look at this “proof of life”:
Recognise this screen? It’s a little distorted, but it’s getting there!
I managed to create the ‘hardware shim’ that would allow the Verilog RTL to run on my new DE10-Nano. This is the first output from the RTL image. A few problems, but promising!
The screen shot below says it all. Yay! Video output from the CPC2.0!
I promised myself that I wouldn’t post those shaky photos/videos that people seem to post of their game/emulator/screen. Unfortunately, at this time a photo of the screen is the best I can do. Longer term, I’ll get a HDMI capture card from eBay and capture the screens properly, but for now this will have to do as proof of success! Colour bars. Continue reading
I’ve posted the files of my work to date. They’re rough and will need some work if you want to compile them, but it’s working!
Code is posted on GitHub here.
The support software provides a stdio connection to the Atmel supervisor, allowing me to start working on the connection to the video chip and seeing the results in real time. Stay tuned!
Finally, after weeks* of effort I can write about the SPI interface between the Atmel SAM4S supervisor chip and the support CPU in the FPGA. You’ll recall from my last post that I had this working in emulation, but anyone who has worked on FPGAs or RTL code before, a simulation is still a long way from a working configuration. Still, after a bit of work, I managed to get this:
I managed to reliably pass the string ‘ABCD’ (0x41 0x42 0x43 0x44 in hex) across the SPI interface in response to a keypress going from the picocom terminal through the USB serial port of the supervisor chip, passed through the SPI module of the Atmel SAM chip into the FPGA across 4 lines of control and signal, into the soft Z80 CPU. Responding to the incoming data, the software stored in the ‘ROM’ in the supervisor functions would read the transmitted keypress, store it in memory and return ‘ABCD’ across the SPI interface by requesting another transfer from the master. Continue reading
It’s been 2 months since I wrote about setting up the SPI connection between the supervisor and FPGA. That time hasn’t been idle, but I still don’t quite yet have a proven SPI connection. What I do have is a Z80 CPU running a program to exercise the SPI connection in a simulation. Valuable lessons were learned along the way that I hope you’ll find useful. Let’s start with a nice picture of the simulation waveforms!
Simulation Waveform, click for bigger image
As I was explaining to someone recently, bootstrapping a completely new, custom design is hard. There are no tools or pre-existing software to manage the device (Atmel/Altera tools aside). Everything has to be built from scratch. It’s been quite a while since I started this project to get to this point, but I’m getting close now to a workable infrastructure. Once the foundation is in place it will allow rapid development of the CPC portions of this project. Here’s the UI part of the work so far:
It’s been a while since my last post, so I thought it about time I provided an update. I’ve been working on the supervisory software inside the SAM4 microcontroller.
Here are the planned features for this chip:
- Flash management including flash translation layer
- MRAM management
- Provide an interface to the FPGA to access these two memories
- Provide a debug console for both the monitor program and the FPGA
- Provide an upload facility to both the FPGA and to memory
To date, I’ve:
- Written the MRAM interface, using the Atmel ASF libraries to handle the SPI
- Connected and passed traffic between the FPGA and the SAM4 supervisor using the 40MHz SPI interface
- Started the user interface for the monitor program. At the moment, all it shows is one active item to upload the bitstream to the FPGA and several templated inactive items.
- Connected and can read/write the RAW flash layer
Where I’ve gotten bogged down is in the flash translation layer (FTL). Continue reading
Still on a high from my last success, I moved onto testing the FPGA. The only way this would work at the moment, is through the JTAG port. The software that will eventually configure the FPGA through the fast passive parallel port is not ready, and there’s a lot to learn first, so I’m going to leap frog that and use the JTAG port to configure the FPGA to get the LED to blink.
Just like this :