I managed to send video signals to a Mac Classic’s internal CRT monitor from a BeagleBone Black back in 2016, and it seems like this is a topic that a lot of people are still interested in. A recent discussion gave me the idea to try and do the same thing with a Raspberry Pi, and I wanted to document the experiment in this article.
Introduction
Important update: As of right now, the Macintosh Classic CRT related parts of this article are only valid if you use a Raspberry Pi 4! Older versions won’t work. However, the DPI interface is available on all other 40-pin Raspberry Pi models, and the rest of the article remains valid for those.
Please also note that this is an approach that worked for my Mac Classic, not an official guide or a universal method that’ll work for all of you. Please also see the comments for fixes that other readers have implemented!
If you remember the original series and this article about exact timings on the Pi, I somewhere concluded that it simply wasn’t possible. At least not in the same way it is on the BBB. While the sync signals could be generated precisely on the Raspberry Pi, it was not capable of sending the pixel data to the monitor fast enough in the full resolution.
While I still think that’s true, I didn’t think about the possibility to use the Pi’s display hardware to do the job for me, like a commenter on the original series pointed out. So the main goal of this article is to configure the Raspberry Pi in a way that allows the framebuffer to be rendered on the Macintosh Classic’s monochrome CRT display.
The Display Parallel Interface (DPI)
You might have seen some Raspberry Pi display HATs that only connect via the GPIO interface. Those use the DPI mode of the 40-Pin GPIO Raspberry Pi, which is one of the alternate functions of the GPIO.
If selected, the GPIO pinout of the Pi changes:
This configuration allows parallel RGB displays to be attached to the Raspberry Pi GPIO. Several color modes are available:
- RGB24 (8 bits per color)
- RGB666 (6 bits per color)
- RGB565 (5 bits red, 6 green, and 5 blue)
However, this also means that most of the GPIO pins can’t be utilized for other tasks while the Pi operates in the DPI mode.
This interface is controlled by the GPU firmware and can be configured with special config.txt parameters. Furthermore, you’ll also have to load and enable the correct Linux Device Tree overlay, just like with the original BBB version.
Enabling the ALT2 (DPI) Mode of the GPIO
As mentioned, the mode is enabled by loading the correct Linux Device Tree overlay. But first, you’ll have to disable I2C and SPI, because those will conflict with some of the video pins. To do that, edit the config.txt file:
sudo nano /boot/config.txt
In that file, comment out the following two lines:
dtparam=i2c_arm=on dtparam=spi=on
They should now look like this:
# dtparam=i2c_arm=on # dtparam=spi=on
Once that’s done, put the GPIO in the Alt2 mode by loading the DTO:
# 24-Bit mode dtoverlay=dpi24 # 18-Bit mode # dtoverlay=dpi18
Note that both DTOs are already installed by default. They are located in the following folder:
/boot/overlays
That’s all you need to do to enable the DPI mode! Let’s take a look at how you can configure the graphics card to output the right sync signals.
Configuring the video hardware
As mentioned earlier, the DPI mode can be configured by placing special attributes in the config.txt file. I wrote this small Java application that’ll allow you to quickly enter all the necessary information. It will then generate the attributes for you, and you only need to add them to the config.txt file:
This tool is universal and can also be used to create the configuration properties for other displays. The various fields and parameters are explained on the app’s download page. I used the following two attributes for the Macintosh Classic CRT:
dpi_output_format=0x76017 dpi_timings=512 0 14 178 0 342 0 0 4 24 0 0 0 60 0 15667200 1
Just add them to the end of the config.txt file.
Configure the framebuffer and setup a custom video mode
You can either use a pre-configured timing mode, or define a custom one. In this case, no standard video-mode could be used to interface the display. Therefore, I had to define a custom video mode, which can be done by setting the following two flags in the config.txt file:
dpi_group=2 dpi_mode=87
This will make sure that the dpi_timings parameter, described above, is used by the driver when the Raspberry Pi boots up.
As the last step, the framebuffer has to be configured. I used the following settings for the Mac Classic CRT:
overscan_left=0 overscan_right=0 overscan_top=0 overscan_bottom=0 framebuffer_width=512 framebuffer_height=342 enable_dpi_lcd=1 display_default_lcd=1
The last two lines will make sure that the video signals get generated and that the DPI is used to output the contents of the frame buffer.
The overscan values can be used to center the image if it should be off-center. However, mine was fine right away, so I didn’t use those values.
The completed config.txt file
These are all the lines I added to the config.txt file for the Macintosh Classic CRT:
dtoverlay=dpi24 overscan_left=0 overscan_right=0 overscan_top=0 overscan_bottom=0 framebuffer_width=512 framebuffer_height=342 enable_dpi_lcd=1 display_default_lcd=1 dpi_group=2 dpi_mode=87 dpi_output_format=0x76017 dpi_timings=512 0 14 178 0 342 0 0 4 24 0 0 0 60 0 15667200 1
Hooking everything up
Connect the HSYNC line of the Raspberry Pi (Physical Pin #5) and the VSYNC line of the Pi (Physical Pin #3) to the HSYNC and VSYNC lines of the display. Unfortunately, my display’s synchronization signals use a voltage of 0V and 5V for the digital LOW and HIGH state. However, the Raspberry Pi only outputs 3.3V. Therefore, I also needed to add a logic level converter to the two sync signals. Don’t forget to connect a ground wire of the display to a GND pin on the Pi (See fig. 4).
Next, connect the color lines of the Raspberry Pi to the display. This step varies, depending on your configuration and display. The following GPIO pins can be used to transmit the color information:
I used mode 7, which means that there are 8-bits per color. If you, however, use mode 3, for example, the red data-bits get transmitted on the GPIO pins 24 to 20, green pixel information gets sent over the pins 17 to 12, and blue over GPIO 8 to 4. This configuration allows you to use some GPIO pins for other tasks.
The Mac Classic’s display is a one-bit monochrome display, so I used a single color line to connect the data-line of the screen. That’s a very quick and dirty solution, and I’ll properly hook the screen up in another article. For now, this is all I needed to do:
(View full size image)
This method was enough to verify whether the signal generation works properly.
Luckily, it did almost right away. Here are a few quick pictures I took:
As you can see both, the console, as well as the desktop, can be displayed perfectly fine. However, as mentioned before, the colors are completely off, which is fine for now. I’ll fix that later.
Problems and solutions
Compatibility
As some commenters have brought up, older Raspberry Pi Models can’t produce a pixel clock frequency that suits the Macintosh Classic CRT. Therefore, the Macintosh Classic related sections of this article only hold for the Raspberry Pi 4. With it, you can achieve a close enough output:
Furthermore, there may be differences in the various iterations or versions for different regions/countries of the Macintosh Classic. However, that’s just speculations.
Overscan
If you remember the BBB series, one problem was, that the Macintosh Classic’s CRT display circuitry expects the HSYNC signal to become HIGH (and thus inactive) exactly 110 pixels after the video data had already started:
However, the Pi can only generate an HSYNC signal that gets HIGH just before the data gets transmitted. Or, in other words, the data gets transmitted just after the HSYNC is done, which is the way to go for HDMI and VGA.
My first workaround for this problem was to increase the number of pixels per line by 110, use a left-overscan of -110 pixels, and then make the HSYNC pulse 110 dots longer. This worked reasonably well. One of the pictures from the slideshow above shows this workaround. However, this way, every line took longer than it should, which caused refreshing artifacts and flicker.
You might have noticed that my finished configuration from above doesn’t contain this workaround. It turned out, that the display simply ignored the incorrect portion of the HSYNC pulse and happily rendered the data anyway. So in the end, it was much less of a problem than I had first thought.
Troubleshooting
Another thing, that I noticed, is that when you leave the Mac Classic CRT’s data line floating (not connected to anything), it displays all pixels at full brightness (blank white screen) as long as the HSYNC and VSYNC lines are correct. This is good for troubleshooting. If you don’t see this happening (or if the display produces a clearly audible buzzing or humming sound) try swapping the HSYNC and VSYNC lines.
Voltages
Make sure that you supply the correct voltages! The synchronization lines on the Macintosh Classic CRT use 5V and the data line uses 3.3V. Utilize a logic level converter (or any similar technique) to overcome this issue.
Display is still blank after troubleshooting
If the Mac Classic CRT displays a full white screen with the data pin floating but it doesn’t display anything with it connected, try to use a different color output of the Raspberry Pi.
Supported Raspberry Pi Versions
The DPI interface is available on all 40-pin Raspberry Pi versions (including the Zero). The instructions for the Macintosh Classic CRT, mentioned in this article, will currently only work on a Raspberry Pi 4.
Sources
[Figure 1] Screenshot from pinout.xyz
[Figure 3] Official Raspberry Pi Hardware documentation
[Figure 4] Raspberry Pi 3 Vector Graphic
[Figure 6] Mac Classic II Developer Notes
Raspberry Pi video options (overview)
Summary
The old BBB based project was a lot of fun to create. However, it’s extremely outdated nowadays as well as inconvenient to use. Furthermore, I never managed to display the contents of the framebuffer with that method.
That’s where this mini-project comes in. While the BBB is practically dead, the Raspberry Pi is more than alive. Luckily, it’s very easy to set up the DPI mode and configure it to work with almost any display, even 30-year-old CRTs. This method allows me to render the desktop and the console output without any complicated programs and hardware modifications.
nerdhut 
I found a header that could be used to build a nice little Pi Hat for driving your Mac display. https://www.arrow.com/en/products/0039281143/molex
LikeLiked by 1 person
Thanks for sharing!
I’ll look into the MacDisplay project a little more once I have more free time again.
LikeLike
I just put a board together using that header. It’s pretty much plug and play now. https://i.imgur.com/nyPVlf6.jpeg
LikeLiked by 1 person
Oh, that’s cool!
I see you used a quad buffer IC there, I assume it’s to protect the Raspberry Pi’s GPIO pins in case something goes wrong?
LikeLike
Hey thanks for sharing this method which has been successful in displaying on my 1992 Macintosh Classic CRT!
I took a gamble and purchased a dead Mac hoping it was a simple recap job. Unfortunately the battery electrolyte had taken it’s toll at some point liquefying every trace surrounding the leak. I had components literally sliding off the board. It was a real shame to see it that way.
I’m using a Raspberry PI 4 after having no success on the Raspberry PI 3. Setting that you’ve shared work fine to get a display but I’m wondering if you’d had any success with getting the colours right?
Naturally the OS is not optimised for this type of display so images and especially text does not display fully. Any ideas?
LikeLiked by 3 people
Hello!
Good to hear that it’s working with a RPi 4! Unfortunately, I still haven’t found the correct settings for earlier models, but that’s a different story!
Anyway, regarding the black and white image: I think there’s a way to configure the OS to output gray-scale or black/white images, but I’m not sure about this one (I’ve just heard about it somewhere, but haven’t looked into it myself). I think this discussion could be a good starting point: https://unix.stackexchange.com/questions/526537/is-it-possible-to-change-my-display-to-amber-monochrome
If that works case, someone suggested a method in a different comment: You could use one of the other bit modes and a resistor ladder to convert any of the color channels to a single analogue brightness line, and try to feed that into the mac classic’s display. But I think this wouldn’t yield much better results because the Mac Display is a monochrome display, so it would most likely only display all gray tones below a certain threshold as black and all other ones as pure white. So some detail, like gradients, will still be lost.
I unfortunately haven’t had the time yet to look into this a little more, but I’m pretty sure that I will! If you find anything interesting, feel free to share it with use here!
Anyway, I hope this helps!
LikeLiked by 2 people
The “Mac Display” is only a 1-bit deep display because the video signal is passed through a schmitt-trigger before it is fed to the video amplifier. Just omit that and you have infinite gray scales only limited by the bit depth of the graphics card that drives it.
LikeLike
Yep, it’s working with the SE and se/30 also, I’m going to post a video on YouTube, and of course everything will be credited to nerdhut:) Thank you, I’m older and have absolutely no experience with terminal commands and inputs, thanks to you I learned quite a lot, because I didn’t understand how you obtained some of your settings, so I had to do something I haven’t done in a long time, research:)
LikeLiked by 3 people
Hello!
Thank you for your comment – I appreciate the feedback! I’m glad to hear that this method worked for you on the SE and SE/30, and I’ll try to explain Unix commands in the future where it makes sense!
LikeLike
I would like to See it! Where i can find it on YouTube?
LikeLike
Hi,
Unfortunately, thereās no YouTube video at this point in time. However, you can find a few images in the blog post.
LikeLike
Funny I had been working on this for a while now (a few months) and just came across your post here. Couple question — what kind of Pi are you using? I’m using a Pi3B+ and it will not accept a dot clock of 15667200 which you have in your config.txt. Anything less than 19200000 can only be divisible by an integer… so with that dot clock you simply get no output.
I got my setup working by doubling the pixel clock to 31257600 and doubling the pixels and front porch. Now, what’s odd is my classic does not work correctly with the shortened h-sync pulse which you said worked for you. On mine it does not generate high voltage and you head the field collapsing in the flyback.
The h-sync is driving the sweep but also generating the high voltage… so that means to get a long enough sync pulse to generate high voltage for testing, I cut the visible pixels down by 110 to extend the pulse as like you mentioned they can’t seem to overlap with the current kernel drivers… of course this results in a chunk of the left side of the screen to be missing……
On my setup I didn’t need to level shift the H or V sync either — they work fine at 3.3v. H-Sync is immediately buffered on input and all that matters is grounding which activates the transistor. On the V sync input it goes right into a TEA2037 IC which also boosts the signal appropriately.
So I’m mainly curious how you got that pixel clock working … and then it’s interesting how your analog board accepted the short sync pulse.
LikeLike
Hi!
I used a Pi 4 (First revision) for this ‘project’. However, I’ve also managed to get this CRT screen working with a BeagleBone Black a couple of years ago (https://nerdhut.de/2016/06/30/macintosh-classic-crt-2/) where I was able to supply the correct timings to the display.
Anyway, I honestly can’t tell you why the display control circuit in my Mac accepts the shortened signal – I was quite surprised myself, and I just assumed that it’ll also work on other Mac Classics. During my experiments with the BBB, I noticed that the control circuit seemed to accept quite bad signals too. Maybe there are regional differences that make the CRTs behave differently? My computer was manufactured in Sept. 1990 (maybe it’s an earlier or later revision?), and I think that it was originally sold in Germany (but I’m not sure). Regardless, it requires European mains voltage with 220-240V and 50-60Hz (if that matters).
I found my Mac in a basement a few years ago, and it’s pretty beat up. That’s why I originally decided to have some fun with it and experiment. However, I’ve never disassembled the CRT part of the computer, neither have I looked at the control circuit in detail. I tried to do it now, but the IC you mentioned was hidden under the CRT, so I couldn’t check whether they used the same IC.
The only thing that I can 100% confirm is that my screen won’t turn on with the 3.3V signals from the Pi (on the HSYNC and VSYNC lines).
Anyway, did you get your screen working with the changes that you mentioned in your comment? It’d be quite interesting to determine why some Mac Classic CRTs seem to accept the signals while others don’t. Furthermore, do you have a source on the claim that anything less than 19200000 can only be divisible by an integer? The official documentation didn’t state any such thing, or maybe I just missed that part.
LikeLike
Interesting — maybe the Pi4 doesn’t have that limitation on pixel clock.
Link to thread talking about the Dot clock:
https://github.com/raspberrypi/firmware/issues/734#issuecomment-277313013
Documentation is extremely scarce on the whole subject — rather frustrating. Took me ages to figure out what were acceptable clocks.
Also using this command it’s easy to see the DPI clock:
for src in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi ; do echo -e “$src:\t$(vcgencmd measure_clock $src)” ; done
Right now running at 2x dot clock I see this:
dpi: frequency(4)=31258000
But if I try anything under 19.2mhz without a integer divisor, you just get a 0 for that reading and also no output on the DPI at all.
I’m going to try level shifting the H-Sync and V-Sync that might be the trick for getting the drive circuit to accept the shorter pulse. Talking to my friend about the circuit design — he said as it is right now it shouldn’t even be working at 3.3v like it is for me ….
But you if you have a something less than a Pi4 handy, try out DPI at less than 19.2mhz and you’ll see it doesn’t work. š
LikeLiked by 1 person
Thanks for sharing that link. Now I understand the problem. Unfortunately, this doesn’t seem to be anything that I can do a whole lot about. Doubling the frequency and resolution is probably the best thing to do. Maybe you can combine that approach with an external circuit to build a simple clock divider? I think a single dual J/K flip-flop IC should already do the trick (However, that’s just a quick guess). This would allow you to double the frequency on the Pi, divide that by two with the external circuit, and the result should come close enough to a valid VSYNC signal.
Just out of curiosity, I tried the command on my Raspberry Pi and this is what I got:
It’s not quite 15667200, but I guess it’s the closest value that the system could come up with, and my CRT accepts it.
I’m starting to think that this might only work on a Pi 4, even though the official documentation suggests that all 40-pin Raspberry Pis work the same in this regard. It might be down to low-level differences between the ARM Cortex-A53 (Pi 3) and ARM Cortex-A72 (Pi 4) cores. The newer CPUs might have a different clock divider or some other factors that come into play. A closer look at the datasheets might answer this question.
I might look into that issue and try to get it running with an older Raspberry Pi model. I’d also like to mention that this article wasn’t originally meant to be a tutorial on how to get the Macintosh Classic’s CRT to work with the Raspberry Pi. It just happened to be the only CRT that I own. Anyway, I’ll update the article if anything changes!
LikeLike
I just confirmed that pixel clock does work on the Pi4 for me. But not on earlier ones (I was originally doing all my testing on the 3B+)
So you may may want to update your post (if you can) that this requires a Pi4.
What is good is the Pi4 is more flexible with the clocks which means it’s more flexible driving CRTs in general — a huge help for anyone doing retro emulation!
Another caveat on the pi4: The frame buffer width must be divisible by 8 or it will look all screwed up. (The display will be all slanted inside the framebuffer.) Just figured this out as I was having issues with slightly adjusted resolution to accomodate the longer h-sync pulse…. On the earlier Pis, this was not a requirement and it would work fine with any integer pixel width.
Now I have to test out the level shifter to see if I can get it working with with my analog board with the shorter pulse.
LikeLiked by 1 person
That’s good news, at least we know that it’s working with the Pi 4! I just flashed a new SD card, and I’ll try to reproduce the problem on an older Pi (the only one I have is a 2B, so let’s hope that it comes close enough…)
LikeLike
Yes the actual clock is divided by integers so it’s not exact but close enough. The analog board is pretty tolerant and I have fed it 21khz to 23khz and it all works fine with those….
Also as a side note for the config.txt it can be a bit simpler:
dtoverlay=vga666
enable_dpi_lcd=1
display_default_lcd=1
#custom resolution
dpi_group=2
dpi_mode=87
dpi_timings=404 1 14 288 0 342 1 0 4 24 0 0 0 60 0 15628800 1 # long pulse hsync compliant with standard but reduced framebuffer width of 404 pixels. Pixel width must be divisible by 8 will only work on Pi4
or
dpi_timings=512 1 14 178 0 342 1 0 4 24 0 0 0 60 0 15628800 1 # shortened pulse but normal width — not working for me yet, will only work on Pi4
or
dpi_timings=808 1 28 576 0 342 1 0 4 24 0 0 0 60 0 31257600 1 # longer pulse but double pixel width and pixel clock which will work on Pi3 and earlier
or
dpi_timings=1024 1 28 356 0 342 1 0 4 24 0 0 0 60 0 15628800 1 # shortened pulse and double pixel width works on Pi3 or earlier
LikeLiked by 2 people
Thanks for all your input! I’ll look into all the things you mentioned, and I’ll post a fix for earlier models of the Pi (if I can find one), as soon as I can! Yesterday, I managed to get a steady image from a Pi 2b, but the resolution was all wrong. Hopefully, we’re getting closer to a universal solution! š
LikeLike
Hello! Excellent article and a very interesting project. I replicated every single step you posted, however I’m not being able to get any results. Mac Classic II screen remains black as if turned off. HDMI screen remains displaying the colorful square that appears at startup and stays like that. I’ve checked all the pinouts and every connection seems to be alright. On the Mac side I’m connecting VSYNC, HSYNC, GND to the matching Raspberry pins. IĀ“’m using RED 0 (on the RasPi) to deliver video info to the Mac. No results. Maybe you can give me some advice? I’d really appreciate your help.
LikeLike
Hi!
I’m glad you liked it, and I’m sorry to hear that you’re experiencing problems.
When I attempted this project, I noticed that the Mac Classic’s CRT control circuit only accepted a signal on the data line (the pixel data) if the signal was in the 0V for LOW and 5V for HIGH range. I had to use a logic level shifter to get it to run, otherwise, the display refused to turn on. Maybe that’s the problem in your case?
Another thing that might be causing this problem is that the HDMI circuit somehow intercepts the video signal from the DPI. However, I can’t recall that I changed any settings in the system that relate to the HDMI output. Furthermore, I’ve never used the HDMI out on my particular Raspberry Pi, so maybe there’s something wrong here? (The OS might have done some configuration in the background). Maybe try booting without an HDMI cable connected or try to run the project from a “factory fresh” install of Raspbian, if the problem persists.
LikeLike
Thanks a lot for your prompt answer! I think the difference in voltages makes sense for this issue, I’ll try the shifter and let you know.
LikeLike
Just one remark. Mac Classic I and I they both use internally 5v and RasPi GPIO uses 3.3V so I think you say “I used a cheap logic level shifter to change the voltage on the data line from 5V to 3.3V.” you meat “I used a cheap logic level shifter to change the voltage on the data line from 3.3V to 5V”
Cheers!
LikeLiked by 1 person
Yes, thanks! That was a typical 2 AM typo š
LikeLike
Hi, very interesting application for calculating dpi timing.
However, i cannot run it on Win10 (JNI error). Any ideas why?
On the other hand, i“m trying to run a video(800×600) with a Pi3 on tri sync arcade monitor. So far nothing (i mean no any settings used) worked at that resolution.
LikeLiked by 1 person
Hello! Thank you very much for reporting a bug. Can you please make sure that you have the latest version of Java installed on your computer? This error happens due to missing libraries. Please let me know how that goes – I might need to change the target version of the app if this error persists.
Unfortunately, I don’t know that particular monitor. Try to find a manual that describes the timing of your device. If it’s an arcade machine, you’ll most likely be able to find a service manual. However, you can also try to use standard VGA settings. But definitely try to find the correct timings first, because debugging the timings can be a very long and annoying process!
LikeLike
Thanks for reply.
Error was caused by sdk missing package(so it’s not a bug) – but i think you should mention it on download page to avoid the problem.
Can you tell me what data i need from manufacturer in order to compute the timings?
LikeLike
You’ll need to look for a timing diagram like the one you can find in the Macintosh Classic Manual (On page 16): http://members.optusnet.com.au/eviltim/macmp3/Mac_Classic_II.pdf
Or just a simple description (for example this one for standard 800×600 VGA: http://tinyvga.com/vga-timing/800×600@60Hz)
If you’re unfamiliar with video signals in general, you can take a look at the following articles I wrote:
In these, I explained what numbers and timings you’ll need. Anyway, getting the correct timings for an unknown display is usually the hardest part. If you can’t find anything then you can still try the standard VGA timings. However, I don’t know whether or not this might damage your display (it shouldn’t, but better be safe than sorry).
LikeLike
It`s clear now. I will try to get that info from manufacturer and in the mean time a HDMI-VGA adapter will be tested…maybe i`ll be lucky.
To damage monitor is pretty difficult (unless you keep it with weird sync signal for a while) anyway it`s not instant and you can hear-see something is wrong. So no worries about that – even if will fail i can fix it pretty fast.
Thanks again for your help.
LikeLiked by 1 person
Really great article, I hoped you would do this with a Raspberry Pi! I have a Mac Classic II and I’ve tried to replicate what you’ve done but unfortunately I’ve made no progress. Any chance I could get a bit of help? š
LikeLiked by 1 person
Hi!
Yes, sure. What exactly do you need assistance with?
The Mac Classic II should have the same display and display control circuit as my Mac Classic, at least according to the old developer notes (http://members.optusnet.com.au/eviltim/macmp3/Mac_Classic_II.pdf – take a look at page two). So you should be able to achieve the same result by just following the steps in this article.
However, I don’t know about the pinout of the connector that’s used to connect the original logic board to the display hardware. But you should be able to get it to work with four connections: HSYNC, VSYNC, GND, and VIDOUT. I used this site when I started working on the old version of this project back in 2016 (https://old.pinouts.ru/Power/macclassicpower_pinout.shtml), but I don’t know whether the Mac Classic II uses the same pinout.
Anyway, let me know what doesn’t work for you, and I’ll try my best to help you out!
LikeLike
Hi, thanks for the reply. I’ve only just had time to come back to this project :).
So one thing that was missing was the logic level shifter, I’ve bought one and installed it but it’s made no difference.
I reconnected my CRT to the logic board just to check whether the CRT still works (which it does).
Could you share some pictures of how you wired the Pi to the connector please? I think it might help out some of us Classic fans :D. I’m also using a Pi 3 Model A+, do you think that would cause issues?
Many thanks!
LikeLiked by 1 person
Hi!
It shouldn’t make a difference what Raspberry Pi you use as long as it has the 40-pin GPIO (at least that’s what the documentation says: https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/README.md).
Anyway, I just noticed that I connected only the sync signal lines to the logic level converter. The data line was directly hooked up to the Raspberry Pi. Make sure that you try that too! Unfortunately, I didn’t take any pictures of how I connected the Pi to the display, which probably, in retrospect, wasn’t the best idea.
I don’t have access to my Mac Classic right now. However, I’ll go and get it and repeat the steps in the article with a fresh install of Raspbian and also take a picture of the connections and update the article and this comment if I find some problems.
LikeLike
Okay, I’m back! I can now confirm that you only need to connect the sync lines to the logic level converter. You can connect the data line of the display directly to the Pi. Furthermore, I noticed that if you leave the data line of the display floating, the screen should display only white pixels, so that might be a good way to check whether the HSYNC and VSYNC outputs are correct. If your screen doesn’t display just a white image, try swapping the VSYNC and HSYNC connections (especially if the screen produces a humming or buzzing sound). If the test works (the screen displays white pixels only with the data line left unconnected), then try to connect the data line to a different color output of the Raspberry Pi (It’s possible that the pin you chose accidentally outputs 0 all the time for that particular image). Just randomly connect the data line of the screen to any other color output pin of the Raspberry Pi until you see an image.
I’ll update the article and add a simple schematic that shows the connections in more detail.
Thanks for all your feedback on this article – I really appreciate it! I hope that this will now resolve the issues you had while attempting to build this project! š
LikeLike
Hey,
So I spent some more time on this today.
The short story is that I still haven’t got it to work :(. I looked into the logic level converter and got this one: https://www.adafruit.com/product/1787. Not sure whether it’s the right one for the job.
I also tried different wiring combinations to the connector and didn’t make much progress. I’m in the UK and the case of my Mac says it was made in Ireland in 1991, but some of the boards inside say they were made in Singapore. Not sure whether that makes a difference.
One issue at the moment is that I’m not 100% which pin is which on the connector. I’ve looked at the data sheet but I’m not sure which one is which.
Hopefully you have some more insight into this š
Cheers
LikeLike
I used this table to determine which pins to connect to the Raspberry Pi: https://old.pinouts.ru/Power/macclassicpower_pinout.shtml
It’s not perfect, but the only thing that I could found. It refers to the connector on the main logic board which should be labeled. VIDOUT in the chart is where the video data goes in (remember, the names refer to the connector on the mainboard).
LikeLike
Hi!
I wanted to inform you that it looks like you’ll need a Raspberry Pi 4 for now. However, I’m trying to find a solution that works on all 40-pin Raspberry Pi models. You can read through the comments if you’re interested in the details!
LikeLike
Hi,
So a quick update – I got a Rapsberry Pi 4 and I’ve got some stuff showing on the screen now ššš. I wasn’t able to get the /boot/config.txt which you provided working (no idea why), but I played with Adrian’s Digital Basement’s examples and I made a bit of progress. I tried a few of the options and found that the image was offset roughly in the centre of the screen.
So I tried it without a data line and it shows an all white screen. There’s some weird lines running horizontally through the screen, not sure why though.
Not sure where to go from here, but I appreciate the hard work!
LikeLiked by 1 person
That’s fantastic news! Yes, the screen should just be all white without the data line connected. The thin white lines are normal. That’s the path the beam takes when it travels back to the beginning of a line or to the top of the entire screen (called retrace – see slide 5 here for an example: http://courses.csail.mit.edu/6.111/f2008/handouts/L12.pdf). Under normal conditions, the electron beam would be off during the time it returns to the beginning of a line or the top of the screen. When the data line is disconnected, it’s constantly on and the retrace lines show.
I’ll play around with the exact settings with my old Pi and update this article when I find anything new.
LikeLike
Hey thanks for the information.
I found another similar project albeit using a FPGA to output image to the Mac Classic Crt. From what I’ve read shading has been achieved via dithering. Whilst the image does look good it seems that a workable refresh rate could not be achieved with that project for Mac OS emulation purposes. Your implementation of the RPI 4 to drive the CRT is real time which very much suits emulation purposes.
Ahh only if were as simple as combining all of the colour outputs of the RPI GPIO…
LikeLiked by 1 person
I used dithering in an older version of this project. There, I controlled the CRT with a BeagleBone Black (https://nerdhut.de/2016/06/30/macintosh-classic-crt-2/).
I got a regular photo of a cat and used Photoshop to apply a dithering filter. Then that static image was displayed by the BBB. The real-time dithering was the biggest problem back then. However, I’m confident that it’s possible to achieve good results with the Raspberry Pi 4. I think I’ll start looking into it soon, and hopefully, there’s a simple solution that makes sense and yields good results.
LikeLiked by 1 person
Yes I think the RPi4 should be plenty powerful enough to do the extra processing.
I wish I could help in some way but unfortunately coding is not my strength. I am more than happy to verify any settings etc that you would like me to try on my setup, just let me know what you need me to do.
LikeLiked by 1 person
I’m starting to think that using something like this: https://github.com/felixrieseberg/macintosh.js is more reasonable if one is looking for an old-style emulation. For modern systems, there might be a way to configure X11 (or maybe a different desktop system other than the one that comes with raspbian, if one’s interested in using modern features. However, many apps and programs might not support monochrome modes and crash unexpectedly or behave weirdly.
Anyway, thanks for your support, but I, unfortunately, can’t promise a quick solution to this problem, but I’ll definitely stay at it and post an update once I know more!
LikeLiked by 1 person