Cool project. Thanks for doing a write-up that includes so much detail.
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.
show comments
dylan604
The example image for blanking from pyroelectro.com seems off to me. The blanking was on all sides of the images, not just two sides. The beam was off before reaching the end of the line, during the retrace, and still partially at the beginning of the line. The same for the retrace back to the top. The vertical blanking at the top of the image was important as things like CC and VITC were encoded there (as well as some other non-standard uses). Essentially, the active picture was window boxed in the blanking. This example image does not represent that well at all
eek2121
Arcade machines were so weird (and amazing). Example: A TON of effort was put into copy protection, for example. There are still a few games that haven't completely been broken into, despite being 30-40 years old.
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.
retrac
The new RP 2350 has an enhanced PIO that relaxes some of the constraints the author ran into here.
Also the new HSTX (high-speed serial transmit) unit is really well suited for rapid line coding.
The article doesn't mention what games they are actually running on the arcade machine. They mentioned the 18-bit DAC being a limitation, but most 2D arcade games only output 15-bit color.
I don't know, as impressive as this is, I think using a MiSTeR would be much easier.
show comments
ge96
Philosophical tangent
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.
lawrenceyan
There's something deeply poetic about using modern engineering knowledge to breathe new life into the warm, fuzzy glow of an analog CRT.
Cool project! I've been doing software for so long but originally got an EE degree. I miss messing around with hardware.
zahlman
> I like the Raspberry Pi RP2040 a lot. It's relatively cheap (around $1 USD) and has tons of on-board RAM - 264 KB in fact! It also has what is called Programmable IO, or PIO.
I wonder how benchmarks would compare between the RP2040 and, say, a Z80.
show comments
platevoltage
This looks really cool. I'm restoring an 80's SEGA candy cab with a CRT and have been trying to figure out the best way to most accurately utilize the 15khz display in it. I tried bit-banging from a Raspberry Pi's GPIO, but landed on using an AMD GPU with the capability outputting a usable signal. This also looks like something I want to toy around with.
Cool project. Thanks for doing a write-up that includes so much detail.
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.
The example image for blanking from pyroelectro.com seems off to me. The blanking was on all sides of the images, not just two sides. The beam was off before reaching the end of the line, during the retrace, and still partially at the beginning of the line. The same for the retrace back to the top. The vertical blanking at the top of the image was important as things like CC and VITC were encoded there (as well as some other non-standard uses). Essentially, the active picture was window boxed in the blanking. This example image does not represent that well at all
Arcade machines were so weird (and amazing). Example: A TON of effort was put into copy protection, for example. There are still a few games that haven't completely been broken into, despite being 30-40 years old.
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.
The new RP 2350 has an enhanced PIO that relaxes some of the constraints the author ran into here.
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
The article doesn't mention what games they are actually running on the arcade machine. They mentioned the 18-bit DAC being a limitation, but most 2D arcade games only output 15-bit color.
I don't know, as impressive as this is, I think using a MiSTeR would be much easier.
Philosophical tangent
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.
There's something deeply poetic about using modern engineering knowledge to breathe new life into the warm, fuzzy glow of an analog CRT.
CRT tech is neat, the flat ones are cooler
https://www.youtube.com/watch?v=pjzK-Lppa1c
Cool project! I've been doing software for so long but originally got an EE degree. I miss messing around with hardware.
> I like the Raspberry Pi RP2040 a lot. It's relatively cheap (around $1 USD) and has tons of on-board RAM - 264 KB in fact! It also has what is called Programmable IO, or PIO.
I wonder how benchmarks would compare between the RP2040 and, say, a Z80.
This looks really cool. I'm restoring an 80's SEGA candy cab with a CRT and have been trying to figure out the best way to most accurately utilize the 15khz display in it. I tried bit-banging from a Raspberry Pi's GPIO, but landed on using an AMD GPU with the capability outputting a usable signal. This also looks like something I want to toy around with.
> I have a full CI/CD pipeline set up for my PCBs
Oh more on this, please!