The Pi Pico's PIO units should be able to be clocked to sync up to with the Mac and easily get accurate pixel samples without having to oversample. Some math would be involved to figure out how to divide the system clock (48MHz) down to the pixel clock and setting the PIO unit to run at that speed. So it could do something like:

wait for hsync to drop (maybe) wait out of front porch time read 512 pixels and send them to the main CPU - main CPU reads the pixels with DMA and dumps them into the frame buffer repeat until vsync loop

The second PIO can run the VGA or DVI code to output the frame buffer. I'm not sure how do mix in an overlay but some of the examples might have a method of doing it. The main CPU cores can mine bitcoin or something while the PIOs do the hard work. Or maybe talk to an ESP32 for WiFi and the VNC server.
Oh, it probably needs a level shifter chip so the 5V video signals don't burn out the 3.3V inputs.

Here's a link to the DVI sock PCB that someone might find useful:

https://github.com/wren6991/pico-dvi-sock

@retr01 .... Its the main power & vid+sound connector on the mainboard ive shown before

Here I did also find the schematics for the classicI/II confirming pinlayout to the Analog board-monitor section.

I think of making a patch cable loom from my fully functioning CLII so I can experiment with a Pico Pi.
(having a working 9" display)Then when in working order create a new PSU -Pico connector loom to the board?

>> luminescentsimian said:

The Pi Pico's PIO units should be able to be clocked to sync up to with the Mac and easily get accurate pixel samples without having to oversample. Some math would be involved to figure out how to divide the system clock (48MHz) down to the pixel clock and setting the PIO unit to run at that speed. Click to expand...

I think the clocking strategy you're describing actually won't work since you can't divide 48 MHz into the 15.6672 MHz pixel clock. Maybe you can do 48 MHz / 3 = 16 MHz but because there is a frequency difference and therefore no consistent phase alignment, some kind of correction for the oversampling is required. Even if you run the Pi at a multiple of 15.6672 MHz and get the pixel clock that way, it won't work because the two 15.6672 MHz clocks will wander with respect to each other. Even (over)sampling at just 16 MHz, it's impossible to reconstruct all the pixels coming by at 15.6672 MHz. Nyquist-Shannon sampling theorem says you need > 31.3344 MHz sample rate and in that case you would have to do the oversampling decimation thing I described. Maybe 48 MHz sample rate (i.e. 3x oversampling) is good though and the 62.5 MHz rate (4x) I mentioned is overkill.

Another problem with the Pi Pico is that, uhh, I think I was confusing it with the Pi Zero back in February when we were discussing the oversampling algorithm. It would require some pretty tight code to keep up with transforming the oversampled pixels into the real 512 pixels on the Pi Zero's 48 MHz Cortex-M0+ CPU. The big RPis are much more capable so I don't think processing time would be an issue. But on the Pico, sampling at 48 MHz, we would have to process one byte of sample points every 8 clock cycles. Too tight for a 48 MHz C-M0+ I think.

@-SE40-did you see the video by Adrian that I shared? He showed precisely where in the Classic to tap from the AB to get the video signal, as you indicated in that part of the schematic.

Unless you say there is another location on the Classic / Classic II LB where the video signals can be tapped?

@retr01 .... Yes!.....this is the cable that runs between the logic an analog board.
Grey - Violet - White
At least that is what I have to look into.
This is the easier place to connect cables into a Pi. But I have no analog/psu-monitor board and so pick up the signal from the mainboard. At least thats my idea to solve this. Plus I do not have the space lateron for an analog board.

Ah! :D [idea] @-SE40-, it is also possible to tap the video between the connector on the LB and the harness to the AB by an adapter similar to the Power R 2703:

>> -SE40- said:

Yes!.....this is the cable that runs between the logic an analog board. Click to expand...

Correct. :) That is the whole point of the Power R video adapter between the LB and harness to the AB. And then now there is a GitHub repo by @Stephen about that. :D

And now @Zane Kaminski, @alxlab, and @luminescentsimian are discussing using Pi Pico to convert the signal instead of RGB2HDMI (simple knife versus swiss army knife, other tools that are not needed). [grinning-face-with-s]

>> -SE40- said:

Grey - Violet - White Click to expand...

and black!

Yes!

and so hoping for that should reduce (skip) the analog board section...as this is what is essential for a Classic II laptop version.

>> -SE40- said:

Yes! and so hoping for that should reduce (skip) the analog board section...as this is what is essential for a Classic II laptop version. Click to expand...

Correct. When Adrian did that video, he already had those wires tapped there on the AB; that is why he connected there. I agree that tapping to the AB for video signals is not needed, especially when wanting to use LCD instead of CRT.:)(y)

[four-leaf-clover][check][four-leaf-clover]
Next I will check on the speaker connection.
If there is an amplifier or such on the AB board

>> Zane Kaminski said:

I think the clocking strategy you're describing actually won't work since you can't divide 48 MHz into the 15.6672 MHz pixel clock. Maybe you can do 48 MHz / 3 = 16 MHz but because there is a frequency difference and therefore no consistent phase alignment, some kind of correction for the oversampling is required. Even if you run the Pi at a multiple of 15.6672 MHz and get the pixel clock that way, it won't work because the two 15.6672 MHz clocks will wander with respect to each other. Click to expand...

The PIOs do fractional clock dividing. A quick test in circuitpython say `real frequency 15663240` when I request 15.6672MHz, that might be enough to hold for 1 scanline. My Salae logic analyzer only does 12MS/s so I guess it's not fast enough to capture individual pixels but when running a trivial 4 on/4 off PIO program I get a mostly square waveform around 2Mhz.

>> Zane Kaminski said:

Another problem with the Pi Pico is that, uhh, I think I was confusing it with the Pi Zero back in February when we were discussing the oversampling algorithm. It would require some pretty tight code to keep up with transforming the oversampled pixels into the real 512 pixels on the Pi Zero's 48 MHz Cortex-M0+ CPU. The big RPis are much more capable so I don't think processing time would be an issue. But on the Pico, sampling at 48 MHz, we would have to process one byte of sample points every 8 clock cycles. Too tight for a 48 MHz C-M0+ I think. Click to expand...

The base clock is actually 133MHz. I don't know where I got 48MHz from.

I was thinking I could try out the idea with my Rainbow but it's video is composite not TTL and I don't have anything else old enough to generate these sorts of signals. Le sigh.

>> luminescentsimian said:

The PIOs do fractional clock dividing. A quick test in circuitpython say `real frequency 15663240` when I request 15.6672MHz, that might be enough to hold for 1 scanline. My Salae logic analyzer only does 12MS/s so I guess it's not fast enough to capture individual pixels but when running a trivial 4 on/4 off PIO program I get a mostly square waveform around 2Mhz. The base clock is actually 133MHz. I don't know where I got 48MHz from. I was thinking I could try out the idea with my Rainbow but it's video is composite not TTL and I don't have anything else old enough to generate these sorts of signals. Le sigh. Click to expand...

Oh, huh. Well 133 MHz is much more workable if we have to do the oversampling.

And yeah, I think 15.663240 MHz is close enough for one line. Only differs by 11 nanoseconds (i.e. 1/6 of a pixel) by the end of the 704-clock line. But how do we ensure we start the SPI transfer in the proper alignment with the video signal? We need to wait a precise amount of time after the HSYNC falling edge and then start the SPI transfer so as to align the centers (ish) of the correct 512 pixels in the middle of the SPI sample clock. It may be possible but any interference from other elements of the system will spell timing disaster. A pixel is 63.8 nanoseconds so that's 8.5 clocks wide at 133 MHz. Therefore we have something like a 4-6 clock range of time where the SPI transfer has to start so as to line up correctly at the middle of the line without getting too far off by the time the 11 nanosecond error accumulates at the end of the line.

Morning! :)

It makes sense to use the software approach to over-sample and then process the output on the modern screen. Will that approach still create the exact (or close enough) replica of the original screen behavior and results?

How about comparing Pi Pico to the R Pi Zero that the current RGB2HDMI adapter uses? If the Pico underperforms that over sampling is needed, does over sampling also happen with Zero in the current RGB2HDMI?

One interesting observation by Adrian in his RGB2HDMI on Mac Classic video, a vertical line or two did not reproduce the cross-hatching correctly. :oops:

>> Zane Kaminski said:

And yeah, I think 15.663240 MHz is close enough for one line. Only differs by 11 nanoseconds (i.e. 1/6 of a pixel) by the end of the 704-clock line. But how do we ensure we start the SPI transfer in the proper alignment with the video signal? Click to expand...

The PIO units do their own IO on their own clock, so there's no need to use the SPI engine. It can delay X pixel clocks after detecting the end of HSYNC and then start reading on the next cycle. By default GPIO reads will be queued for the main CPU in 32-bit words in a 4 or 8 word deep FIFO and the DMA engine can be triggered after each word to fetch those pixels to RAM without involving the code running on the main CPU cores.
Hmm, may need to double the clock so there's time for a conditional JMP at the end of scanlines

Didn't see any source material from the CatMac/Hackintosh days in the thread. I was moving documentation around today and misplaced the three PCB pics I'd associated with this article:



I'll try to find and edit the pics in later if you guys would like or not if you don't. IIRC TTL -> VGA is pretty simple, no? Maybe just for shiggles and gits if of no practical use in this project? :)

>> Trash80toG4 said:

Didn't see any source material from the CatMac/Hackintosh days in the thread. I was moving documentation around today and misplaced the three PCB pics I'd associated with this article: I'll try to find and edit the pics in later if you guys would like or not if you don't. IIRC TTL -> VGA is pretty simple, no? Maybe just for shiggles and gits if of no practical use in this project? Click to expand...

Sure! :) (y) Seeing what was done back in the day is nice. Was this from a book?

It's from a book called Macintosh Repair & Upgrade Secrets

>> retr01 said:

Sure! Seeing what was done back in the day is nice. Was this from a book? Click to expand...

It's from the Macintosh Repair & Upgrade Secrets book by Larry Pina. I just posted it up in the resources:

https://tinkerdifferent.com/resourc...e-secrets-for-models-128k-to-macintosh-se.42/