PowerBook reverse engineering for fun and no profit

[liamur]

There's a lot to investigate in these machines. I'm focusing on the PowerBook 140-180, excluding the 150 and color models, because they're machines that I already have. I will be writing up these somewhat loosely collected thoughts into slightly more organized content on the website linked in my profile at some point, primarily for preservation. If you have your own info to contribute, please do! There's a lot to say, so expect info in semi-frequent posts as I collect my thoughts and discoveries.

Let's start with the display. The schematics for the 14x/170 are available and include the pinout of the interconnect cable and connector, so I mapped out the pins on my 145B's interconnect board with my multimeter. The pinout is as follows (the underside of the interconnect board numbers the pins on every connector, helpfully):

1	GND	10	GND	19	M_F
2	FPDATA[7]	11	FPDATA[1]	20	5V
3	FPDATA[6]	12	FPDATA[0]	21	5V
4	GND	13	GND	22	Inverter board pin 10
5	FPDATA[5]	14	CL2I	23	STN_MODE
6	FPDATA[4]	15	GND	24	GND
7	GND	16	CL1I	25	DISP_BLANK/
8	FPDATA[3]	17	GND	26	Inverter board pin 9
9	FPDATA[2]	18	FLM_F

The signal names are taken from the 140/170 schematics, and they're fairly sensible so I'll use them too. You can see the direct lineage from the Macintosh Portable here: the Portable exposes its LCD driver pins on its external video connector, but it branches them off from the driver chip and LCD through ferrites. The internal clock signals end with the letter I, like CL2I, and the external signals end with an X. Obviously the PowerBooks keep their LCD signals exclusively internal, but Apple kept the "I" in the names. I don't keep the I around except for direct reference to the schematic. A slash at the end of a name indicates an active-low signal.

These signals are:

• FPDATA: an 8-bit data bus
• CL2, CL1, FLM_F, M_F: clocks
• STN_MODE: binary signal telling the video chip what kind of display is connected, see below
• DISP_BLANK/: display blanking signal from the Power Manager
• Inverter board pins: as far as I can tell, the contrast potentiometer is directly connected to the display. I suspect the high-voltage drive circuit is controlled by it.

I can make sense of these signals, but that requires an explanation PowerBook video chips, so this particular post will end with that. The Portable used a chip called Omaha that sits on the 68K's bus and addresses its own 32K of video RAM. The 68K writes to that VRAM, and Omaha independently scans the display. The Portable calls FLM_F and M_F just FLM and M (I have no idea what F stands for). Interestingly, the M signal is actually generated by the MISC GLU chip on the Portable, derived from FLM. This entire procedure is described in detail in the Macintosh Portable dev note, and here Apple actually made a small mistake! They claim that FLM is a vertical sync signal that pulses every 16.32 ms, or "61.8 Hz". 1/61.8 = 16.18 ms, not 16.32 ms. Not a big deal, but worth noting. The Portable's video is also well understood by the community.

The PowerBook 100, 14x, and 170 use a different LCD driver chip called Omaha2 (U4 on the CPU board), which we know is called Omaha2 because it's labeled on the schematic. Omaha2 is located on the PCB board and is the same chip on passive matrix and active matrix systems. Omaha2 is almost the same as Omaha, but adds STN_MODE and a special STN_CLK as an input, and is capable of generating its own M signal. Omaha2 is called the DDC (Display Driver Chip) in the 140/170 dev note, but Apple stopped giving detailed explanations of how it works. I assume this is because they weren't breaking out the signals on an external connector anymore.

The PowerBook 16x and 180 use a completely different chip that Apple calls the GSC (Gray Scale Controller) in the 160/180 dev note. GSC adds support for grayscale, of course, and 128K of VRAM instead of 32K. There's no schematics available for these models that I can find, but I have done some original research.

Omaha, Omaha2, and GSC all have 16-bit data interfaces that are also byte addressable. Keeping GSC on a 16-bit interface seems kind of tight, considering that it has to handle up to 4x the amount of data as Omaha and Omaha2.

The same LCD driver chip is used on all versions of in-family CPU boards, but it is connected to active-matrix and passive-matrix displays. The STN_MODE pin is pulled up on the CPU board, and if you inspect the back of an active-matrix display, you can see that pin 23, STN_MODE, is connected to the ground plane. STN_MODE measures 5V (logic 1) when a passive-matrix display is connected, and thus tells the video chip whether a passive-matrix ((F)STN) or active-matrix display is connected. As a result, we can conclude that the two display types require different signals, and this is observable if you power a PowerBook with no display attached and change the logic level on STN_MODE. What can we conclude from this? Well, for one (ignoring the inverter boards), all monochrome/grayscale displays are compatible with all monochrome/grayscale PowerBooks, assuming you have the right display cable. The video chip is told how to drive the connected display, and there's no way to tell that chip if a passive-matrix Rev. A, B, C, or some other display is connected---all it knows is if the display is active or passive. Additionally, GSC and Omaha(2) have the same amount of information about the connected display, so any screen from a monochrome computer should be compatible with a grayscale computer, and vice versa. The one caveat with this is that it's possible that, for example, Apple chose passive-matrix Rev. A displays before they decided that future computers would have grayscale support, and thus Rev. A displays don't support grayscale, but I doubt this. If somebody would like to test, I'd be interested in the results! I only have one Rev. C display and it works in both my 145B and my 160.

I have so far figured out Omaha2's data format in passive matrix mode, so that will be my next post.

 

[liamur]

Let's talk about Omaha2 in passive-matrix mode. luRaichu's recent display cable scans show that the pins that are actually connected to the video chip are the same between a passive-matrix and active-matrix display. This means that the signals are probably similar. If you set STN_MODE high or low while Omaha2 is running, you can see that the clock timing and data signals change. I could see that the data lines were still data lines, and that the clock lines were still clock lines, but that was about it. I spent a lot of time staring at logic analyzer graphs before giving up and trying another solution: probing the display.

I have a Rev. C (Sharp LM64P58) display panel. I assume that what I'm about to share is similar for other display versions, but I don't know. The Rev. C display is driven by LCD drivers and some auxiliary components on three PCBs:


My particular display is kind of weird: the lower half is slightly lower contrast, especially in 16-grey mode, than the upper half. This gave me the suspicion that the screen is driven in separate halves, which is supported by the two sets of column drivers. Normally, passive-matrix displays need m + n drive signals, because then you can select from row m and column n to access any pixel. (This is also why passive-matrix displays have vertical and horizontal artifacting: that selection process is imperfect and some amount of charge tends to leak across the row or column). Two sets of column drivers means that the screen is being driven with m + 2n drive signals, and that the upper half must then be independently addressed of the lower half. You can see this in action in the picture below, which has the display set to 16 greys and the contrast slightly lower than I would consider comfortable viewing.



The bleed from the white area around "Macintosh HD" stops halfway down the screen, and the bleed from the scrollbar stops halfway up the screen. The upper and lower halves are driven independently. (Note that the picture above is from a 160, while the

I then probed the display PCB itself. First of all, all 8 lines of the FPDATA data bus are routed through IC3, a 74HC540 inverter, which is wired to always be enabled. Then, the upper half of the inverted data byte is routed to the upper half of the display, and the lower half is routed to the lower half of the display. The little white ribbon cable things are connected as follows, when looking at the screen such that the components of the left-side PCB are facing up and so that the "DC/DC CONVERTER" text is right-side up (90 degrees counterclockwise from the image above, in other words):



The question mark pins are pins I couldn't figure out, even from probing the analog parts of the board. I suspect they're related to the high voltage pixel drive circuit, but I'm not sure. We can conclude from this discovery that the upper half of the display is driven with the high nibble of the data bus, and that the lower half is driven with the low nibble. This is further confirmed by looking at the signals on the logic analyzer. Here's D7, and a rising edge counter set to count edges of CL2 and reset on CL1:

CL1 was the line clock on Omaha, CL2 was the byte clock, and FLM_F was the frame clock. We can see that in Omaha2's passive-matrix mode, CL2 lines up with new data on the data bus (my logic analyzer caps out at 24MHz, probably there's some slight rise time difference there), so CL2 is probably a byte clock. There are 160 CL2 cycles per every CL1 pulse, and 160 nibbles = 80 bytes at 1 bit per pixel. If we count CL2 cycles per FLM_F pulse, we get:

If we assume that FLM_F is a frame clock like it is with Omaha, we see that there are 32000 CL2 cycles per frame. One 640x400 frame at 1 bit per pixel is 256000 pixels / 8 pixels per byte = 32000 bytes, so there's 32000 bytes per frame. What can we conclude from this?

• The display is probably scanned left-to-right, two nibbles at a time. The first line of each half of the display is scanned at the same time, 4 pixels per CL2 clock, unless the data format is something weirder.
• We don't know if the display halves are scanned top-to-bottom or vice versa.
• CL2 is a byte clock, CL1 is a line clock, and FLM_F is a frame clock.

There's more to talk about here, but I'll split this post to keep it from growing too long.

 

[Froggy814]

This is so cool! I can't wait to see more! Why did you decide to start with the display first?

 

[liamur]

I should clarify to say that the D7-D0 signals above are the same as the FPDATA[7]-FPDATA[0] signals from the schematic, and that the display drivers themselves see these signals inverted. Also, the "upper half" ribbon is JP1, and the "lower half" is JP2. I should have done a better job explaining what the signals look like visually in passive-matrix mode:


Zooming in, we see:


Let's dissect the signals. FLM_F and CL1 are pulses and otherwise low. CL2 is a constantly cycling clock. I'm happy to share my logic analyzer captures if anybody wants them, but I doubt they'd be of much use.

I made some really rudimentary C programs to write to screenBits.scrnBase so that I could see how Omaha2 reacts to different display content in passive-matrix mode. I actually wrote a lot more than you see here, but these are the ones that I think are sufficient to draw a complete conclusion. I apologize for having no pictures, but I couldn't really take any because I didn't have the display connected to the laptop while I was working on it. The first is called MonoScreen, and it just sets the first 200 lines of the display to black and the lower 200 lines of the display to white. This confirmed that my split-screen suspicions: D7-D4 were all 1, and D3-D0 were all 0, but that's about as simple of a pattern as the screen can have.

The next test program is called MonoScreenStripes2 (not that anyone needs the names...), and it sets the upper half of the display to horizontal stripes ending at the right side of the display, first white (QuickDraw 0), then black (QuickDraw 1). The lower half of the display is set to vertical stripes, three bytes white (0), and one byte black (1), aka 24 pixels white, then 8 pixels black. This causes D7 through D4 inclusive to be high for an entire CL1 period, then low for another CL1 period, then high again and so on. D3 and D0 are then all low for 6 CL2 cycles, then high for 2 CL2 cycles, then repeating. In other words, D7-D4 are all identical in timing and shape, as are D3-D0. Here's what they look like on the logic analyzer:



D3 zoomed in:


This is a problem: the corresponding logic levels for white pixels on the top and bottom of the display don't match. We can however conclude that a nibble on the data bus corresponds to left-to-right sequential pixels: 6 CL2 cycles × 4 data lines = 24 pixels (the white part), and 2 CL2 cycles × 4 data lines = 8 pixels. The screen is 640 pixels wide, and one vertical stripe period is 32 pixels, for 20 stripe periods across one line of the display. This means that the last 8 pixels of each line in the vertical stripes region are black, and if the display scanned right-to-left, we would see 2 CL2 periods in one state and then 6 CL2 periods in another state after the line clock.

With those two, we know that the screen scans left-to-right, 4 pixels at a time, one nibble per pixel. We don't know what logic levels map to what pixel values, and we don't know what vertical direction the screen scans.

The final test program is called MonoScreenUpperTest. This sets the first line of the display black (1), the second line to white (0), and the third to black again, then the rest of the screen white. The result on the data lines is that D7-D4 are all high for one CL1 period before the FLM_F pulse, then low for one CL1 period, then high for one CL1 period, then low until it repeats. I conclude from this that FLM_F is a frame clock, but it's a frame clock that comes at the end of the first line. With that assumption, a 1 on the data lines maps to a QuickDraw 1 and a black pixel on the display, and a zero maps to a QuickDraw 0 and a white pixel on the display. This aligns with the vertical stripes from MonoScreenStripes2: 6 CL2 cycles low equals 24 pixels white, and 2 CL2 cycles high equals 8 pixels black, and tells us that the display is scanned top to bottom. I conducted a similar test that set the same lines to the same color, shifted downward by 200 lines, and D3-D0 behaved the same.

Here's what we can conclude from all this about Omaha2 in passive-matrix mode:

• CL2 is a byte clock, CL1 is a line clock, and FLM_F is a frame clock. FLM_F comes at the end of the first line instead of at the start. This is notable because FLM_F comes at the start of the line in active matrix mode.
• The upper nibble of the data bus corresponds to left-to-right pixels on the upper half of the display (starting at line 0), in the order D7 D6 D5 D4. The lower nibble of the data bus corresponds to pixels on the lower half of the display in the same way (starting at line 200), in the order D3 D2 D1 D0.
• One line, demarcated by CL1, is 160 bytes, or 80 lines. Two lines are scanned at one time, starting with lines 0 and 200, and incrementing down the display.

If you want to make a modern replacement display for an Omaha2 PowerBook, should you set it to passive-matrix mode? Probably not. I can visualize a display input solution for PIO on an RP2 microcontroller, and it's way more complicated in passive-matrix mode than active-matrix mode. You'd have to read the data bus 8 bits at a time, synchronized to the clock signals (relatively easy), separate the nibbles (probably easy), and get those into byte-organized memory on a byte-oriented system (hard, and even harder with DMA, which is generally desirable). Active-matrix mode scans 8 pixels at a time across the display without a split halfway down and you can just stream it directly into memory.

I'll look at GSC next, but I can tell from just a cursory glance that the signals are a lot more complicated, so it might be a while.

 

[liamur]

This is so cool! I can't wait to see more! Why did you decide to start with the display first?

These PowerBooks seem relatively under-researched compared to, say, the Portable (which is reasonable considering how weird that computer is). The displays are the part that fail the most, and as far as I can tell the least researched out of all the PowerBook components, so I thought it would be smart to start there.

 

[Froggy814]

These PowerBooks seem relatively under-researched compared to, say, the Portable (which is reasonable considering how weird that computer is). The displays are the part that fail the most, and as far as I can tell the least researched out of all the PowerBook components, so I thought it would be smart to start there.

Smart! I wouldn't have thought of that!

I am wondering, it sounds like the display has the same pinout as the Portable, so would a adapter for the Portable work on the Powerbook?

 

[SuperSVGA]

If you want to make a modern replacement display for an Omaha2 PowerBook, should you set it to passive-matrix mode? Probably not. I can visualize a display input solution for PIO on an RP2 microcontroller, and it's way more complicated in passive-matrix mode than active-matrix mode.

The DSTN format is more complicated, but still plenty doable on RP2040/RP2350.