Well, my capture card arrived! No more shaky video. Here’s the current state of my CPC2.0. I’ve faked a keyboard to type in |m,1 to start the Arnor disassembler.
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
Since my last post, I’ve been beavering away on the SPI interface between the Atmel supervisor chip and the FPGA. The SPI interface is almost ready to share, but not quite. In the meantime, I’ll share the little side project I’ve been working on, replacing the NAND raw flash with an eMMC chip on the CPC2.0 board.
I wrote about raw flash and the challenges of writing a flash translation later in part 16 of this series. After some research, I concluded that the eMMC interface looked exactly like the much more common SDCard interface, albeit that the interface can be run with an 8-bit width. SDCards are limited to 4 bits by the physical pin count. Taking a gamble I created a board to test this new eMMC chip. I created a fake SDCard!
This fake card allowed me to check very quickly if my assumptions were correct both at a hardware and a firmware level. I wanted to be sure that it was possible to interface the eMMC via 4 bits, rather than the full 8 bits and be sure the firmware instructions were the same between these two technologies.
The Atmel SAM4S chip has a hardware interface for SDCards. If the eMMC worked with the SDCard interface, I just needed to hook up the eMMC to the Atmel SAM4S chip using the built-in HSMCI interface. I could then use the libraries provided in the Atmel Software Framework to interface to the card. No effort required and definitely no flash translation layer required!