I recently came across some very interesting one-line programs, which generate some primitive music from simple logic expressions – a genre which has come to be known as “bytebeat”.
Being in need of a pointless-but-fun project requiring little to no concentration, I immediately wanted to play with these programs. Implementing the logic directly in an FPGA would be perfectly possible, but I actually chose not to this time – instead I wanted to compile them for the EightThirtyTwo CPU and run the sound through the four-channel DMA sound “chip” contained in EightThirtyTwoDemos (modeled very much after the Amiga’s beloved Paula chip!).
I’ve been exploring Yosys / NextPnR / Project Trellis on some Lattice ECP5-based boards recently, and I’ve been very impressed and enthused by what I’ve seen. I do have to admit, though, that it’s not “there” yet, especially when it comes to SystemVerilog and VHDL support through the ghdl-yosys-plugin. Yes, you can develop and compile “real” projects with Yosys and friends, but you do have to keep the toolchain’s limitations in mind and design around them.
For this reason I wanted to install and try the “official” software for ECP5 development, namely Lattice Diamond. This left me with a slight problem in that it’s only available on Windows and Redhat Enterprise Linux 6 or 7, with the software distributed in RPM format.
Continuing my experiments with the IceSugar-Pro board, building cores using Yosys and friends, I now have EightThirtyTwoDemos running, using PMODs to provide VGA out, I2S audio out, PS/2 keyboard and mouse, and SD card. (The latter isn’t strictly necessary since the FPGA board already has an SD card slot – but it’s on the underside of the board and impossible to access while the IceSugar-Pro is inserted into the carrier board.)
So how did I go about wiring up the PMODs?
Coping without SignalTap – Part 3 – 2022-04-28
I’ve found the bug which was preventing interrupts from working with the EightThirtyTwo CPU, at least in the EightThirtyTwoDemos projects…
Coping without Signaltap – Part 2 – 2022-04-26
By the end of part 1 I was able to communicate over JTAG with a design running on the IceSugarPro, remotely control the LEDs on the board and read the contents of a wide register through a FIFO queue.
That’s the barebones of a useful debugging subsystem, but to be truly useful we need the ability to set a trigger condition.
2022-04-19 – Part 1: Establishing communication
If I’m going to find the problem with EightThirtyTwo that’s preventing interrupts from working, I’m going to need some way of observing what’s going on. The CPU works in GHDL Simulation, works on Altera/Intel chips, and works on Xilinx chips so there must be something I’m doing which the Open Source toolchain doesn’t like. (Or I may have stumbled upon an actual bug…)
There are basically three problems to solve here:
- Capturing the state of internal signals
- Transporting those signals to the host computer
- Displaying them in a meaningful and readable format.
I’ve been tinkering with the IceSugarPro board recently, which is a nice little SO-DIMM form factor FPGA board containing a Lattice ECP5 FPGA. It’s the successor to the earlier IceSugar board which contained a Lattice iCE40UP5k: despite not having an iCE40 series chip, the IceSugarPro retains the name!
… that the reason for the “I$” and “D$” notation when discussing instruction and data caches is the homonym between “cache” and “cash”! Now I feel very dim!
I’ve been experimenting with the QMTech Kintex7 board, which provides a huge FPGA for a less huge amount of money. The one thing that prevents my existing projects from running on it without deep changes is the lack of SDRAM, but since I’ve been wanting to get more familiar with the Xilinx ecosystem for a while, this was a good opportunity to dive in.
Achieving 24-bit colour on a 15-bit device – 2021-12-31
[I found this unfinished post in a dusty corner of my drafts folder, and decided that tonight was the night to finish it!]
While I’m sitting through the all-too-familiar wait while Quartus builds a core, I wanted to write a few words about dithering and how I approached the problem of doing 24-bit colour video output on a platform which has only 15 bits of colour resolution on its VGA port.
The video DAC on the Turbo Chameleon 64 has just 5 bits per colour gun which means we can output 32 different levels each of red, green and blue for a total range of 32,768 colours. This is fine for the ECS Minimig core, since the original Amiga has only 4 bits per gun, for a total of 4,096 colours – but the AGA chipset doubles this colour depth to 8 bits per gun, full 24-bit output – so some compromises will be needed.