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!
I unboxed the Terasic DE10-Nano! What a great bit of kit for a bargain price of $130! Nice going Terasic – you build some amazing stuff. I couldn’t buy the components for that price! Here it is, plugged into my development box.
The cables are (anti-clockwise from 11), 5V/2A power from the power brick, USB Blaster connection, Ethernet plugged direct into my dev box (no crossover or switch), FTDI UART console.
There are two images available from the Terasic site, an Ubuntu image with full LXDE GUI, or a console image. I started with the Ubuntu image, just because it had a great ControlPanel App to show linkage to the DE10.
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
Developing a complex embedded system like the CPC2.0 from scratch is a series of massive achievements in miniature, like a nano-scale thunderstorm. Huge steps forward are represented by a signal line going high, or a chip outputting a short sequence of bits, proving the framework of everything built to date. This project is just like that, so it’s tough to explain to people that those few numbers on the screen represent thousands of hours of coding in C, RTL and hardware design to get a coded sequence out of the HDMI chip. There can be a lot of effort behind a blinky LED.
So, to make it a more interesting post, I thought I’d start with this:
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