Everything I ever wanted to know about the Apple IIgs RGB monitor signals

My favorite 80's computer by far is the Apple IIgs.  I had this machine as a kid growing up and thought it was awesome.  I think I was even more stubbornly loyal because so many of my peers refused to give it the respect that it deserved.

Well, the Apple IIgs stock RGB monitor is intriguing to me because it is relatively small and I do a lot of work with arcade game PCBs in a bench type setting.  I have a need of a nice compact RGB monitor for testing and so if I can somehow use the Apple IIgs monitor for this purpose, that would be awesome.

I asked a question on Facebook about the Apple IIgs RGB signals and got no response.  Either no one knew the answer or no one knew why I possibly would want to know. :)

Never one to rely on other people to achieve my goals, I decided to take matters into my own hands and created a little break-out PCB so that I could 'sniff' the RGB signals myself and get my own answers.

The first step was to whip up the schematic in Eagle:

I whipped this up as fast as possible because I knew that I would only need this board once and then probably would never use it again.

I spent an equally short amount of time on the PCB layout:

This was a mistake to rush through this, but not a fatal one.

On a recommendation from a friend, I decided to use pcbway.com to make the PCB.  To my shock, I had the PCB in my hands in only 7 days after placing the order.  And it was from China!!  Only cost me $10 for 10 boards (why buy one when you can get ten? lol) and $20 for shipping which is a steal in my book.  Awesome!

After ordering the rest of the parts I needed from digikey.com, I whipped out my soldering iron and got to work.

It was then that I realized my mistake.  I wasn't paying close attention to the DB15 datasheet and ended up having the two connectors facing INWARD instead of outward.  That simply was not going to work!!!

Not to be defeated, I decided to solder on wires and hack the thing together enough to do what I wanted.

I plugged it in ...

and turned on my IIgs ...

it was working!! WOOHOO!!!

Once I got this far, I decided to hook up my Rigol scope to the CSYNC and BLUE signals to see what kind of voltage levels I was getting.

I decided to use a nice nearly solid blue screen so that I could see what the full blue intensity would be.

First I wanted to see what vsync looked like:

Interestingly, the blue signal seems to also contain sync information.  I really don't understand why they would do this and I strongly suspect that this monitor will probably work without the sync info being part of the color voltages.  But I guess I'll find out.  At any rate, I observed that the sync was a fairly typical negative composite sync signal going from 0-5V with hsync being mixed with vsync.  I've seen it both ways where the vsync is a solid low pulse and where vsync has hsync mixed in with it.  This is, I believe, what the jamma csync looks like (or is pretty close at least).

Next was to see what the voltage range of the blue signal was by going to a random line in the middle of the field/frame:

 It looked like the voltage was going from 0-1V.  I'm glad I checked this because I would've assumed it would've been from 0-5V.  If I do rig up arcade PCBs to talk to this monitor, I'll probably need to drop the voltage down to avoid damaging stuff.

Next I wanted to zoom in on an hsync pulse and see how wide it was:

Nothing earth-shattering here.  Just wanted to document it :)

Just to be sure I was seeing what I thought I was seeing, I decided to switch the screen to a black background with blue border:

This is what I was expecting.  By zooming in a single line, I was expecting to see 1V near the beginning of the line, followed by a drop in voltage to indicate black, followed by 1V again toward the end of the line, and that's exactly what I am seeing here.  Interestingly enough, black seems to be around 0.3V, not 0V.  It seems that 0V is reserved for sync signals.  This is pretty similar to how NTSC composite works.

Again, I suspect that it is not necessary for the sync signals to be part of the blue signal, but maybe I'm wrong.  Why would Apple go to the trouble of including it if they didn't have to?  Maybe it was part of the RGB encoder they used. *shrug*

The last thing I wanted to document was whether this signal had fields like an NTSC signal.  The NTSC signal's vsync pulse is slightly different depending on whether it is a top or bottom field.  I wanted to see whether this RGB sync had the same kind of characteristics.

Using a scope was probably not the best way since I didn't have a good way to trigger on vsync.  Therefore, I switched to using my Saleae logic analyzer to measure distance between vsync pulses:

Here's a logic analyzer capture zoomed in on a vsync pulse.  It looks similar to what it looked like on the scope except more well defined :)

Zooming out, I was able to put time markers on each vsync to see the intervals:

As you can see, the interval between each vsync pulses is "exactly" 16.689 ms with no variation.  This means that it is a ~60 Hz signal but that it not like NTSC composite where top and bottom field vary.  However, I am not sure what it _does_ mean :)  I don't  have a lot of experience with progressive signals, but if I were to guess, I'd say that this is a progressive signal and that the entire frame is being sent 60 times per second.  The hsync pulses were similar to NTSC (63.5uS apart) so I'd guess that this means that this signal is describing 525/2 lines just like NTSC (~262.5ish but without the decimal since it's progressive).  That would kinda make sense since the IIgs can display 200 vertical lines and it has this extra border on the top and bottom.  But I'm kinda just speculating at this point.

At any rate, I've concluded that in order to get this monitor to work with arcade games, I'm going to need to do a few things:

a) if arcade game has separate positive vsync and hsync, I'm going to need something like an xnor gate to combine them.  Otherwise if it's just a jamma csync signal, I may be able to use it unmodified.

b) if arcade game RGB voltages are 0-5V, I'll probably have to add some resistors to drop the voltage down to 0-1V.  This may be something that I play around with until I find values I like.

I hope you enjoyed my journey.

Subtle defect with Raspberry Pi NTSC video output

I've known about this Raspberry Pi NTSC defect for a long time.  The reason I haven't reported it is because I have been too lazy to provide a way to reproduce the defect.  Unfortunately, reproducing the defect requires an oscilloscope but otherwise it is something most anyone should be able to do.

Tools used to reproduce defect:
- LM1881
- Rigol DS1054Z oscilloscope
- Raspberry Pi B+ with Raspbian dated 2015-02-16
- A specially crafted PNG file
- The 'fbi' program

First, let's talk about why I am using an LM1881.  I am using it as a trigger for the scope so that I can get a consistent stable view of the problem.  To make sure everyone is on the same page, here is a part of the datasheet that defines the "field" pin:

So when the field pin is high, an "odd" field is starting, when the field pin is low, an "even" field is starting.  Also, in NTSC land, odd means the top field and even means the bottom field.  This is kind of backward from how computer science geeks think of things, because we think that the first item in a list is 0 which is an even number.  But in NTSC land, the first line is 1, not 0.  For this reason, I will refer to the fields as odd/top and even/bottom to avoid confusion.

Here is the specially crafted PNG file that I made.  It is almost black except for the top 3 and bottom 3 lines:

The resolution is 640x480, the 480 part being the crucial part here to match NTSC's 480 lines.
The top and bottom lines are solid white.  The second and second to last lines are grey (7f7f7f) and the third and third to last lines are solid white but only go halfway across the screen.  I chose these lines so they could be easily identified on a scope.

To reproduce the problem, I booted the raspberry pi in NTSC mode (with a TV plugged in so I could see).  I then ran the command "fbi rpi_ntsc_test.png" and pressed 'V' to disable the status bar once the image was displayed.  I then hooked one scope probe up to the NTSC signal and the other scope probe up to the "field" (odd/even) pin of the LM1881.

Here are the results with comments:

Conclusion: At the very least, the fields are currently being reversed in this iteration of raspbian and the pi (B+).  There may be additional problems since the first visible line according to NTSC does not line up with what the Pi is doing (see my notes in the PNG files).

In the past, I observed potentially different issues on earlier revs of the pi which are not important to note anymore.