Compact Mac external VGA adapter

[bigmessowires]

I've been kicking this idea around in my head: build an adapter to connect a compact Mac (128K, 512K, Plus, SE) to an external VGA monitor. Has anyone seen something like this before? I did a quick web search, but didn't find anything.

I see two parts to this hack: getting the video signal out of the Mac, and converting it to VGA. Getting it out shouldn't be too bad, I think: the video and sync signals are already present on the analog-to-logic board connector. Some kind of Y-splitter cable could be inserted inline, with some new wires to feed the video signal out the back, through the battery compartment or a drilled hole. (eek!)

Converting to VGA is the tricky part. The Mac's horizontal refresh rate is 22.25 kHz, which doesn't match any standard VGA resolution, nor does it divide evenly into any standard resolution. It's around half the 48.36 kHz rate for 1024 x 768 @ 60 Hz VGA, but it's not exact.

Outside the Mac, you'd have a board with a CPLD or FPGA, maybe some RAM, and a VGA connector. The job of the FPGA would be to record the incoming video signal, then play it back out at a different rate. It might also need to flip the polarity of the sync signals.

One approach would be to buffer an entire frame's worth of Mac video into RAM, then play that frame back out at a new rate while simultaneously buffering the next frame. This would require two frame buffers worth of memory: 512 x 342 x 2 / 8 = 44KBytes of RAM. I believe there are FPGAs with that much internal RAM, or alternatively one or two external RAMs could be used. Two external RAMs would be convenient, because of the requirement of simultaneous access to both the incoming and outgoing buffers. But it might be possible to use one external RAM and do transfers twice as fast, alternating incoming and outgoing data. With external RAM, it should be possible to fit all the logic inside a smaller and cheaper CPLD instead of an FPGA. But you'd need around 25-50 I/O pins to interface with all the address and data lines on the RAM(s).

The second approach would be to buffer only one line's worth of Mac video, then play it back out twice, at 2x the original rate. This would only require two lines worth of memory: 512 x 2 / 8 = 128 bytes. That might even fit inside a CPLD, or for sure inside an FPGA. But this approach would result in a horizontal refresh rate of 2x the Mac's rate, or 44.5 kHz. I don't know if that would be close enough to 48.36 kHz for a VGA monitor to be happy with it, or if it would barf. I'm guessing it would barf, but it's probably worth testing.

With either approach, you would end up with a pixel-doubled VGA display at 1024 x 768, with a black boarder at the top and bottom, since 342 x 2 is less than 768.

A CPLD with external RAM may be the better solution. I did a quick check on FPGAs, and the Xilinx XC3S500E has enough internal RAM, but it costs $30, only comes in a BGA package, and runs at 1.2 volts. Not very hobbyist-friendly.

Thoughts? Am I crazy?

 

[cb88]

Instead of just redisplaying the internal video.. implement a separate display.

1. Get a copy of the ScuzzyGraph driver... (it even supports color)

2. Reverse engineer it figure out the protocol

3. implement it in FPGA (SCSI interface / simple graphics processor / VGA or HDMI out)

4. Profit.

You can find info and more links to the Scuzzygraph on this forum... it used a TI graphics processor which probably wouldn't be terribly hard to reimplement.

I dunno why you would want to redisplay the video already shown on the built in display... for the ammount of effort that would require it seems pretty pointless.

 

[Trash80toHP_Mini]

Thoughts? Am I crazy?

Indubitably, but you come up with amazing stuff, so it's a fair trade-off. Back in the day of the real Hackintosh, there were methods to put Compact Mac video on TTL monitors, but I don't recall VGA adaptation.

Having a Compact Mac hooked up to a KVM switch with other Macs and a PC using such an adapter in combination with bbraun's PS/2 KBD/Mouse adapter would be very handy for playtime.

A Wireless USB KBD/Mouse->PS/2 adapter would be the next logical step for such a setup. Such would allow me to use my online/main Mac workstation with the collection.

 

[bbraun]

I've been thinking about the same problem in a slightly different way. The 68000 macs' graphics interface is a simple framebuffer. I have been toying with attaching to the 68000 processor (or in the SE, use the PDS slot) and just snooping the bus for writes to the framebuffer, passively keeping a duplicate copy. Then you can do anything with it. My initial thought is to just build a USB device where a host can then access the framebuffer contents as a window on your computer. Coupled with a raspberry pi or similar, you've got compact mac -> hdmi. Or, throw some GPIOs on that adapter and plug it into the keyboard/mouse port and you've got your mac entirely in a window on your computer. Better than any emulator!

This way there's zero loss in signal quality, it's digital all the way through to the final output.

 

[bigmessowires]

I dunno why you would want to redisplay the video already shown on the built in display... for the ammount of effort that would require it seems pretty pointless.

Hehe, for sure. I guess I prefer hacks where you can plug some doodad into any old Mac, and it'll work, rather than things that require special software or drivers. Seems more "pure" somehow. As for WHY I'd want to mirror the display, because I can! I suppose you could hook it up to a KVM like Trash80 suggested, or project it on a big screen to an audience or something. You could even remove the Mac motherboard and run it independently of the rest of the Mac (the analog board, CRT, and case), powered from a 5V wall wart. Make a headless Mac Plus! Put a Plus board in an LC case! Who knows...

Back in the day of the real Hackintosh, there were methods to put Compact Mac video on TTL monitors, but I don't recall VGA adaptation.

Yup, I just read a book that described how to do the TTL adapter, which is what got me thinking about this.

I have been toying with attaching to the 68000 processor (or in the SE, use the PDS slot) and just snooping the bus for writes to the framebuffer, passively keeping a duplicate copy. Then you can do anything with it. ...This way there's zero loss in signal quality, it's digital all the way through to the final output.

That sounds good too! I'm not sure how you'd physically connect to the bus on an older Mac though - some kind of clip-on? What kind of hardware would you use to snoop the bus? I'm not sure the RPi would be up to it.

Now that I think about it, you could combine our ideas, and use a CPLD/FPGA to capture the video signal coming out of the logic board, then pass that to a Rasberry Pi or whatever, instead of driving a VGA monitor directly. My guess is that would be a simpler way to acquire the video image than snooping the processor bus, though I may be wrong. The data would still be digital either way, since it's a 1-bit video signal. Or maybe the RPi *could* do that directly - it would require sampling three digital I/Os at exactly 22.25 KHz, with enough processing time left over to do something useful with it.

 

[bbraun]

There have been a variety of ingenious ways people have attached to the bus on the compacts. One is the killy clip approach where you have kind of an inverse socket that fits over the top of the 68000 chip. I've found those to be incredibly frustrating to work with. The other approach is to insert a layer between the board and the ROM chips, and then just have clips for the remaining couple of address lines that are missing from the ROM sockets.

For snooping the system bus, I wasn't thinking of using the rpi directly. I've been toying with the stm32f4 lately, and it seems to be pretty quick for just bitbanging stuff. It might be fast enough to decode the addresses plus forward data off. Otherwise, decoding the addresses can be done by a CPLD or discrete logic (I've done the latter for 030PDS before, so seems fairly straightforward). Then have the little bitbanging device contain the framebuffer and forward off via some other modern interface, I'm just using USB as an example. If it was USB, you can plug it into an rpi and display it out hdmi, that way you don't have the rpi bitbanging.

Given that it's an 8Mhz, 16bit bus, memory access takes 4 cycles, and the internal clock on the stm32f4 is something like 140MHz, it seems somewhat reasonable. But maybe it's just one of those cases where I have a hammer in the form of the stm32f4 and everything looks like a nail now.

The big problem with using rpi for this kind of stuff directly is of course that it runs linux and you get everything that means, for better or worse. Including imprecise timing...

 

[techknight]

Well, VGA is 640x480. not 1024x768. That is XGA i believe. But regardless, still have to find some way to convert the scan.

Either buffer it frame-by-frame and deliver it into a VGA generator program, or direct conversion but i dunno how to do that.

 

[Bunsen]

From previous research and discussions here I recall that EGA (or was it CGA?) is near-enough to the boxMac video that existing E/CGA-to-VGA adapters work, with a little intervening circuit for polarity correction or something. Those existing adapters are not exactly cheap, though, and a pixel-doubled adapter to XGA may just work out cheaper, even in small/single/DIY runs - especially if you incorporate the aforementioned required signal conditioning onboard.

I noticed that you used the pixel-doubled approach in your FPGA Plus, BMOW - is there stuff you can re-use from that build?