Viewing A Macintosh SE’s Video On A Modern Computer

[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]

25 thoughts on “Viewing A Macintosh SE’s Video On A Modern Computer

      1. 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!

          1. 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.

          2. 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?)

    1. 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.

      1. 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.

  1. 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.

    1. 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.

      1. 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.)

    2. 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.

  2. 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!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.