Mac Portable Video: Where to tap the source?

[Trash80toHP_Mini]

I've outlined a direction I'd like to go with my extra Luggable: Macintosh Portable: LuggablePi

It involves installing (it's looking like it will fit) an 11.6" 1080p LCD in a customized 3D printed bezel. There'd to be some flavor of Pi baking in the HDD's cubic for playtime in that world and I'm trying to figure out how to use that Pi filling to adapt the Portable's video output and throw it up on that big, beautiful LCD so that it looks juuust right for 68000 playtime.

 I was thinking in terms of tapping the LCD cable connector on the mobo, feeding it to the Pi for translation into something it can display on the 1080p LCD. That was after considering use of the Portable's video out setup, but IIRC it was never really used or documented? Remembering the bit-banging approach to some of this kinda crap, I hit the docs:

DDC (Display Driver Chip)
The DDC provides the Macintosh PowerBook 100 computer’s interface to the LCD (liquid crystal display). Its primary function is to keep the computer’s main processor from having to refresh the screen (LCD display), thereby allowing the processor to do more useful work. The DDC generates horizontal and vertical synchronization pulses and all other signals necessary to make the flat-panel display work. It also supports its own video 32K x 8-bit SRAM (static RAM). In addition, the DDC limits the CPU from refreshing the display and thereby allows the CPU to do more useful work.

The video port seems a no-go?

Converting the signals meant for the stock LCD  .  .  .  I have no idea, but that'd be my fully reversible preference!

Might banging the snot outta that SRAM IC be the easiest in terms of signal/data conversion? Soldering crap to the mobo of even my "Hackable Lugggable" goes against the grain for me these days.

What do you GPIO cowboys think of wedging the video feed at the LCD cable socket? Non-trivial or impossible?

 

[Gorgonops]

What do you GPIO cowboys think of wedging the video feed at the LCD cable socket? Non-trivial or impossible?

My gut feeling is somewhere right on the cusp between non-trivial and impossible. I don't know what the refresh rate of the portable's screen is; if it's 60hz then we're looking at a dot clock of at minimum 18.5mhz. (This is assuming no front/back porches. If it has CRT-ish timings then it's going to be more like 22-something-plus mhz.) I've seen references that claim that the GPIO pins can be *toggled* at speeds greater than 20mhz with a native C library, but there's a lot of caveats to that. (IE, this is in a loop that does *nothing* but do a toggle; it's not actually hitting RAM, and it's also not constant; when running Linux it'll regularly drop samples as it's interrupted by the scheduler/interrupts/whatever. And this is also a write, there are a lot of conflicting claims about how fast you can actually *input* data on the pins. Consensus seems to be anything faster than 10mhz or so will be a problem.) There are also references that claim the SPI clock can be turned up to 32mhz, *maaaybe* if you had some sort of buffering circuitry to compensate for the regular pauses you could grab the data using the SPI data pump? But you'll still have to cram the data received into a framebuffer and scale and display it. That latter requirement *probably* rules out going bare metal on the Pi instead of running Linux, because last I checked the support for running the GPU from bare metal was somewhere between minimal and non-existent? (Granted, this could have changed; I haven't been doing any development on mine.)

You don't happen to have the part numbers for the original LCD panel, do you? Granted, the chances the datasheet is online somewhere is probably pretty low given the sheer age, but having it would help a *lot* in trying to noodle this out.

It might actually be significantly easier to drive the Portable's original LCD display from the Pi, ironically enough, but of course that would limit you pretty badly on the Pi side. I doubt X11 has very good support for 1 bit framebuffers anymore.

 

[Gorgonops]

... and, of course, it does also go without saying that if what you really want is a Mac Portable-shaped Pi that can still run 68k Mac programs the Pi should be able to run an emulator several times faster than the Portable's native speed, so there's a reasonable argument to be made for just gutting the thing entirely and using the *ample* space thus freed for things like your ADB keyboard converters, a shedload of batteries and a charging circuit, the contents of several briefcases...

 

[Trash80toHP_Mini]

HRL 1010-10-110i    ASSY HLD 1010-03-001

Zero/Cap O and One/Cap I have no differentiation, so searching could be a crossword puzzle.

No mfr's mark, but every IC is either a Toshiba T7778A of a T7900.

Just wrapped it up for scan to .PDF at work, maybe the PCB will tell us something?

Hieght's about identical to the 11.6" panel > 1080p screen in the Pavilion NetBook but it's a bit wider. Thicknesses make me think we can bolt the NetBook's LCD up to a piece of FRP notched out for the undisturbed clips in the lid. Might even need to use a standoff. There is a LOT of cubic just in the lid for hardware and that one bigass PCB as well.

Nope, not a standalone Pi project, this one's gotta be an inverted Pi-a-la-mode/Luggable confection.

Are we looking at the likes of a nasty CPLD/High speed digital signal processing rabbit hole?

edit: now I've got two medium and one large of the project boxen out and cluttering up the joint. Mania's fun within limits, but REALLY messy. :blink:

 

[Gorgonops]

Here's a thread from someone looking in vain for information about the same LCD. Amusingly enough it looks like the same guy posted the question on pretty much every web forum he was a part of, including the Straight Dope website. Here's a thread in German who I'd also suspect of being the same guy that includes a very possibly incorrect pinout, but no usage information. Actually, maybe I take back that "very possibly incorrect" part because the named signals match up extremely well with the pinout of the 15 pin connector on the back of the Portable; it looks like that connector is very close to just being a mirror of the LCD connection minus some connections that appear to be for brightness/contrast PWMs.

So this does actually tell us something, which is the output to the LCD is an 8 bit parallel bitstream and *not* a CRT-esque single-dot-at-a-time raster. If you have access to a high-speed memory oscilloscope it might not be *that* hard to reverse engineer what the datastream to drive the LCD looks like; it might just be as simple as triggering the frame sync signal to reset an address counter in the LCD to top-of-frame and then just linearly shoving out 32,000 data bytes (8 pixels per byte) with the data clock pulsing when the data's valid. I suspect it's *slightly* more elaborate than that, but how much depends on the internal layout of the screen itself. It looks like 8 bit parallel drive is at least a semi-standard interface for "controllerless" LCD panels like this...

AHA! Here's a datasheet for an LCD driver designed to convert CRT-intended signals to LCD drive signals. It has at least *some* useful information about what the data format coming out on the LCD side looks like in different modes, including 8 bit monochrome. It doesn't substitute for actually having the datasheet for your particular LCD panel, but it has enough theory that it might make it easier to interpret what you're seeing if you tried reverse engineering it.

But, anyway, all that aside: yes, this is a "high speed digital signal processing rabbit hole". Unless the frame rate coming from the Portable's LCD controller is quite low I don't think capture/conversion in software on the Pi by just jumpering the lines to the GPIO header is going to be particularly feasible. Not going to quite rule it out entirely, but at the very least I think you'll need some hardware help (like a high-speed parallel-to-SPI buffer? Or maybe USB? That's a thought.) An FPGA could probably make easy work of converting the Portable's output directly into drive for a more modern LCD, although adding non-integer scaling would suddenly make that a lot harder. (IE, it might be pretty easy to drive a 1280x800 LCD because the simple expedient of scan doubling will do the needful, but filling up a 1366x768 or 1080P panel would be genuinely a #$%.)

 

[Gorgonops]

some hardware help (like a high-speed parallel-to-SPI buffer? Or maybe USB? That's a thought.)

Actually, the more I think about it the more I feel like that *with* some hardware help it might be doable. I mean, after all, even at 60 frames per second it's "only" about two megabytes a second.

Here's a little USB 2.0 microcontroller dingus that includes a 4k FIFO buffer capable of ingesting 8 bit bytes at up to 48MB/s, 16 bit words at 96MB/s and can be ordered on a dev board for less than $5. (Or maybe $6.50 if you don't want to try to find the dang thing on AliExpress.) The FIFO is a good 1/8th the size of an entire frame and the upstream data rate is full USB 2.0 "High Speed" (480Mbps, or 60MB/s theoretical) so I could actually see just dropping a little glue between one of these boards and the LCD output on the Portable's motherboard and writing an application that constantly just grabs frames in, I dunno, 1K chunks of data off the USB bus and writes them into an OpenGL ES texture which is mapped to scale up to full screen. (With aspect ratio correction, of course.) Writing the app for that might almost be "easy", and if you run into an interruption that causes a FIFO overflow it's not the end of the world, just keep the data from the last frame and overwrite it when the next one comes through.

I wonder if anyone's made a "frame grabber" device with one of these things before.

 

[techknight]

The macintosh portable is indeed an 8 pixel per clock display. As far as timing, I never scoped them although I should. 

However, the display has 2 pixel clocks which doesn't surprise me as it is a dual scan display. 

The one thing I am not sure of though is if it's 8 bits are split into each nibble for odd/even scan. 

View attachment M5120 Video.pdf

 

[Trash80toHP_Mini]

Looks like it may just barely be possible to pull that rabbit up outta the hole by its ears after all? :?:

piccie:



scan:

View attachment image2018-01-23-180155.pdf

That must be the 150 DPI version, the 300 DPI scan is conspicuously absent from my mailbox. :/

edit: I can get a better scan if I desolder a couple of caps if needs be.

 

[Gorgonops]

The datasheet for the LCD driver talks about LCDs having several different possible arrangements; I don't see one for even/odd scan, but there is a configuration in which the top and bottom halves of the LCD are essentially treated as two screens (dual scan?) and, yeah, in that case it looks like each half gets a 4 bit nibble. (So it essentially looks like 2 4-bit 640x200 screens stacked atop each other.)

I don't necessarily see that as a dealbreaker to using something like that USB 2.0 widget to just swallow up all the bytes and let the CPU sort them out, since for display the raw data is going to have to be reformatted into a different pixel format anyway. (I don't know what bitmap formats the Pi's GPU accepts for textures so it's remotely possible that's not true, but I wouldn't count on it.) I think it's mostly a matter of figuring out just how much glue you'd need to mediate the data transfer.

 

[Trash80toHP_Mini]

It's great to know it's at least possible to do scaling of Luggable video.

I was going to do a graphic showing 1280x800 letterboxed within 1920x1080. That'd be a 140 pixel border bottom and top and 320 pixels on either side. Not all that pretty, but we could have the Pi throw the rim around the display in Platinum? :lol:

 

[Trash80toHP_Mini]

Is there any spec on what the pixel count on the external connector might be? The only reason I can think of besides more pixels would be 2bit(?) compact Mac grayscale output? If it's 640x480 single bit that'd just look like hell in the middle of 1080p.

Offhand, would 1366x768 match the Luggable's aspect ratio of 640x400 any better than 1920x1080? I'm too crosseyed to run the numbers ATM. :blink:

 

[Trash80toHP_Mini]

Haven't found a picture of a bare 11.6" 1080p panel, but I just found an 11.6" 1366x768 panel that will definitely fit:



I really want 1080p for movies though, not that I could afford to buy the parts required for this insanity. :mellow:

I wonder how much an outsourced 15" X 9.25" printed bezel might cost?

Never mind the rabbit hole, looks like this is heading straight into a money pit! But boy might it be a cool toy. Offshoot might be replacement of the spate of destroyed LCDs in the various PowerBooks. The PB100 is a bit cramped, but any 'Book with a bad screen and no real need for its FDD might be a candidate for this sort of thing. Sure would be a neat thing to have an active matrix, high res LCD/Pi setup in the 150. []

 

[Gorgonops]

Keep in mind the plan we're hashing around here depends on using the Pi's GPU to do the scaling. I can't say offhand how good its likely to look. Since you're going to have to write the software to make this all happen anyway you could try banging together a prototype display app that uses opengl to stretch a 640x400 static bitmap to various dimensions. The pi's GPU does support some antialiasing but I wouldn't expect miracles. By definition the 1080i stretch will look better because each of the 400 source pixels will be transformed to "almost 3" dest pixels instead of "awkwardly just under 2" for 1366x768. To preserve the aspect ratio presumably you'll blackbar the sides. (If the portable's original screen actually has square pixels it has a 16x10 aspect ratio. That would be the attraction of finding a suitably sized 1280x800 display, aspect ratio is identical. Displays that size were common for a while on fancier netbooks and android tablets.)

Re: bit depth on the external connector, its lines are literally wired in parallel to the LCD plug according to the schematic techknight attached. It's mono.

 

[Trash80toHP_Mini]

I wonder if Apple was planning to do a projection screen? Seems a waste to put LCD outta the ass end of a Portable?

edit: 1920x1200? 10.1" is way too small anyway.

 

[Trash80toHP_Mini]

BINGO!!!!!!

EYOYO 10" IPS-LED-HD-1280x800-VGA-AV-HDMI-LCD-Monitor

It's almost a perfect fit for the standard bezel! []

edit: didn't understand much at all of what you were saying above, but this panel has a USB 2.0 input, does that help?

View attachment 21326

Lots of thickness to trim away, but the side view makes it look like mostly air inside the housing.

Might need to mill away the beveled opening in the real deal bezel a bit, but not bad!

 

[Trash80toHP_Mini]

... and, of course, it does also go without saying that if what you really want is a Mac Portable-shaped Pi that can still run 68k Mac programs the Pi should be able to run an emulator several times faster than the Portable's native speed, so there's a reasonable argument to be made for just gutting the thing entirely and using the *ample* space thus freed for things like your ADB keyboard converters, a shedload of batteries and a charging circuit, the contents of several briefcases...

Heh! Realized last night that you've joked your way into a three mode LuggablePi. I've never run any kind of Mac emulator, so I'd not thought of it at all. Running games on that accelerated LuggablePi under Mac OS on an emulator in backlit color on a 4x(?) pixel playing field would be incredible experience. Is emulation video resolution flexible enough to do a non standard 1280 x 800 TPD format?

< wonders about angling a Duo 2300c down into the briefcase void from the back to mate with a hacked MiniDock  .  .  .   :lol: >

 

[Trash80toHP_Mini]

Out of curiosity, is there a System 6 or 7 emulator that runs under X on a beige G3?

 

[BadGoldEagle]

Mini vMac should work on that beige G3...

 

[MrGasS27]

Out of curiosity, is there a System 6 or 7 emulator that runs under X on a beige G3?

http://www.gryphel.com/c/minivmac/dnld_std.html

Mini vMac, there is a PowerPC binary available.