PowerBook reverse engineering for fun and no profit

[invenexus]

Okay, I chased this all the way down and want to correct my earlier 102 Hz claim it's colour depth, and it splits into two regimes.
I confused myself at first by changing depth while also toggling power management and rebooting, so I was seeing 68, 87 and 102 Hz without tracking what caused what. Isolated properly now, measured directly on FLM.
During boot (before the Mac OS splash screen), the frame rate depends on the colour-depth setting:
1-bit (B&W): 68 Hz
2-bit (4 greys): 87.4 Hz
4-bit (16 greys): 102 Hz
Once the OS splash/loading screen appears, it switches to a fixed ~69.94 Hz and stays there regardless of depth.
So the depth-dependent rates I first reported and the constant ~70 Hz I measured in the loaded OS are both real they're just different phases. Looks like the ROM picks a boot frame rate based on the stored depth setting, then the OS graphics driver (the DB-Lite driver) takes over and runs its own fixed rate. That fits your note about ROM setting things up before the OS is discovered.
Comparing to your figures: 1-bit (68 Hz) and 2-bit (87 Hz) match exactly. The difference is that your notes group 2-bit and 4-bit together at 87 Hz on the 180 they're distinct, with 4-bit running a full step higher at 102 Hz. So the 180 gives each greyscale depth its own boot frame rate (68/87/102), presumably scaling the refresh up for the extra dithering.
None of this touches the boot screen content or power management I ruled both of those out. It's purely depth-driven during boot, fixed in the OS.

 

[liamur]

Nice! I have logic analyzer records that should be a boot into 4-bit mode, but they don't show 102Hz....but I do have an oscilloscope record of 102Hz FLM. I trust your analysis either way. I was much more focused on GSC's data format (and thus just its data lines) than its clock signals.

Looking at the DB-Lite driver, the comments in the skew table on line 1071 say that 4-bit mode on a 4-bit TFT runs at 87Hz, even though the table value for that mode is different than 2-bit mode. (I think the 180 uses a 4-bit TFT, but I don't know.) I suspect the programmer in charge of the table just copy-pasted for the comment's third column.

On a related note, I noticed that if I boot my 160 into 4-bit mode, the screen briefly flickers and wobbles when the Mac OS progress bar loads to about 15%. I suspect that's the switch-over from the ROM GSC driver to the OS driver, and clearly they aren't configuring the chip in exactly the same way. I also wonder if there are different versions of the DB-Lite driver---the source code we have is from System 7.1, but I observe that behavior on System 7.5.5. Maybe it doesn't always do that?

 

[demik]

Very cool! Looks like we were many working on this display thing. You guys tackling grayscale and color have some skill.

Have you looked at the GSC registers and init from the super mario source code if there is any hints ? I can search them again if you want

 

[liamur]

The code snippets I posted were the only references to GSC registers in the DB-Lite driver I was able to find. There might be more, but I don't think the driver has to do very much besides identify the display panel connected, configure GSC to drive it, and tell the OS what bit depth to render at.

I would definitely be interested if you find more GSC-related code, in that driver or elsewhere in the source code. invenexus's discovery of the three active matrix frame clocks shows that more eyes on this research is a good thing.

On that thought, I wonder how the GSC display ID pins read on the Duo. The 210/230 schematics show that all three pins are routed to the display (instead of just one as we infer on the 16x/180). If the DB-Lite driver is used by all the grayscale-capable PowerBooks, then the GSC ID pins must be configured the same way between models, and switch the same way depending on what screen is connected.

 

[Arbee]

Known GSC panel IDs are 4 for PB150, 5 for 160/180, and 6 for Duo 210/230/250.

 

[Froggy814]

Are inverter board pin 9 and 10 the same as the ones coming on the separate cable that comes from the inverter board?

 

[liamur]

I don't really understand the question, but I'll try to answer. The connector on the interconnect board that the inverter board sits in has labeled pin numbers. Pins 9 and 10 of that connector go to the LCD ribbon.

I don't know exactly what those pins do. These displays usually expect about -20V on a specific pin to generate the pixel bias, but the PowerBook doesn't appear to generate this voltage, which means the display is probably making it itself. I measure a resistance across inverter board pins 9 and 10 that changes as I adjust the contrast potentiometer, and my current best guess is that the bias generator on the LCD measures the contrast pot to adjust its output voltage.

 

[Froggy814]

Sorry, that wording is very bad I just realized...

Here is a photo of the separate cable I am talking about, would this one be for brightness then?

 

[liamur]

That's the high voltage supply to the backlight, so yes.

 

[Froggy814]

Thank you very much!

 

[invenexus]

Back after a month away (work + university prep ate all my time) but I've got something to show for it.
I now have a verified, working capture of the PowerBook 180's GSC bus in active-matrix mode. Two 74LVC245As (5V→3.3V) into an RP2350 (Adafruit Feather, PIO + DMA), sampling FPDATA[0..7] on the falling CL2 edge, writing the full 128,000-byte frame. First photo shows the setup — it's not pretty, but it works.
To verify the chain I captured the same static screen twice and compared byte-by-byte: zero differing bytes across two independent captures. The other images are frames exported straight from the capture buffer — pixel-identical to what the internal panel shows.
Findings from the data:

1. Frame geometry confirmed end-to-end: exactly 320 bytes/line × 400 lines, no vertical blanking — matches my earlier LA measurements, now verified by full-frame capture.
2. The nibble LSB never appears set. Across entire frames only the values 0/4/8/14 show up — bit 0 of each nibble stays low. Caveat: I haven't yet ruled out my own wiring on those two lines (FPDATA0/FPDATA4), so treat this as preliminary. If it holds up on the 5V side, the 180's GSC drives effectively 8 grey levels here — which would fit liamur's earlier observation about D4. Will verify and report back.
3. Polarity is inverted: high nibble values = dark. Value 14 is the light desktop background.

Sampling on the falling CL2 edge (Sharp convention) turned out correct on the first try.
Next step is the output side HSTX/DVI to a modern monitor. Happy to share the sketch and wiring protocol if anyone wants to replicate.

 

[liamur]

Cool! How did you decode the samples into images?

I will point out that the exact definition of "inversion" is definitely dependent on perspective. From QuickDraw's perspective, higher values = darker colors (ignoring the complexity of Color QuickDraw rendering to an actual color device), and the screen behaves exactly that way. I do agree that most displays have higher values = lighter color, and from that perspective it definitely is backward.

 

[Froggy814]

Back after a month away (work + university prep ate all my time) but I've got something to show for it.
I now have a verified, working capture of the PowerBook 180's GSC bus in active-matrix mode. Two 74LVC245As (5V→3.3V) into an RP2350 (Adafruit Feather, PIO + DMA), sampling FPDATA[0..7] on the falling CL2 edge, writing the full 128,000-byte frame. First photo shows the setup — it's not pretty, but it works.
To verify the chain I captured the same static screen twice and compared byte-by-byte: zero differing bytes across two independent captures. The other images are frames exported straight from the capture buffer — pixel-identical to what the internal panel shows.
Findings from the data:

1. Frame geometry confirmed end-to-end: exactly 320 bytes/line × 400 lines, no vertical blanking — matches my earlier LA measurements, now verified by full-frame capture.
2. The nibble LSB never appears set. Across entire frames only the values 0/4/8/14 show up — bit 0 of each nibble stays low. Caveat: I haven't yet ruled out my own wiring on those two lines (FPDATA0/FPDATA4), so treat this as preliminary. If it holds up on the 5V side, the 180's GSC drives effectively 8 grey levels here — which would fit liamur's earlier observation about D4. Will verify and report back.
3. Polarity is inverted: high nibble values = dark. Value 14 is the light desktop background.

Sampling on the falling CL2 edge (Sharp convention) turned out correct on the first try.
Next step is the output side HSTX/DVI to a modern monitor. Happy to share the sketch and wiring protocol if anyone wants to replicate.

Cool... I was about to work on this! I probably still will. But glad to see this.