Building a 24-bit arcade CRT display adapter from scratch

I do a lot of PCB review for students and makers, so if you're interested I wrote up some notes. Consider this an incomplete review because I only had so much free time, but hopefully this information can be helpful for your next rev or next project.

Design:

- Add ESD protection to all pins exposed by connectors and around the buttons. A simple TVS will work. However, the capacitance of the TVS needs to be small enough to minimize burden on your higher speed lines like USB and VGA. I'd use a cheap TVS for the low speed pins and then maybe look at some dedicated USB-HS protection parts and then just re-use those on the VGA lines. The USB3300 part you're using looks to have some minimal built-in ESD protection but as you observed it's probably not enough for real world use.

- Consider a buffer between your resistor DAC and the output. This could be an op-amp or a dedicated buffer chip. This will let the resistor DAC operate without significant load, isolated from the cable. You can then put a 75 ohm resistor in series with the buffer output to get optimal impedance matching with the 75-ohm VGA cable and load. You can get away with resistors connected straight to the VGA cable for demo purposes, but having it properly buffered and impedance matched will clean up the edges even further.

- Look into the design of an R-2R DAC as an alternative to the weighted-summing configuration you've used. You would want 0.1% resistors at 8-bit depth but you'd only have to buy and manage 2 resistor values (R and 2R) which is helpful when doing hand assembly.

- Better yet: This project is a good place to use a real DAC chip. Resistor DACs are cool to play with and useful for ultra-cheap demo boards where manufacturing cost is a high priority (Like the RP2040 VGA demo) but for a hand-assembled project like this a good DAC chip is great choice. It would shrink your PCB, reduce assembly time, and allow you to choose a physically smaller MCU package because you don't need 24 IO pins for the resistors.

Schematic:

- When using hierarchical schematics it's a good practice to avoid putting ICs and components in the root sheet. I suggest adding additional sheets for the MCU and other parts, then connect the blocks in the root. Treat the root page like a block diagram.

- KiCAD's bus functionality could help reduce a lot of the pins going into your blocks, like USB_D[0:7] and VGA_R[0:7]

- Breaking up that big STM symbol into a couple parts would be a good way to learn how to use KiCAD's symbol editor and would allow everything to fit on standard A4 sheets

- Don't hesitate to add notes to the schematic that might be helpful during debugging, assembly, or for your future self when you return to the project.

- I like to do a cleanup pass on schematics to make sure all labels are readable and there's enough space to comfortably see everything. It's a good practice to get into and pays off when you're tired from a long debugging session and trying to read a schematic. I suggest using the empty space on some of your pages to space components out more so no text is overlapping or hard to read.

PCB:

- You used 0.15mm (5.9 mil) traces almost everywhere. It's best to avoid using small traces unless you have to. You want to stay away from the minimum trace/space of your PCB manufacturer by default and reserve those for only the places where you need it. It will improve yields and make rework easier. Many of your traces could be 0.25mm or 0.5mm without any problem.

- Likewise, avoid letting traces run too close to pads unless you really need to. It's okay when you need to squeeze a trace into a narrow spot, but by default you should try to give as much room between pads and traces and between adjacent traces as you can. The tighter the spacing, the easier it becomes to accidentally short something out during assembly.

- Similar story with vias: Try not to use the absolute smallest vias everywhere when you have space.

- A lot of your vias are grouped together in a way that creates large slots in your ground plane. This doesn't matter too much at the low speeds you're working with, but it's good practice to avoid creating large cutouts in ground planes. The return current has to flow somewhere and those big slots will force it to take a longer path, which increases emissions and distorts high speed signals.

* I also started with an RP2040 because the PIO is such a good Swiss Army knife for working with custom digital protocols. An RP2040 with a faster USB PHY would be killer!

* The STM32U5 series has variants with built-in High Speed USB PHYs, along with 2.5 megabytes of SRAM, along with easily solderable footprints (down to LQFP64) if you want to solder at home instead of having a PCB fab do it.

* JLCPCB and/or PCBWay can assemble boards for quite cheap these days

* ESD protection would be good to add to the board, as others have noted and as you mention in the post

* Ideally all routed traces which have fast rise/fall times (most digital signals) should have a solid reference plane under them along the entire trace, to avoid cross-talk and EMI, along with vias for your reference plane if your signal changes layers.

* If you control the rendering, and color banding is still an issue, look into Interleaved Gradient Noise

* I hadn't heard of GUD before. I just made a simple USB Bulk Out endpoint in the firmware and in my application code, took less than a day. Sometimes a custom solution is quicker and easier but it depends on where it's running and who you're distributing it to. Obviously my custom solution isn't interoperable with other things, but for now it doesn't need to be.

I plan to write up a blog post on the project I worked on, I'll be sure to post it to HN when I do.

https://blog.demofox.org/2022/01/01/interleaved-gradient-noi...

My advice is to never shoot the board before you have all your IO planned out in the tool. That's saved us a bunch of times.

Also, give the U5 series a look? Hyperram, internal HS phy, and parallel display port.

Also also I'm pretty sure pis can put out parallel display on the 40 pin header. Maybe not 24 bit, though.

The systems from the 80s-90s were also very odd/exotic. Some systems (like certain variants of Street Fighter II) had interesting bugs that needed to be worked around.

Also the new HSTX (high-speed serial transmit) unit is really well suited for rapid line coding.

Here's a different project that generates a high resolution high depth VGA signal from the RP 2350: https://www.breatharian.eu/hw/disphstx/index_en.html

And here's NTSC composite using just the original PIO: https://github.com/obstruse/pico-composite8

I don't know, as impressive as this is, I think using a MiSTeR would be much easier.

I also produce hardware projects and share them open source but unfortunately at a certain level of complexity people don't reproduce them. It's kind of sad but also I'm glad to be able to give back as I've had people help me learn to code in the past, sit down with me through video and yeah. Or people sharing knowledge in question answer forums.

There is the inspiration aspect too I've had some of my repos get forked/modded so that's something but yeah ultimately gotta do it for yourself. Getting published in tech websites is cool though, like I had a project get picked up by a Japanese website that was neat.

I wrote a book about Windows NT Server system administration, and sustained this error through chapters discussing hard disk and network bandwidth.

God bless my technical editor, who caught this before publication.

Most PCs, like the laptop the author mentions, can output 15.7 kHz using native or super resolutions (depending on the GPU's minimum pixel clock). For a CRT, both are the same, provided you have the right configuration.

There is a lot of information about this in the context of arcade machine emulation for both arcade and consumer CRTs.

Am I missing something?

https://www.youtube.com/watch?v=pjzK-Lppa1c

Wouldn't it be trivial to do this development in a VM with USB pass-through?

I wonder how benchmarks would compare between the RP2040 and, say, a Z80.

Oh more on this, please!

Ah yes, gotta love it when you get screwed because you missed one sentence in a 642 page doc. I can relate