• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Yet another SoC to B&W CRT thread

Hey guys,

I have been a reader for some time now. I got a Macintosh Classic II from a yard sale and it's standing in my basement currently. I would like to build a little bit with it and use it as a little data server.

My plan is to replace the original logic board with a SoC like a Raspberry Pi or an ODROID or something similar. The coolest would be to keep the original screen working, if there's no way to achieve that, acrylic mold and LCD it is but I wanted to check my options.

From what I have seen it's either very specific solutions (as simply displaying images on the CRT) or having low-performing solutions (4-5 FPS like the solution proposed by SpriteTM). Another suggestion is to get a grayscale monitor and replace the internal screen, this would at least yield a VGA connection one could work with. But hell, they are expensive. (Actually, why?)

I was curious whether there have been some progresses in that topic (as many people must have tried that already) and if there are some suggestions from people who have succeeded with that. I'd like to hear your opinions!

 
The main challenge with VGA on the internal monitor is that the horizontal scan rate is different, and this requires substantial modification to the existing analog board. There's a secondary challenge around grayscale vs. black and white, which needs a different CRT neck board, but that's an easier challenge and also less of a gating factor to getting something the screen.

I started down the resolution-changing road a few years ago, and I'm still (very) slowly working on it in whatever bits of free time I find:



The good news for you is that you've got a Classic II rather than any of the earlier compact Macs. As you'll see near the end of the above thread, the Classic II (and late-model Classic) have a different analog board design with a different flyback transformer than all the previous compacts. It appears that this flyback is amenable to being run at a higher scan rate, where the earlier one basically can't go above 22kHz. The starting point would be to decrease the value of the flyback capacitor, then generate an HSYNC signal with the right pulse width to replace the HSYNC coming from the logic board. You will probably need some external circuitry for that (e.g. a one-shot timer). You may also need to find a way to generate a higher power supply voltage for the horizontal section to get a wide enough picture, but I haven't gotten that far yet.

Certainly the 9" VGA monitor option is easier if you're taking out most of the guts, but I do think VGA will eventually be possible with the built-in analog board, at least on the Classic II.

 
In one of the threads on this topic that's floating around the board (there are a lot, and unfortunately some of the internal links are messed up so I'm having trouble finding it) I *believe* I posted some links to some documentation I'd found about the built-in direct LCD driver circuitry that's present on the Raspberry Pi and irrationally speculated that in theory at least *maaaaybe* with a little external circuitry you could use it to drive a classic Mac monitor directly. TL;DR version:

The Raspberry Pi supports a protocol called "DPI", Display Parallel Interface. This allows LCDs supporting this standard to be directly wired up to the GPIO pins on the PI (you lose them as GPIO, of course) and driven by the GPU hardware directly without any sort of nonstandard driver overhead. Although this connector is mostly intended for LCDs it's technically possible to hang a DAC off it and drive some other sort of display; here's a thread about a simple resistor-ladder DAC they make that lets you drive a VGA display from it. Anyway, if you follow this rabbit hole all the way to the bottom you'll find pages about setting up custom video modes on the DPI port, and from that follows this wild supposition: given this level of flexibility why couldn't you just bang together some glue that would let you drive a Classic mac CRT directly?

Obviously there's some wrinkles you'll have to deal with, like the fact that the Classic mac's CRT doesn't use quite according-to-Hoyle TTL sync (there's an old article about interfacing it to a VGA card floating around that talks about that; from what I recall it shouldn't be a deal breaker) and, of course, the issue that it's only one-bit TTL when it comes to video level while the drivers in the Pi only supports 16, 18, and 24 bit color output, but I don't see these as insurmountable. The three strategies I see for dealing with the color depth issue would be:

1: Set up your "DAC" so it does a logical OR on the output pins so if a color, any color is set above a certain brightness at a given pixel you'll render that spot as white, otherwise it's black. That'll work, you'll just need to be very careful about choosing colors when setting up your UI. (IE, constantly remember you're really dealing with a 1 bit display when writing to your 24 bit framebuffer.)

2: Hack the display circuitry to do grayscale. This is non-trivial but it's been done before on commercial products for the SE/30.

3: Crazy idea that someone smarter than me will shoot down: run this in 16 bit color mode, put a *very fast* 16 bit parallel-in-serial-out shift register across the RGB output pins, and use a PLL to drive its output at 16x the pixel clock. That would translate the binary code for each incoming pixel into 16 minuscule black-and-white subpixels, effectively microscopically dithering into shades of gray without hacking the circuitry. (Again, seriously, this is something I'm pulling out of the air and it's very possible that trying this would effectively melt the CRT circuitry with the resulting pixel clock "overclock".)

I genuinely suspect that this might work... actually, here we go:

It looks like someone mostly got this to work using the similar LVDS framer on a Beaglebone. It notes the problem that the framer for that doesn't support the negative backporch signal the Mac CRT expects; I wonder if the "h_sync_polarity" inversion flag the Raspberry supports would help there...?

Anyway, that same page also documents using the PRU on the Beaglebone with a "virtual" X-server (IE, unlike that other writeup that's out there that only got as far as supporting static pictures). So if you're willing to forego console video (IE, nothing at boot time) there's a working solution.

 
Thanks for your reply on this, apm, your thread(s) were one of the more promising sources here! How are you progressing? I'm not sure whethe I can do much independent work on that topic, no oszilloscope at home and my electronics skills would be comparatively wack. I toyed around with some embedded stuff but mainly lower-level stuff (one needs to choose his evening topics focussed).

Certainly the 9" VGA monitor option is easier if you're taking out most of the guts, but I do think VGA will eventually be possible with the built-in analog board, at least on the Classic II. 
That's promising. The 9" VGA monitor solution proves to be rather expensive. Is there a reason?

And I found the ressource you post here as well, Gorgonops:

It looks like someone mostly got this to work using the similar LVDS framer on a Beaglebone. It notes the problem that the framer for that doesn't support the negative backporch signal the Mac CRT expects; I wonder if the "h_sync_polarity" inversion flag the Raspberry supports would help there...?
That sounds (partially) promissing.

 
The 9" VGA monitor solution proves to be rather expensive. Is there a reason?
I think that's mostly just a matter of the "old stock" for those things having finally run out. (The 9" B&W VGA monitors were still being sold into the early 'aughts for applications like cash registers, but at this point they haven't made any new ones for the better part of 20 years.) It seems like when they do show up on eBay it is almost always as old stock instead of used; my suspicion is they're the piece that dies first in the POS terminals they're a part of.
 

How are you progressing?
I haven't been working on it myself, I don't have a spare compact Mac to do it with. I do sort of wish I still had something like an old NEC Multisync monitor that could conform to Macintosh-like scan rates, it would be a good proof of concept to take that VGA cape for the Raspberry Pi and program it to output a Mac-spec video mode.

 
I messed with the LCD to GPIO setup on the Raspberry Pi at work. 

Cool thing is, you can modify the front porch, back porch, blanking, etc timings to whatever you want. 

 
but his solution does have the potential of destroying the Pi if the analog board goes wonky
Yeah, he's definitely playing it a little fast-and-loose tying the drive lines directly to the GPIO lines without any buffering. The Raspberry Pi doesn't have any built in.

Note in the article he also talks about using DPM to drive it directly, which is essentially what we've been speculating about above. (IE, using the GPU framer directly instead of driving it via the I/O processor and having to "fake" it. It's a shame he never got to that.

 
Note in the article he also talks about using DPM to drive it directly, which is essentially what we've been speculating about above. (IE, using the GPU framer directly instead of driving it via the I/O processor and having to "fake" it. It's a shame he never got to that.
I mailed him a couple of days ago and asked him specifically that - he told me he has something and will get back to me on this. If it's a reasonable approach I will of course share it here :)

I messed with the LCD to GPIO setup on the Raspberry Pi at work. 
techknight, have you got to a working solution?

I openend and cleaned my Macintosh from the inside yesterday. I had a quite distorted checker-pattern on the screen and no sound when turning it on. "Scrubbing" the logic board with isopropyl and a old toothbrush helped, it turns on now but can't boot from the hard disk. Going through the forum I suspect something like this 'sticktion'.

Makes me almost reconsider and restore the original hardware to working condition... :)

In any case, I'll try not to modify or damage any of the internals, neither case nor electronics. If those are still in working condition, I want the whole piece to be kept restorable and I'll keep the internals in a secured box in the basement otherwise. It seems to be in quite good shape.

Or I get a second one.

Ah I see already where this goes. :P

 
Back
Top