In part 1, I connected the digital vga outputs from my chip to a basys3 fpga board to use its vga connector, which I captured to my laptop through a vga-hdmi adapter and an hdmi capture card. Initially I got "no signal". Generating an independent hsync/vsync from the fpga showed a teared effect suggesting that some pixels are being dropped. Line-buffering the rgb values using the fpga corrected for this and resulted in a playable game with minor visual glitches.

In part 2, I massively slowed down the caravel clock and rerouted the captured values from the fpga to my laptop using uart, where I decoded the uart stream with a python program simulating the vga beam. I could take pixel-perfect captures of the glitches which allowed me to map the dropped pixels to the shapes of letters being drawn on screen. One of the drawbacks of slowing down the clock was that the input buttons were no longer detected at such a low speed (~12kHz instead of 25MHz) so I had to switch between the two clocks.

Continuing the journey, I found that all the dropped pixels were preceded by one of 7 particular runs of colors (it was enough to check the red channel). I was able to modify the python program such that it inserts an extra pixel every time one of these patterns were encountered and so the glitch disappeared. To get pixel-perfect output I also needed to delay the blue channel and the top-most bit of the green channel by one tick.

So it was time to slowly crank up the clock. I needed a faster connection as the uart gave up at ~230kbaud corresponding to a ~12kHz pixel clock. I could tell apart vga glitches from uart failure by adding a parity bit at the fpga.

I took out my FX2-based logic analyzer to capture the chip outputs directly and modified the python vga simulator to receive its inputs from sigrok-cli using the fx2lafw driver, binary output, continuous capture mode and an initial sample rate of 20 kHz. This was the first time I bypassed the fpga (except as a glorified clock generator used both as xclk and as a captured pin) and suddenly all the glitches disappeared without any corrections on the python side.

Apparently the glitches were caused by the fpga. Part of it was capturing on the same clock as the one I passed to caravel and not doing any oversampling. But there must have been something else too, as in "part 1" I was capturing at 100 MHz and it was also glitchy.

Anyway, I continued cranking up the clock. I could go up with the sample rate until 250kHz, but at 500kHz python+pygame could no longer catch up to sigrok. I rewrote the vga simulator in rust+sdl2, which allowed a sample rate of 2Mhz, corresponding to an ~870kHz pixel clock. Still no glitches, but not quite 25MHz yet.

It was around this time that the PmodVGA I ordered back in December arrived, so I could try proper vga output without going through the fpga. I still didn't have a monitor with vga input (or even hdmi) as everyone around me is using laptops. Thus my new setup was: caravel board -> pmodvga -> vga-hdmi adapter -> hdmi capture card -> laptop. And it mostly worked. There was pixel-perfect output unless my current guess contained the letter "O" or "W", in which case it reverted to "no signal".

By that time I grew suspicious of the extra devices in my chain, in particular the cheap vga-hdmi adapter and capture card. I expected actual screens to have better quality vga decoders. Eventually I got access to a TV with vga input and it confirmed my suspicion: the caravel board -> pmodvga -> tv screen setup worked flawlessly.

Before playtesting, I made some quality-of-life improvements. Tiny pushbuttons connected with short wires to a TV don't make for the best experience, so I flashed a Pico W with https://github.com/intGus/picow_ble_controller to map some buttons on a wireless gamepad to the gpios. While at it, I also replaced the fpga with another pico as the 25MHz clock generator.

Soon I could get rid of the second pico. Caravel has a built-in PLL, but it didn't work for me the first time. I used https://github.com/kbeckmann/caravel-pll-calculator that recommended setting the feedback divider to 15 and the output divider to 6, but this resulted in a "no signal" message, while an external 25MHz clock from the pico (or the fpga) on the xclk pin worked fine (with a jumper on J6). For the second try I did my own calculations and found an alternative configuration with the feedback divider set to 10 and the output divider to 4. This one did work.

Took the controller in my hands, sat down in front of the TV and played wordle for 2 hours non-stop, right from my chip. It felt fantastic.

I still have a few tests I'd like to perform, but this seems like a right milestone to report.