The cheapest FPGA RGB-PPU

[andkorzh]

I'd like to present to you a version of a PPU replacement for a FPGA. The goal of the project was to create a low-cost replacement for an RGB PPU for a NES. Initially, I used a 4-layer PCB and an ADV7125 integrated DAC, but to reduce costs, I decided to switch to a more affordable and simpler board and build a similar R2R DAC using resistor arrays. As you can see, I was inspired by the NESRGB project, which allowed the mod to be installed on any original Nintendo console using ready-made adapters. Several color palettes are available, which can be switched using configuration jumpers. I'll make a video showing the prototype in operation later.

IMG_4667.JPG

full pal.jpg

This is an open source project, I am preparing all the information in the GitHub repository.
https://github.com/andkorzh/PPU-LITE
Demo:
https://www.youtube.com/watch?v=B2EgrhUERuM

[Ben Boldt]

I have a couple of questions.

• How do I get the PCB? Is the it available for purchase from you or do I have to send files to PCBWay? I don't see any files in GitHub for the PCB.
• Is it a complete replacement or does it still require a real PPU chip connected like NESRGB?
• Any known bugs or compatibility issues?
• All of the other RGB and HDMI mods have some bugs. Do any of those bugs also apply to your design?
• How full is the FPGA? Can it still be expanded for other features such as VT03 graphics modes, HDMI, etc.

It looks nice. Your choice of that big 3.3V regulator is simple and effective; it will be reliable.

[andkorzh]

The PCB will be in the repository soon. A couple of minor issues were discovered, and I'm working on fixing them. This is a complete replacement; no additional chips are required. The design contains a full-fledged NES PPU with an internal structure as close to the original chip as possible. The project takes up 41% of the chip's capacity. It's a Cyclone I EP1C3T100. I prefer linear voltage regulators. I try to use what I have on hand. The prototype shows excellent compatibility. If you don't mind, could you point me to where I can read about issues with other PCB implementations?

compreport.PNG

Here's a photo of an early prototype from two years ago. It contains an expensive 4-layer board, and the installation dimensions aren't very good.

2023proto.jpg

[Fiskbit]

The DIP-40 footprint lacks the EXT pins, which would be necessary for a mod that requires slave mode and which wouldn't be useful for a PPU replacement on an NTSC system. However, I do think it's worth supporting RGB output on the EXT pins to allow this to be compatible with arcade systems, so consider that a feature request.

Since it's not using slave mode, there's no reason for it to have the same sort of issues we see on the NESRGB and Hi-Def NES. Being a new implementation, though, there is of course room for all sorts of novel bugs in it. We've found, for example, that the RGB2C02N FPGA PPU has a bug where it doesn't output an address on the 'idle' dot, which breaks the small number of MMC3 games that the use the incorrect pattern table order while also using scanline IRQ (Wario's Woods, Armadillo, Indivisible).

[Fiskbit]

If you don't mind, could you point me to where I can read about issues with other PCB implementations?

I don't think there's been much research yet on the accuracy of FPGA implementations of the PPU (aside from the one RGB2C02N bug I mentioned above). The existing RGB and HDMI solutions for the NES instead work alongside the PPU, either snooping on the memory buses and emulating part of the PPU (RGB Blaster, PPUdigitizer) or intercepting and modifying the data sent to the PPU and colorizing the PPU's digital video output from its EXT pins (NESRGB, Hi-Def NES).

I don't know much about the accuracy of the snooping devices. There's a review of the RGB Blaster that shows serious problems with Rolling Thunder, though I'm not sure what is triggering them.

The slave mode devices have a lot of problems:
- They modify the values sent to the PPU, and the CPU can see the modified values via open bus value on the PPU register interface (and the value being wrong causes Arkista's Ring to crash at the end of the first loop).
- They give the PPU a special monochrome palette to distinguish between backgrounds and sprites and use this as a 5th bit of video on the composite output, since the EXT interface only outputs the low 4 bits, but they have sync issues where the digital and analog sources may be off by 1 pixel on some power cycles, causing color fringes on one edge of all sprites. The analog video from the PPU also may not change fast enough to get the right value for the first pixel after transitioning between backgrounds and sprites, causing flickering pixels on the edges of sprites.
- They don't emulate the impact of rendering on v, so if a game relies on the value of v when disabling rendering to write to palette RAM, that will go straight to the PPU's palette RAM instead of being intercepted. The device won't know that color was updated and thus won't use the new color in its RGB output, and the write will mess up the monochrome palette in the PPU, potentially causing problems with detecting the 5th bit from the PPU.
- The don't emulate the backdrop override behavior when rendering is disabled, where pointing v into palette RAM draws that color. Games use this intentionally sometimes, such as for the colored bar toward the top of the screen in Micro Machines and to hide ugly lines when updating the palette mid-screen.

[Zonomi]

or intercepting and modifying the data sent to the PPU and colorizing the PPU's digital video output from its EXT pins (NESRGB, Hi-Def NES).

There is a graphical bug with the Former Dawn Demo an Hi-def NES. I think Hi-def NES emulates (badly) a part of the NES PPU.

[andkorzh]

Fiskbit, thank you very much for your reply. However, regarding the EXT outputs for connecting in slave mode in Artcad machines, there is a problem: a shortage of available FPGA pins. Also, keep in mind that the Reset pin will need to be used to synchronize the chips with each other. Theoretically, you could use four pins for configuration and a pin for a second optional crystal oscillator for these purposes, and it would work; I don't see any problems. Minor design changes are needed. But we'll be limited to a single color palette, so perhaps this won't be a problem.
I've added the PCB files to the repository, so anyone can assemble the device themselves. I'd also like to point out that the board design supports a configuration where the VRAM is located inside the cyclone. However, the VRAM on the motherboard must be desoldered and the VRAMA10 and VRAMCS signals must be connected to the board. To do this, you need to add the VRAM instance to the top file in Quartus, having first generated it using the MegaFunctions wizard.

[Fiskbit]

To clarify, while arcade PPUs do use the EXT pins, they do not use (or even support) slave mode; no Nintendo-made system uses this mode. RGB PPUs repurpose 3 of the EXT pins for RGB video output (and the 4th pin may be an analog ground). A single palette is sort-of fine for arcade systems; several of the arcade PPUs (2C04 series) have scrambled palettes that games released for those PPUs rely on, but most arcade PPUs are probably the variant with a fairly-standard, close-to-2C02 palette (2C03 series). There's also the 2C05 series with minor functional tweaks (same palette as the 2C03 series, but swapped registers and a signature in the unused bits of $2002).

[Dwedit]

One problem with the PPU's ext mode is that the PPUs must have exactly the same timing, and the skipped dot can cause timing problems. One PPU skips the dot and the other one doesn't, and all bets are off. Forced Blanking is one way to prevent the dot from being skipped.

[andkorzh]

I recorded a short demo. Don't worry about the colors; my iPhone camera distorts the colors a bit when exposed to light in the dark.
https://www.youtube.com/watch?v=B2EgrhUERuM

[acidrain97]

or intercepting and modifying the data sent to the PPU and colorizing the PPU's digital video output from its EXT pins (NESRGB, Hi-Def NES).

There is a graphical bug with the Former Dawn Demo an Hi-def NES. I think Hi-def NES emulates (badly) a part of the NES PPU.

Speaking of the Hi-Def NES when using pc10 palette SMB sometimes exhibits random appearing green blocks. Only happens in world 1-1. Any other palette not a problem...