Nintendo Virtual Boy Displays: Reaching out for help, to create new larger displays

[Eudimorphodon]

CLKA, CLKB, and CLKC are not used by the Verilog code - but are (obviously) used by the VB for brightness control!

It would definitely be of some interest to see what the actual duty cycles on those lines are and how they vary when a game does a "palette change" or fade effect, to see if they just directly translate to the percentage of the time the LED is held on during a line time or if there's some translation that was embedded into the LED control die.

 

[T-Squared]

Is the display specifically a common failure part in these things? I would think parts like the oscillating mirror would be far more of a problem, but that’s just a wild guess. To make the costs even *remotely* reasonable per chip you’re probably going to need to be able to sell thousands of them.

The display is not quite a failure point, but the connection from the display PCB to the FFC is.

Nintendo were frugal when it came to that connection. They didn't solder a cable to the display board. Rather, they used conductive glue. This is where many failures of the system stemmed from. After 30+ years, the glue deteriorates, and causes sporadic disconnects. Some have attempted in the past to bake the displays, softening the glue again, but it's a losing battle.

There are solutions, such as new FFCs like the Virtual Boy EyePatch, but they take a steady hand to solder to the traces. Plus, the system seems to be sensitive to solder flux. I've attempted to repair mine, but I have glitches here and there, and I am in danger of damaging mine past repair. Others have already damaged theirs (one had a glob of flux UNDER the plastic window that protects the LED array, and completely destroyed the fragile bond wires trying to get it out), and others have had displays where an LED is completely inoperable, leaving a dark line in their projected display.

 

[daver2]

A bit further today with my understanding.

The writes from the VB to the RAM is as follows:

WRITE_ADDR is reset to 0 an a LOW to HIGH transition of the chip select (CS) input.
WRITE_ADDR is incremented an a LOW to HIGH transition of the SHIFT input.

If the CS input is HIGH and SHIFT transitions from LOW to HIGH, this initiates a write of D15..D0 into the RAM at the WRITE_ADDR. There will be some additional timing constraints on exactly when WRITE_ADDR is incremented and the WRITE to the RAM is performed. I am not too bothered with this detail at the moment.

As a result, the 16-bit data bus (from the VB) is stored into RAM starting at address 0 (when the CS is activated) and incrementing by 1 for each shift pulse.

28 shift pulses gives us a complete LED vertical strip of LED pixels and further pulses gives us each horizontal 'fame'.

However, when the 16-bit data word is read from the RAM - it is split up as follows into eight (8) pixel values of two (2) bits each

  Data bit: D15 D14 D13 D12 D11 D10 D09 D08 D07 D06 D05 D04 D03 D02 D01 D00
 PIXEL_OUT: D0  D1  D0  D1  D0  D1  D0  D1  D1  D0  D1  D0  D1  D0  D1  D0
            ------  ------  ------  ------  ------  ------  ------  ------
PAIR_INDEX: 1       3       5       7       6       4       2       0

Note how the D0 and D1 (two bit brightness for each pixel) are swapped between the high byte of the word and the low byte of the word.

This accounts for why the 2/3 and 1/3 brightness equates to 0x55AA and 0xAA55 respectively.

Now to work on the how the data is read out of the RAM and displayed on the screen. This is for another day... Hopefully, this will identify the order of the pixels/data bits in the shift registers.

Dave

 

[daver2]

I got bored, so I had another look!

At the beginning of each video frame, VCOUNT, READ_OFFSET and PAIR_INDEX are all cleared to 0.

At the beginning of each video line, HCOUNT and READ_COUNTER are all cleared to 0.

The READ_ADDR (RAM read address) comprises the sum of READ_OFFSET and READ COUNTER.

For each effective horizontal pixel (well, 2 physical horizontal display pixels), READ_COUNTER is advanced by 28.

For each scanline (well, 2 physical scanlines), if the PAIR_INDEX is 7, READ_OFFSET is advanced by 1; and PAIR_INDEX is also advanced by 1 (remembering that PAIR_INDEX consists of 3 bits - so can take the value from 0 to 7).

I should be able to now tie this together...

Dave

 

[Eudimorphodon]

I wonder if the differing bit-order of the high/low bytes is just an artifact of some pin numbering getting lost in translation between the "real" order on the original part verses how they were laid out on this adapter? (Which required them to "fix it in post".)

 

[daver2]

This is my 'best guess' for the vertical ordering of the LEDs in the strip based upon the order words sent and bit numbers within the word.

Ignoring the CLEAR signal for now.

The cycle/frame starts when the CS signal transitions from LOW to HIGH. Each 16-bit word is shifted in when SHIFT transitions from LOW to HIGH (and CS is HIGH).

I am numbering the words starting at 00.

The most significant bit of the word is D15 and the least significant bit is D00.

Within the pair of bits identified for each LED (e.g. D14/D15) the bit reference on the left is the D1 of the brightness logic and the bit reference on the right is the D0 of the brightness logic.

Word 00 bits D01/D00.
Word 00 bits D14/D15.
Word 00 bits D03/D02.
Word 00 bits D12/D13.
Word 00 bits D05/D04.
Word 00 bits D10/D11.
Word 00 bits D07/D06.
Word 00 bits D08/D09.

Word 00 is followed by words 01, 02, ..., 27 in the same bit order.

Cross-checks:

28 [words] * 16 [bits] = 448 [bits].

2 [bits/pixel] = 448 [bits] / 2 [bits/pixel] = 224 [pixels].

I should be able to code this logic up in a logic simulator now...

Dave

 

[T-Squared]

I have some FFC extender boards on the way, one of which I will convert into a breakout board to use with my logic analyzer.

The order of the events confuses me, because I would think the "latch clock" pulse (based on the name in the patent) would come after the shift register is filled, not before.

I know my schematic is probably not logical, but I'm trying to base how the data would be retained in the latch if there is no latching signal after the data has been input.

Instead of filling the shift register, then transferring the data to the latch with a pulse,

the logical way of latching without an external pulse would be:

Transfer the bits on the shift register into the latch like a see-saw using the antiphase of the clock. The bits in the latch change on each clock cycle, if I understand the idea. At least, the logic there is that the data is already latched when it comes time for the PWM clocks to be asserted.

The question we're trying to answer is: How do the bits get into the latch if there possibly isn't a latching signal to transfer them?

Anyways, when my extender boards come in, I will take a reading with my logic analyzer to see what comes first, the chicken or the egg.

 

[daver2]

Don't forget, there are a group of pulses BEFORE the clear/reset/latch signal as well as those AFTER.

There are three (3) possible scenarios:

1. A combined latch/reset signal.
2. Count to 28 then latch.
3. An extra bit on one of the shift registers.

There are 28 clock pulses, with each clock pulse latching 16 bits of data (in parallel) into 16 shift registers - with each shift register being 28 bits deep. This is our starting point.

In (1) we shift a load of bits into the shift register. The LOW->HIGH transition of the LATCH/RESET signal causes the shift registers just loaded to be latched into the output registers whilst the HIGH->LOW transition of the same signal causes the shift registers to be reset.

In (2) the RESET signal is just that. It resets the shift registers and a counter. The CLOCK signal then shifts 28 words into the shift register and (on the last clock pulse edge) the counter causes the shift register contents to be latched into the output register.

In (3) the we have an extra bit in one of the shift registers (this acts as a LATCH bit). The RESET signal clears the shift register - except the first bit of the register chain containing the extra bit. This extra bit is set. On each clock signal, the data is shifted into the shift register chain. After the 28th clock, the extra bit has now transitioned from 0 to 1 - and this is the latch signal.

These are three examples of the sort of things I have used myself in the past. Now, which one is applicable...

The important thing is that there must be some form of RESET somewhere. If not, any glitch could cause the image to be permanently shifted and never recover. This would be a bad design. I have seen this exact type of failure mode on ill-conceived serial communications protocols.

Dave

 

[Eudimorphodon]

FWIW… if the project is now no longer building an actual prototype of some sort, it’s fundraising to pay a chip manufacturer to make new units then… does it matter? The shift registers, output latches, and final output driver stages all lived on the same hunk of silicon and all that would matter for a replacement would be that it behaves appropriately when fed the same signals from the outside. If there’s a trace that says the clear pin toggles once with no data present and then there’s 28 toggles of the clock pin transferring 16 bits of pixel data each time then would it matter if the new die implemented it differently?

(IE, let’s say the original did it like @daver2 described in scenario A; would it make any difference at all to the output if the replacement, I dunno, didn’t technically have a shift register at all, it had a multiplexer and counter (reset by the clear signal) that made it just push the 28 data words directly into addressable 2-stage latches? The end result is the same, the buffered presentation of 448 bits of output data to the final output stage for each line.)

Trust me, paying someone to design the circuit that goes on the chip will be petty cash compared to the fabrication costs, it’s not going to change your Kickstarter targets much.