LavaRGB mod and WDL6528 PPU

[krzysiobal]

A friend of mine asked me if I could install lava RGB mod in his famicom AV.

//inst_guide.jpg

Except the main board, there are:
* 2x DIP40 precise sockets,
* one 1x40 precise goldpin,
* one 1x40 low profile standard goldpin
* 13 pin cable
* PPU extension adapter PCB
* AV extension adapter PCB (FragolTech FT-006 / NESRGB Fami-Buddy)

//avaext_pcb.jpg

I got mainboard with revision 1.2:

//lava12-top.jpg
//lava12-bottom.jpg

Though looks like there was revision 1.1 before:

//lava11-top.jpg

Main board is already soldered with components, all you have to do is:
1) desolder the PPU from FC mainboard
2) solder DIP socket to FC mainboard
3) solder 13 pin plug to lava RGB (this plug contains: GND, chroma, luma, composite, BLUE, GREEN, RED, SYNC, console /RESET, $4016.CLK, $4016.D0, OUT0)
4) solder goldpin to lava RGB
5) solder DIP socket to lava RGB
6) solder goldpin to PPU extension adapter
7) solder lava RGB to the PPU extension adapter

If you do it in wrong order, you will be in trap because for example - soldering DIP socket first will cover the holes where you need to solder goldpin. Included instruction manual is not helpful enough about it.

After soldering everything together, all I got was grey screen. I though PPU got broken, some of the pin connectors does not work reliably, ESD killed lava RGB or so. After some inspection I found out that there is no M2 clock. Culprit was the /RESET cable.
Manual says: RST does not require welding (welding??), but in the manual's photos they are soldered.
In fact, this line is driven constantly low by the FPGA (probably this pin is not implemented at all and the FPGA is configured to drive low all unused inputs)

Desoldering /RESET cable made it work. My first impression is WOW, I used S-Video cable and there is huge difference between regular composite. Overally the PCB is well-thought - you can still unplug the lava RGB, unplug PPU from in and put the PPU into the DIP socket in famicom AV.

Ok so how it works?

//lava_11_sch.png

FPGA sits between PPU and CPU data buses and listens to that bus.
* when CPU writes something to $2000, FPGA passes this data to PPU but with bit 6 so that PPU will always output currently rendered palette index on EXT0,EXT1,EXT2,EXT3
* FPGA also listens if any write to PPU palette occurs because it needs to store internally full copy of palette
* to distinguish between sprites and background (there is no EXT5), FPGA passes modified data to PPU via $2007 when palette range is written so that all background entries got one index and all sprites index got another one. There are 3 comparers with different threeshold to extract from PPU pin1 (video out):
* vblank
* scanline start
* sprites vs background

This is preview of what actually generates the PPU (on the left) vs what actually should be on screen added boxes over sprites):

//pin21.png

Proper 3.3-5V translation buffers in the lavaRGB keep your console safe (the only signal that is passed directly to FPGA without translator, but only 100R resistor is series is the clock, probably to avoid false spurious edges.

My video grabber has occasional problems with capturing s-video generated from lavaRGB (image was distorted in the middle in SMB3 for example, but for simple games wthout /IRQ - all was ok). But I believe this is grabber issue.

//svideo.png

I was going to check compatibility of lavaRGB against different PPUs.
* RP2C02G-0/RP2C02H-0 - no problems
* UA6528 - no problems
* WDL6528 - I got 14 of those chips and found out that few of them works with lava fine, while rest have artifacts but only on sprites. Appearance of those artifacts differs depending on a particular WDL6528 chip, but stays the same after power up.


//ua6528vswdl6528.jpg


//wdl6528_artifacts1.mp4
//wdl6528_artifacts2.mp4

I was thinking - maybe some timing issue with EXT pins as they are not used anywhere so WDL might implement them differently?

But after connecting scope probe to PPU pin 21 even on UA6528, similar issue appeared (on RP2C02G/RP2C02H, adding scope probe does not change anything).
So it was clear for me - there is something with the video signal voltage level.

After comparing all those 3 PPus - RP2C02GH has the brightest image (=highest voltage), WDL6528 the darkest (=lowest).

//ppu_comp1.png

Solution was to replace R9=7.15k in the voltage comparer to something bigger to bring the comparision level (1.92V) lower. THe closest I had in my drawer was 10k and after replacement - all problems with WDL6528 were gone.

//r9.png

Out of curiosity, those comparers really are vulnerable to the voltages. When I connected simple voltage amplifier to PPU pin 21, lava RGB stopped working at all:

//vamp.png

By the way of having all those different PPUs in my drawer, I checked all palette colors they generate (all tests done on non-lava rgb console with identical video amp circuit as shown above):

In my opinion, UA6528 gives the best (most saturated) colors.

//ppu_comp2.png

[Zonomi]

Very interesting reversing.
Do you think it is a clone of Tim Worthington's NesRGB mod ? It seems to work the same way.

[lidnariq]

Since the original person to post the idea was thefox... viewtopic.php?t=9561

[krzysiobal]

Looks like available solutions for RGB are:

1. Tim's nesrgb, created: 2013-10-20:
https://etim.net.au/nesrgb/

2. Lava RGB, created: ????:
http://lava-fc.top/
https://github.com/v5100v5100
https://www.pcbway.com/project/sharepro ... 0cfff.html

3. Krikkz's RGB blaster, created: ????
https://krikzz.com/our-products/cartrid ... aster.html

4. Second PPU inside cartridge, created: 2019-06-26
Similar idea to NESRGB but having the second ppu (and its RAM) inside cartridge, so no modification of console is needed.
Because this PPU was clocked by its own 26.601712MHz crystal, I had problems with synchronizing it with the PPU inside console.
But now I found ICS501M chip (LOCO™ PLL CLOCK MULTIPLIER) that is extra cheap and could be used to multiply the M2 to 26.601712Mhz and so sync problems is solved:

viewtopic.php?t=19033

5. Force PPU to grayscale mode and sample video signal
Since most of the artifacts in composite video signal come from adding hue and saturation information together with the lightness, I was thinking would it work the same way if we
a) make it also in form of plug-thru cart
b) omit totally EXT pins and use only video out signal from the console output (that way it could work even with glob top famiclones)
c) force the PPU to generate grayscale image (by making second write to $2001 after the first one with proper bits set)
d) measure voltages of video signal for every color in palette in grayscale mode and select 25 colors from them that are most equally arranged in [Vmin.. Vmax region]
e) assign for each from 25 colors in palette each of such color from d) (again, by making second PPU write to $2007)
f) sample the grayscale signal on composite video, detect 25 colors from it using comparator and send it to some rgb or s-video encoder:

Because each clone might have different video amplifier, different internal palette, this cartridge could first make auto-adjustment by making all the measurements first and then choose which colors to use

a3.PNG

[Fiskbit]

c) force the PPU to generate grayscale image (by making second write to $2001 after the first one with proper bits set)

Just to make sure we're on the same page: The grayscale feature works by ANDing the 6-bit palette color value with $30, forcing it into the first column. Ignoring emphasis, this limits the screen to just 3 grays. Therefore, you get very little information by using grayscale mode.

[krzysiobal]

Just to make sure we're on the same page: The grayscale feature works by ANDing the 6-bit palette color value with $30, forcing it into the first column. Ignoring emphasis, this limits the screen to just 3 grays. Therefore, you get very little information by using grayscale mode.

Oh thank you, I didnt know that it works this way.. So the whole idea is destroyed.

[krzysiobal]

I've just noticed that some of the games, mostly Codemasters' ones have strange color issues with the Lava RGB:

* Fantastic Adventures of Dizzy - during intro, everything is black except background. During game, the background is much darker than it should be.

//diz1.jpg
//diz2.jpg

* Micro Machines - bottom half of the screen has black background

//mm1.jpg
//mm2.jpg

* mig 29 - during the intro, screen is completely black. During the game, terrain is black

//mig291.jpg
//mig292.jpg

I initially thought $0d color used by those games is the reason, but I have fixed versions of those games that do ont use $0d color and the problem still persists.
I checked it against many different PPU versions (UA6528, WDL6528, rp22c02g) and they behave the same way.
Looks like there is some software bug in the lava rgb but I don't know what is exactly triggering it to appear only in certain games.
Maybe if the game does palette change during rendering, something bad happens?

[Fiskbit]

Yes, this is related to mid-screen palette writes.

As far as I'm aware, Lava RGB works the same way as NESRGB in that it uses EXT output and colorizes the result with palette data stored in the mod that was snooped from CPU->PPU writes. In order to know what writes are palette writes, the mod needs to understand the state of v, the internal VRAM address register. This means it needs to understand things like $2006 writes, the state of w, and the automatic increments of v that occur during rendering. These mods don't do that last one, and at least in the case of Micro Machines, the game is writing $3F0F to v and then relying on a coarse x increment of v before rendering turns off to target $3F10 with the following palette write. The other palette writes I'm seeing are more straightforward, but there may be other aspects of the mid-screen palette writes here that are confusing the mods that aren't immediately obvious to me.

When the mod and the NES disagree about which palette byte is being written or even whether palette RAM is being written at all, you end up with various problems. The mod's internal representation of what the palette is supposed to be becomes incorrect, because colors aren't updated when they should have been, are put in the wrong place, or are updated when no palette write actually occurred. The mod also sends the wrong palette data to the console; the console runs with a monochrome palette of two different grey levels, one for sprites and one for backgrounds, which is used for the 5th bit of the palette address because EXT only outputs the low 4 bits. If the mod is mistaken about which one is written, then the monochrome palette in the NES could become incorrect and certain colors could have the wrong value for bit 4, making background colors come from sprite palettes or vice versa. Finally, if the mod doesn't think the game is writing to palettes, it lets the data through unchanged, so if it really is a palette write, the NES can end up with actual color in its composite output, which may lead to additional issues compared to just having the wrong grey.

NESRGB also doesn't emulate correct color behavior when rendering is disabled, because that's not something present on the EXT output and the mod simply doesn't bother to try to recreate it. I presume Lava RGB has that exact same behavior. That's why Micro Machines has that darker blue band in the middle; rendering is off and v is supposed to be pointing at a light blue color in that region, but the mod just shows the backdrop color.

One strategy these mods could use to try to always have the correct palette address without emulating v is to just watch the PPU address pins. When rendering is off, v is on the external address bus, and the low 8 bits of v should be visible on the data bus. You can only write to palette RAM when rendering is off, so if you just watch this, you know exactly what v is when the write occurs without having to emulate anything about it.

[krzysiobal]

Thanks for clarification.
I just looked at the LAVA RGB schematics and none of the signals:
PPU_RD, PPU_/WR, PPU_ALE
is routed to the FPGA so there is no way of adding support for proper emulation of PPU (incrementing v during rendering) by just software update.

The idea of snooping PPU data bus + PPU ALE sounds really straighforward.

[Fiskbit]

It doesn't need that information for the workaround I'm suggesting. During rendering, the PPU can never produce an address in the palette RAM range for the mod to confuse as pointing into palette RAM. The mod also sees all register accesses by the CPU. Any time the PPU is outputting a palette RAM address in the high 6 bits (all 6 bits are 1) and the mod sees the CPU read from or write to $2007, it can use the low 8 bits on the PPU's AD pins, which are currently outputting the actual low 8 bits of v, to tell it which palette RAM address the CPU is going to access. The state of the /RD, /WR, and ALE signals don't help with this.

I can only think of a couple ways in which this could fail. First, rendering could start during the access (ie this access occurred at the very end of vblank), potentially preventing the write from going into palette RAM on the actual PPU (I haven't looked at the timings for this to see how plausible this is). Second, using INC to access $2007 could cause issues by accessing the register faster than the PPU can service the accesses. Well behaved games shouldn't encounter either of these problems.

[krzysiobal]

Yeah, your approach does not need PPU /RD nor PPU /WR though it requires whole PPU AD0..7 bus as well as higher 6 bits to be snoopped by FPGA. Though I still think you need to watch ALE, otherwise you can't recognize what is present on AD bus (addr vs data)

As you can see from the waveforms, there are 3 PPU RD cycles per one CPU cycle, but the delay between fall of PPU /CE and rise of ALE is variable depending on a particular power-up allignment so you cannot just wait a fixed amount of time.

[Fiskbit]

Ah, so those PPU pins aren't connected to the FPGA, either. Yes, this would require a lot of FPGA pins, so from that perspective, trying to emulate v could be a better solution. However, there are so many edge cases with v that I would not trust the mod to get it right. It's already hard enough for software emulators to get this right.

For my solution, though, ALE wouldn't be needed because (as I understand it) the AD pins are always address except when a memory access (the actual /RD or /WR) is happening. By sampling the pins when you see the CPU access $2007 (without waiting at all), you know what the address is for the access, and you get the data from the CPU data bus. Because rendering is off, the PPU is not doing any other memory accesses at this time, so there isn't anything to synchronize with. (The data is also put on the PPU AD pins later; a write to palette RAM looks like a normal write on the PPU bus except that the /WR signal is not asserted. I don't see any benefit to trying to get the value from there, however.)

[andkorzh]

I've prepared a design for my own PPU replacement for the Lattise FPGA, similar to the one used in the Lava RGB. I believe that if I flash my design to the Lava RGB board and use the additional inputs for the EXT and FPGA inputs from the comparators, as well as the inputs for the Latch and Clock joysticks for palette selection in the Lava RGB, then the pins should be sufficient for my design to function properly on this board, hypothetically. The level shifter for the Pd bus will need to be connected to the shifter from the PPU side with wires.
Estimated implementation:

LAVA_RGB to PPU_LITE.jpg