[Bbraun] has an old Macintosh SE computer. He was looking for a way to view the video output from the SE on a newer, modern computer. He ended up working out a pretty clever solution using a stm32f4discovery board.
First, the SE’s logic board was removed from its case and placed onto a desk for easier access. The discovery board was then hooked up to the SE’s processor direct slot (PDS) using normal jumper wires. The discovery board acts as a USB COM port on a newer Mac OSX computer. The discovery board watches the SE for writes to video memory. When it sees that the R/W pin goes low, it knows that a write is occurring. It then waits for /AS to go low, which indicates that an address is on the bus. The discovery board reads the address and verifies that it falls within the range of the video frame buffer. If it does, then the discovery board writes a copy of the data to a local buffer.
The OSX computer runs a simple app that can make a request to the discovery board via USB. When the board receives the request, it sends its local frame buffer data over the USB connection and back to the host. The OSX computer then displays that data in a window using CGImage. The demo video below was captured using this technique.
[Thanks Rasz]
It boggles the mind to think that the Mac SE was so slow (or that the STM32F4 is so fast) that this actually works. Nice hack.
You have got to remember that it is only 512×384 and 1 bit per pixel. Not much data, works out to be about 1.4MB/s.
That barely fits in a STM32F4 disco board’s USB. Not enough for anything more sophisticated. Would be nice to do the same thing with a FX2LP and USB video class for other systems. Plug and play!
“Fortunately, a 1bit indexed color map wasn’t very tedious to make! ” made me lol
Thats not how it works. STM32 intercepts MEMORY writes on the CPU bus, screen resolution and color depth is meaningless here, only thing that counts is the bus speed (8 MHz = 8MB/s).
arghh had a dream about this reply, so I have to fix it :)
its 16bit data bus, so 8mhz = 16MB/s
it’s not one clock per instruction.
I did a quick google but didn’t find the info I was looking for.
The 68000 CISC is a min 4 clocks per CPU cycle. But I am not sure how they extend from there.
Normally with a CISC, a Register – ALU – Register instruction is four clocks. A Read – Register instructions is about 8 clocks and a Read – ALU – Write cycle is about 12 clocks.
argh, you are absolutely right
you will need 16MHz GPIOs, but only 4MB/s
DMA, or video output chip can transfer at full bus speed, but this hack intercepts bus writes (unless mac os used dma for data transfers to video buffer?)
aww my brain, 8MHz gpios …
I think the mind boggling is more about the data acquisition from the SE’s bus than the data rate across USB etc.
But the STM go up to about 72MHz from memory so these old slow buses can be read in real time using bare metal code or cycle efficient C.
I tried to google for ‘CGImage’ but there are too many results to work out which one was used here. I gave up on it anyway as it’s probably Apple only. A windows version would be useful.
CGImage is just basically what you get on a Mac when you create a bitmap context in memory and dump image data into it. There’s no particular magic to it that makes it easier than doing the same thing on any other OS. Of course Core Graphics is not cross platform so it’s not directly portable, but the concept is the same.
Cool!
Now if you could read/write the drive from the host via the stm32, then you’d have a Mac coprocessor for your Mac!
Now that’s a killer hack KUDOS
Impressive! My first computer was a Mac Plus, and I played with several SEs back in the day, so the motherboard looks very familiar to me.
Does anyone know if it’s possible to capture VGA using an FPGA? It would probably need USB 3 to send the frames fast enough, but it would be very useful to me. HDMI would be even better, but that might be wishful thinking. I could buy a composite video capture device, but the quality on those is awful and the last one I tried needed a special Windows-only driver.
You can indeed. I suspect this is likely using an FPGA to do its magic:
https://www.blackmagicdesign.com/products/intensity
There are also HDMI capture cards out there.
The Black Magic is $200, and large to carry around. I’m thinking of something hackable, affordable, and pocket-sized. It would be perfect if I could use my Virtex-II, for which I’m still seeking a good application.
IIRC there is a papilio project that does something like this…
The Papilio project is VGA out, not VGA in.
I have an old Amstrad CPC-6128 and I was going to convert the video out to VGA using a CPLD (Like a very small FPGA).
CPLD’s are small so if VGA can be done on one then HDMI would easily fit into FPGA. I don’t know anything about HDMI at this point though.
For the Amstrad I will be clocking video into RAM at the normal rate and then clocking it out again at a VGA rate. It will be internal so that It can pick up signals before the DAC so it’s cheep – $20 to $30 to make.
I have been putting this off because I also want to make a SD card floppy emulator but perhaps I should make a Ver1.0 anyway.
The original Amstrad output is PAL or NTSC timings (more often PAL) with composite monochrome output (including combined sync) and alternately RGB out with combined V/H sync.
You can get cheap RGB/CGA to VGA converter boards from Ebay for cheap, and they work very well with the CPC, even tolerating a lot of demo effects well – I’m currently using one on mine.
I have been considering doing an HDMI output with a similar approach to you; the tricky part will be emulating the CRTC and Gate Array as well as getting synchronisation right (as hsync/vsync aren’t available on the expansion port, although I have some ideas on how to do it with what is available.)
There are a number of problems to solve to do this and as a result their are a number of restrictions.
VGA is a broad generalisation. The standards are HQVGA, QVGA, HGA, VGA, SVGA, WVGA, XGA, WXGA. Not all of these actually have a VESA standard.
At the lower end you could easily use USB 2.0. At the upper end USB 3.0 is too slow so you would need to use a higher bandwidth interface like PCI.
Then there is problems with clock extraction. If this can’t be done in a suitable way then you need to up the sample rate so that it is at least twice the clock rate – this doubles your bandwidth requirements again.
If you have precise requirements then you may find that it can be implemented rather inexpensively but as you broaden the range of required specifications the cost and complexity increase rapidly. At the same time it is likely that the performance decreases.
There are quite a number of VGA – HDMI converters on ebay. You may be able to reverse engineer one of there and add USB 3.0 but you would need to write the driver as well.
Can we have one that instead of doing USB simply outputs to a cheap LCD replacing the built in monitor? That would be pretty cool.
sure, you could make mac SE laptop if you are crazy enough.
Great hack, reading out contents of memory like that. I had a blue-sky idea to build a “PDS” card for the SE/30 which contains an Intel Edison (Euro-120 to Hirose-70 with level shifters, etc), essentially using it as a coprocessor/wireless bridge. I didn’t think the Edison’s GPIO pins would be nearly fast enough to acquire signals from the SE/30’s 20MHz PDS slot, but this has got me thinking maybe it’s not so impossible after all.
I assume writes to the SE’s screen buffer would need to go through the CPU. It’s very cool seeing old Mac hackery on HaD!