Jump to content
Sign in to follow this  
LaPorta

Macintosh Portable Video Adapter

Recommended Posts

Has anyone ever made an adapter for the Portable's video out port? I know it produces a digital signal that needs to be converted to work with any sort of standard monitor. I'd be interested in figuring out how to make one.

Share this post


Link to post
Share on other sites

There was a thread some months ago about this. As I recall the TL;DR is that the output port is basically just a paralleled copy of the LCD drive lines. I don't think anyone has succeeded in unearthing the datasheet for the Portable's panel, which would help a lot with trying to build an adapter, but you could probably figure out enough to do it with the help of a good oscilloscope.

 

How difficult the actual converter would be depends on what frequency it runs at and how many fields the panel is broken into. My guess is you'll need a dual-ported video buffer (32k will do) to paper over all the differences.

Share this post


Link to post
Share on other sites

My impression was they never actually released an adapter for the port. Not in a position to check but my recollection is that there's an Apple KB article addressing this that recommends SCSI graphics adapters as a workaround. (There may also have been a really rare video card that went in the internal slot?)

Share this post


Link to post
Share on other sites

So far as I can see in the KB from Apple:

 

https://support.apple.com/kb/TA45501?locale=en_US

 

This line is the most interesting: "Sayett Technology's DataShow, an overhead viewplate that connects

directly to the Portable's Video Out port"

 

Apparently this device actually did work with the video port. If anyone knows where to find one is another story...

Share this post


Link to post
Share on other sites

I took a look at the thread that Gorgonops referenced. It looks like that guy was trying hard to do some crazy mods to get a 1080 LCD packed into the Portable. All I'm attempting to do is get some sort of VGA-style output, but it looks like that would be really involved. I am lucky that before I knew all of this, I didn't ruin the LCD monitor that I have by hooking it up accidentally :).

Share this post


Link to post
Share on other sites
1 hour ago, LaPorta said:

Apparently this device actually did work with the video port. If anyone knows where to find one is another story..

I'd be willing to bet a shiny new nickel that device was based on an LCD that was compatible, or close to it, with the built in one.

Share this post


Link to post
Share on other sites

Well, my link is providing a picture and valid part Number M0251 for an Apple product.

 

Maybe the product was canceled at some point.
 

Share this post


Link to post
Share on other sites
1 hour ago, bibilit said:

Maybe the product was canceled at some point.

The title of the KB article that I vaguely remembered, linked above and now here is "Macintosh Portable: External Video Adapter Canceled (6/96)"

 

Quote
Whatever happened to the promised Macintosh Portable video adapter?
 
 
In September of 1989, when Apple introduced the Macintosh Portable, Apple announced they intended to ship a video adapter which would let users take advantage of external displays.

Since that time, a variety of developers have introduced products which provide the external video functionality customers require. For that reason, Apple decided not to offer a video adapter.

Customers in need of external video support have a wide range of products to choose from, including: (....)

 

So, yes, it was cancelled, apparently. Because of the inherent complexity of what it needs to do it would have been painfully expensive for what it was capable of, which probably helped motivate the final decision.

Share this post


Link to post
Share on other sites
On 11/25/2018 at 5:08 PM, Gorgonops said:

I'd be willing to bet a shiny new nickel that device was based on an LCD that was compatible, or close to it, with the built in one.

I have no doubt you are correct. Something like that would be perfect for an LCD that would be used with an overhead projector.

Share this post


Link to post
Share on other sites

Might as well do it from scratch given the chances of finding a prototype and the cost involved in obtaining it.

Share this post


Link to post
Share on other sites

Broadly speaking I think it would be relatively easy to make this adapter if you had the specs for the LCD (or the tools to reverse engineer which of several likely logical geometries it's laid out in) and had some skill in programming FPGAs. As noted, the simplest approach would be to set up a dual-ported 32kb framebuffer large enough to hold a monochrome 640x400 grid of pixels that has glue that emulates the LCD interface on the input side and an output stage that spits out a VGA compatible signal. Sample code for doing the VGA part on an FPGA is readily available, you just need to work out how to handle the input data. Could probably build the whole thing using half a dozen components (figure a voltage regulator, a few input level shifters since the FPGA will probably be a 3.3v part, and some resistors for the VGA output), a little $20 FPGA dev board like this would be serious overkill for the job.

Building it with discrete components would be an ugly task, though.

Share this post


Link to post
Share on other sites

Reverse engineering something like the Radius TPD Video Card for the SE and reducing the layout to fit SMT chiplets and cannibalized custom Radius ICs onto the two sides of a Portable PDS card would be one approach. The slots are not the same pinout, but are signal compatible. Xpanse made a Chassis/Portable PDS card combo in with TWO SE PDS card slots.

 

Of course we haven't gotten that card working on a Multiscan Display quite yet. But that prospect doesn't seem like all that hard to do by comparison. Somebody else started that project thread and I jumped in with my card and the newly acquired SE/Radius16.

 

That would give you a two display desktop. Did the Portable ever do more than mirroring on that panel?

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
16 minutes ago, Trash80toHP_Mini said:

That would give you a two display desktop. Did the Portable ever do more than mirroring on that panel?

It is impossible for the Portable to do anything but mirroring on its integral port. The lines running to it are literally the same ones as those that run to the built-in panel.

Share this post


Link to post
Share on other sites

That answers that, just checked your first reply and that info was in it, but wasn't clear at all. That video port was all but useless before first release. Repackaging an SE VidCard's components would then be only remotely viable option outside of developing an entirely new VidCard from scratch. A new design would be good for both Portable and SE, if not Plus and Classic as well.

 

I really wish I'd snagged that Video Card Prototype/Media/Development Documentation package that was listed on eBay. Couldn't have done anything with it myself, but it wouldn't have sunken into oblivion. Did anybody here or out there among the lurkers snatch it?

 

Edited by Trash80toHP_Mini
Apparently I can no longer typel ;-/

Share this post


Link to post
Share on other sites

The portable works on an 8-bit parallel pixel input per pixel clock. Unfortunately I am not entirely sure how those pixels are arranged whether they are 8 next to each other, or 1 every other row, etc.. 

 

I have the pinouts of both displays, and the rear port. 

 

From the limited studies I have done, there are 2 clock signals and a framing signal. Only 1 of the two clock signals is going to the external port, which is CL2. CL2 the pixel clock, and CL1 is the line sync (Horizontal Sync) signal. 

 

My assumption of FLM being the framing signal is because it is also going into the MISC GLU which probably generates the VBI from the FLM signal. 

 

FLM = First Line Marker, aka Vertical Sync. 

 

Anyways, I havent hooked it up to a scope yet (really need a logic analyzer honestly) to figure out the sequence diagram to figure out how the 8 bits are mapped to the pixel areas. I am familiar with most 4-bit displays, and it goes vertical. D4 being the top pixel, D0 being the 4th pixel down from the top. 

 

LCD Interface.pdf

Edited by techknight

Share this post


Link to post
Share on other sites

Or I could have just simply looked here. LOL

 

 

Anyways, the data can be captured and double-buffered into either a single SRAM IC thats large enough for 2 frames, or two independent SRAM ICs. Draw a frame, swap the buffer and while the portable is drawing into 1 RAM IC, your reading out the other in a different "way" to drive a different type of display. Sure your going to lag 1 frame behind but I doubt youll notice it. The refresh rate would remain the same. as on each V-Sync Period, both scans would need to finish and the buffers "swap". This is if you want to drive a different type of LCD panel that is configured differently. 

 

Otherwise,

 

You could drive a VGA CRT with this using the same exact concepts as the SE/30 does. using an LS166 serializer. CL1 is your horizontal sync, FLM is your vertical sync. CL2 is your latch clock for the LS166, and your shift clock is the CL2 * 8, which should approximately be the same as the 16Mhz video clock. (like the SE/30). Unless you pull a clock line out of the portable, you will need a PLL/VCO with div8 in the loop feedback to obtain the shift clock. 

Edited by techknight

Share this post


Link to post
Share on other sites

Techknight, do you know of any good primers on how to interface with LCDs.   I guess there may be such a variety of methods that it doesn't lend itself to a summary.   But maybe they all have enough in common that it does.   If I knew, I wouldn't need to ask.  :-)

Share this post


Link to post
Share on other sites

Its easy (from a programming standpoint). The easiest way obviously is to get an LCD controller. (like an SED1335 or T6963 for black and white LCDs) But I have interfaced to controller-less LCDs with things like the raspberry pi, and microcontrollers themselves. 

 

Problem with the Pi is the low memory bandwidth. timing critical situations like this will cause flickering when linux is doing things in the background. Which is why the beaglebone black shines because of the shared-memory attached PRU CPUs which I dont have any experience with unfortunately. 

 

With a microcontroller, you just assign some framebuffer in memory, and run a timer interrupt sequenced routine which reads the buffer, clocks out the data, latches it in and moves onto the next line. timer hits again, you increment the pointer, and run the routine all over again. this repeats indefinitely. the LCD will then display what is in the allocated memory. 

 

The memory gets updated and switched with a non-interrupt based routine. 

Edited by techknight

Share this post


Link to post
Share on other sites

Thank you, techknight.   

 

I have several hundred little LCD displays (probably unused Pager stock) in the attic that have a chip-on-glass controller that looks like one of the standard Epson ones, maybe  a 1335.   I have the datasheet on an old drive at home that would tell me which controller I deduced it was.   And an embedded flat flex cable to the controller.    My (very old) plan has been to trace out the cable connections to the chip bumps with a microscope and then experiment to get it working.   I can afford to blow a few in the process.  :-)   On the other hand, I haven't started any projects that require a bunch of displays, so little motivation, what with all the life and procrastination going on.

 

Kind of silly of me to buy the displays in the first place, but it was one of those Ebay lots one used to see (not so common any more) where it's something like 648 LCD displays; current bid $10.83.    Heck, one might find a use for them some day, right?  

Edited by trag

Share this post


Link to post
Share on other sites

When reverse engineering, I have learned the better option is to have the original equipment. You can then use an analyzer to work out the drive signals to figure out exactly what controller it was. 

 

Without that, you dont know whats ground, whats VCC, what is clock, latch, data, any of that. 

Edited by techknight

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×