Mac Plus video signal details needed.

[MarkS]

My Mac Plus' analog board went out. While I could just replace the components, I thought it would be much more fun to switch out the CRT and analog board with a custom designed power supply and a FPGA controlled LCD.

What I need to know is how the video output is structured. The FPGA will provide its own h sync and v sync signals for the LCD, so those can be ignored from the Mac. I'm assuming that the video output is just a series of 5v pulses indicating whether a pixel is turned on or not, but I don't know if this signal is tied to the h and v sync signal. If I remember correctly, the screen is 512x342 pixels, so if it is just a series of pulses, there should be 175104 of them.

Does anyone have more details on this matter?

 

[tomlee59]

While theoretically possible, it's a non-standard engineering task to infer both H and V sync from the Mac Plus's video signal alone, so unless you have designed the circuitry to do this, you may be in for a disappointment. It's not like TV, where a composite video signal purposefully embeds sync information along with the video.

But that's not all. Unless your FPGA implements the equivalent of a PLL, you will also need the raw ~8MHz (7.8336MHz, IIRC) pixel clock from the Plus.

Maybe you already knew all this, and have designed the circuitry accordingly. But I just wanted to make sure that you weren't naive.

As to the Plus, some details on its video circuitry (and other topics) are here: http://68kmla.org/files/classicmac2.pdf

 

[MarkS]

I'm going to use a 640x480 monochrome LCD. Its the smallest that I can find that is big enough to fit the whole screen image. Because of this, the h and v sync signals from the Mac will be useless, so the FPGA will have to create its own for the LCD. Even if the LCD was the same size, I seriously doubt I could use the sync signals directly from the Mac.

The main issue for me is decoding the actual video signal (pin 1 on J4 from the classicmac2 PDF). What I need to know is if it is just 175,000 TTL level pulses in sequence, or is it in some way tied to the sync signals. Basically what I'm asking is if I were to take that video signal and save it to disk, would I be able to reconstruct the bit image from this saved data by simply reading 512 bits of data at a time and turning on the appropriate pixels within that row?

 

[tomlee59]

The video on the Plus is truly binary monochrome, not greyscale. Without separate sync data, however, you don't know exactly where the start of a frame is, nor where the start of a line is. Video does not possess a guarantee on the density of transitions, so if I have an all-white line of video, for example, there is no way of knowing where the actual pixel boundaries are. So, as I mentioned, unless the display interface possesses rather specialized circuitry, you will need to use more than just the video signal.

And although the video data is binary, you can't easily just "save it to a disk." Again, if I have 99 white pixels in a row, I can't easily distinguish that from 98 or 100 white pixels in a row. That's why you need sync. An alternative would be to oversample the data prior to writing to a disk. You could do the equivalent operation in the FPGA. That's an example of what I mean by "rather specialized circuitry" -- it's not the sort of thing that is normally part of an LCDisplay interface.

And that, in turn, is what makes the project challenging. You will need to figure out how to use the sync signals generated by the Plus.

 

[MarkS]

Very good points. I never considered how to read a single horizontal line... I do understand that I cannot save the data to disk; that was merely to explain what I want to do.

Clearly, I will have to use the sync lines, but only to determine where in the data stream the pixels actually are. I guess that my first point of business is getting a suitable power supply built so that I can test the signals.

 

[MarkS]

Correct me if I am wrong here...

From reading the classicmac2 PDF in more detail, it looks like the video signal is a series of TTL pulses, but inverted, i.e., 1 = white and 0 = black. Hence, the inverter, U2. The horizontal sync signal is a series of TTL pulses that basically acts like a 22KHz oscillator and notes where the individual pixels are in the video data stream. The vertical sync signal is high while scanning from top to bottom, and low during retrace.

If this is correct, I should see something along these lines when connecting the three signals to an oscilloscope:

video: 100100101010110111 <- or whatever the pixel data for that scanline shows

h sync: 101010101010101010 <- continuous

v sync: 111111111111111111 <- until the last pixel, at which time it becomes 0.

Correct?

 

[tomlee59]

Not quite. Both the Hsync and Vsync signals are periodic (but not 50% duty cycle). The Hsync signal provides one pulse every line time (call it 50us to keep round numbers). The Vsync signal provides one pulse every frame time (say, 15ms).

Hope that helps.

 

[MarkS]

Right. Vsync stay high until retrace, at which point it drops to low (once per frame). Hsync is a little bit more confusing for me. This changes once per scanline?

I think my best bet is to provide a clock input to the FPGA of 7.8336MHz. This would be the series of operations, greatly simplified:

1.) At start up, wait for a low on the Vsync signal, indicating a new frame.

2.) Once per clock cycle, I'm not sure on the rising or falling edge, write the value of the video signal to the correct position (a simple counter would suffice) in the frame buffer.

3.) When the Vsync signal goes low, write the buffer to the LCD.

4.) Go to #2.

 

[tomlee59]

I dug through my PileO'Stuff and found my old notes on video timing. So here are the real numbers:

1) Pixel clock is 15.6672MHz (= 2 x 7.8336MHz). You can use both edges of the CPU clock (if 50% duty cycle) or use the raw 15.7662MHz clock (or regenerate it yourself).

2) Horizontal line frequency is 22.25kHz (44.93us).

3) Frame rate is 60.15Hz (16.626ms).

Hope these numbers help some.

[Oh, and yes -- the Hsync signal pulses once per horizontal line, just as the Vsync signal pulses once per frame.]

 

[Bunsen]

Would it be possible to slurp the video info directly from the VRAM?

 

[tomlee59]

Would it be possible to slurp the video info directly from the VRAM?

The original compacts all used DRAM for main memory and video (and sound), so pulling out video data is marginally more involved than if there were dedicated VRAM. But the complexity of keeping track of horizontal and vertical sync doesn't disappear even if you have access to the video data in memory. Or maybe I don't understand what you have in mind?

 

[Bunsen]

Ah. Well, there are quite a few examples of using microcontrollers to directly create VGA or PAL/NTSC synced video in software. MBHP TV is another example.

What I had in mind was taking the video data from RAM and using those projects for inspiration to send that image data to a screen, bypassing the Mac analogue video circuitry altogether. That way there's no need to sync to the Mac video signal, only to the receiving screen (if I understand correctly. It's entirely possible I'm missing something here)

It might even be possible to send it to a graphical LCD, if there's one with enough pixels and a fast enough refresh. (And cheap enough). NB "fast enough" might not necessarily mean "as fast as the Mac's video".

The Parallax Propellor might be a more suitable uc for such a project, as it's way more powerful and has plenty of video output routines already created. It's also got 8 parallel processing cores, which is kind of nifty for a $20 chip.

I've thought a little about this in the past as a way of creating a classic Mac "laptop"/palmtop/UMPC, sort of like a modernised Outbound.

I hope that's clear enough.