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!
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:
To date, I’ve:
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 :
Yes, you read that correctly. I managed to get the board working from my last post. Lucky post 13! I removed the SDRAM chip and the short between GND and the 3.3v line disappeared. Perplexed, I re-checked the data sheet and yes, I’d made a mistake. There are three VCC and three VSS pins. I’d transposed the last two of these. Ah well. This board was never going be the final build anyway, so I just removed the SDRAM chip with my hot air hand tools.
The regulators and inductors were still running hot, so I suspected there was a further issue, but the LED was alight now, which was a good sign. The voltages out of the regulators were a bit low, so I checked some key components, such as the clocks and lo-and-behold, I’d placed the 50MHz oscillator at 90 degrees out. These chips are 2mmx3mm, so excuse this minor fault. I removed the oscillator and the line voltages returned to tolerance and the heat in the regs and inductors went away. Woohoo!
I soldered on the JTAG port for my Atmel-ICE programmer and programmed an initial hello world program. I upped the PLL so that the ARM core ran at 120MHz and it was quite stable. If you switch from low speed to maximum clock it sucks a huge gulp of power from the supply lines, so if the regs, inductors and noise suppression capacitors are not sufficient the core self-resets. I didn’t see any behaviour like that, so I’m confident the Atmel SAM core is good.
I also found a few other stupid mistakes, like I’d provided a jumper to erase the ARM microcontroller, but jumpered it to ground and it needs +3.3v to erase. I also managed to set the security bit while fiddling with the programmer, so I was locked out of the chip. Luckily, the Atmel-ICE cable has two connectors, both a 0.05″ and a 0.1″ pitch connector. So I took 3.3v from this ribbon connector and zapped the erase pin during power up and wiped the security bit, allowing me back into the chip programming mode.
I wrote a quick program to toggle the FPGA configuration lines and managed to get an acknowledgement level-shift on the status line, so all good so far! I tried to get a fault condition, by sending zeros and all-ones to the FPGA, but couldn’t elicit a fault response, so I suspect it’s waiting for specific value before it starts it’s configuration process.
As I write this, I’m installing Altera Quartus on my new HP all-in-one, so that I can create a bitstream simply to turn off the LED (it defaults to on) and see the CONF_DONE line go high. That’s probably some way away, but I thought it worthwhile to report this success after another apparent failure.
I’ll be able to test the other components on this build, so it’s not a waste and I’ll perfect the supervisor programming software and test the remaining components before the next build.
Stay tuned for my next post!
Welcome back to the next part of this retro adventure. Last time, I told you the new boards are back from the fabrication house. These are the same logical design (called schematic) as the previous boards, but use a different and simplified layout and I’ve removed some components to make the assembly easier. I also changed my assembly approach.
I’m pleased to say I had a 50% success rate, which is 49% better than last time! The board assembled beautifully.
Unfortunately, I still have some problems but let’s go through the new assembly process before we go further. As I mentioned last time, I intended to assemble the board using a dry layout process first. This means I can take all the time I need to get the components out of their packaging and lay them out on the board and not worry about whether the solder paste is going off. Continue reading