The Search For New Output

Well, this has been both frustrating and fun at the same time. As you might know, I lost my CRT to power issues (possibly a bad cap that just needs replacing). After that loss, I've been trying to come up with a way to present the output from KAPE GPU so that I could continue on the software portion while I wait for a replacement CRT or parts for the broken one. I came up with a few possibilities I could try out:

1. Create a software emulator on the PC that I could work with to improve the GPU command structure
2. I happened to have some MC1377P RGB to Composite encoder chips on hand - just wire these up and use my composite capture card to view the output on PC
3. Modify the circuit a bit and do an additional grayscale weighted resistor DAC to be tacked on the sync line, which would work as a grayscale version of the screen and capture that

So, about option 1, software emulation - nah, don't feel like it. It would probably get Wreckless Abandon (the 2D platformer I'm doing on the side to be played on the end product) development forward as well, and I could possibly do it so I just had a similar framebuffer memory as in KAPE GPU, draw that every frame with say MonoGame, and do some interprocess communication method to send bytes to the simulator (instead of using the COM port to an debug interfacer UNO). If I cut enough corners, I'd probably even manage it in a few hours. But this project isn't about software, it's about hardware. So I want to do a hardware solution for this.

I (Don't) Got The Power!

So, 2 it is then. Oh boy did I have a lot of problems. And spoiler alert, in the end I didn't even manage to make it work properly. My first problem was power: the MC1377P (datasheet) actually needs +12V, not +5V. Luckily the chip has an internal +8.2V regulator, so the Vcc can be unregulated. But how do I get +12V from +5V? I had the idea of making a charge-pump with some capacitors and diodes and a PWM signal from an AVR chip (or the UNO), but either I screwed something up, or you just can't get enough current from a DIY charge-pump. (The chip needs 35mA on normal operation). 

I then found some ICL7660S (datasheet) negative voltage converter chips on my chips-pile, and reading through its datasheet, it could be wired as a voltage doubler, and it should just have enough current to make things going. I'm yet again on the territory of "either I have no idea what I'm doing" (to be fair, I actually don't!) or perhaps the chips were faulty/chinese fakes/etc. as I couldn't get them to work at all. In the end I tried just wire them up as their normal usage and do a negative voltage converter, but even without a load, I couldn't get -5V out where it was supposed to come out from, at no load.

I quickly realized I'm not going to be able generate +12V from +5V, at least with my current components or knowledge or both. So, I started looking for an alternative. I do have a +18VAC wall plug, and a useless (these days, it wasn't then) board that has a fitting barrel plug, so I was thinking I could maybe make a full bridge rectifier with some diodes and filter it out enough to be in the 10-14V range MC1377P expects power to be. However, I decided to try something else first. My second monitor's power brick's capacitors went kaput a while ago, and I ended up hacking up a power cord from inside my computer from the PSU that delivers 12V to the monitor. So, I luckily had one available Molex on the power cord, and an extra Molex cable to use as a donor to cut up, and I whipped up a 12V Molex to 2-pin header power cable to be used on the breadboard from a connector from the PC's PSU. 

After all this, I tested the chip with a volt meter on the power pins. I should get 12V and 8.2V (Vcc and Vb, the internally regulated output voltage). What I got: 8.4V and 7.2V. What's even weirder, if I tested the voltage between +12V and ground wrong way, I didn't get -8.4V - I got -24V instead. I was at a loss. I tested all the chips I had this way, and none worked. I was ready to throw the towel in (at least for now) but then I came by a simple MC1377P circuit design:

I noticed it had filtering/decoupling caps at the +12V line. I didn't have 47uF cap handy, so I substituted it with a 22uF one. And lo and behold, the voltages started to make sense again! In fact, using this schematic, I ended up finally taking some strides forward in this whole ordeal.

Wired almost according to the simpler schematic.
12V power not connected, nor the RGB lines.

It's Not Progressive Enough!

Now I finally had something nearly-almost working. However, when I tried to capture the image with my capture card, it couldn't sync to the image. I tried plugging the composite cable from the KAPE GPU to the capture cards component input Y channel as well (this should just read as a sync + luma), and it still didn't sync. I had an inkling it was because my sync generation generates a progressive 288p signal, instead of an interlaced 576i signal. However, as I had taken great care to implement the equalizing and serrated pulses properly, all I needed to take care of was to make sure there was the correct amount of frame end and frame start equalizing pulses on both even and odd fields. I might be mixing this around but I think even fields should have 5 pre-equalizing pulses and 4 post-equalizing pulses, odd fields 6 pre and 5 post.

The synchronizing pulses for VSYNC in an even field.

It seems to be a bit hard to find out information about PAL and NTSC signals in a concise and easy-to-digest format, but this page (http://martin.hinner.info/vga/pal.html) helped a lot on getting this right. Thanks Martin Hinner!

I finally got the capture card to sync, and to debug and make sure all other timings were correct, I also implemented option 3 - grayscaling the 4 bit color value with weighted resistors - for helping me debug the new interlaced sync. I had to do some fiddling with the framebuffer read timings though, before getting everything working properly. In the end this actually worked really well - I finally got a picture from KAPE GPU to my very, very picky capture card.

I even tested it out with our LCD TV.

Btw. the TV's composite in is a LOT less picky on the timings than the capture card. I could basically massage the values every which way, I even accidentally disable all the serration and equalizing pulses and it still worked, but the capture card didn't capture it the moment one value was off by one. However, even the TV couldn't capture the progressive output, which is a shame. And kinda also the reason I prefer to work with a CRT with this project, as they support 288p out of the box.

I Want Some Color In My Life

So, now we have the proper sync timings, and we also have power to the encoder chip. All we now need is color through composite with the help of a chip, and that should be to just connect the lines and be done with it, right? Well, not so fast. The chip needs a 4.43MHz crystal oscillator for the chroma subcarrier reference. I don't have that. I do, however, have a 17.73 MHz crystal, which is incidentally 4 times as fast. So I could use the 17.73 MHz crystal with the KAPE Pixel Timer AVR chip (ATtiny84) replacing its normally used 16 MHz chip and 4.43 MHz clock with a timer.

Luckily, I push the pixels out from the FrameBuffer FIFO with an AVR clock divided by 4, so I get this clock actually for free. Using the 17.73 MHz clock though would mean that the pixel clock would be almost 9 MHz instead of the earlier 8 MHz, but it should still work correctly in the end - the 256 pixels long line would just be a smidge shorter, and the individual pixels a little thinner. 

Theres another problem though - can the MC1377 be driven with only a clock on oscillator pins, or does it expect something else? With a little help from eevblog forum, I realized that MC1377 expects a color subcarrier wave reference, not just simply a timing reference, which would be a 0.5 - 1 Vpp sine wave if you are driving the color subcarrier externally. Now, I didn't find anywhere in the datasheet at what DC bias the chip expects this sine wave at (0V?), so I just did a voltage divider from 5V through a 330 ohm resistor and a 100 ohm to ground and filtered it once with a 1 nF cap to ground. The result should be something along these lines. 

So, now that I have managed to tackle the power issues, the interlaced syncing issues to get the image to my capture card, and the chroma subcarrier wave the chip expects, I should be all fine and dandy? Well, let's see, after I wired everything up (the earlier shown simple MC1377 circuit design helped a lot with this!), I wired the RGB lines through 22 uF capacitors and sync I connected straight up (the chip should be okay with a normally 5V signal that just has sync tips dropped to 0V), and connected the composite cable through a 75 ohm resistor to the capture card composite cable ANNNND....

Umm. Well. That's not what I expected nor wanted. With a quick glance, it seems every other line is skipped (and it actually changes every frame which lines are skipped), the colors are obviously out of whack, they shimmer a lot, there is a lot of noise etc... but I'm so close I can taste it!

However, I feel like I've sunken too much time on this already. I'd really want to figure out what I'm doing wrong, and how I could fix it, but it feels like the MC1377 is a lot more trouble than it's worth. Something like AD725 seems like a lot easier to deal with, and doesn't need a separate power supply if you are already using 5V. It also uses the 4Fsc crystals which I have (the 4 times the color subcarrier frequency, ie. 17.73). The biggest downside is it's a surface mount - I'm trying to avoid surface-mount chips as much as I can, though in case I won't find anything better, I'll gladly use one. I don't really like soldering in general, and the only soldering I enjoy is through-hole - at least right now, maybe with some practice I'll learn to enjoy soldering surface mount parts as well.

Fine, I'll Just Get A New One

Not long after my old CRT broke, I managed to source a replacement 14" PAL CRT with SCART. However, it was a bit of a drive away, and my back went a bit bad a few weeks ago, so I've been avoiding driving long distances to let it rest a bit. I was hoping I could get the colors working with the MC1377, but as I was nearing the realization that it's a lot more trouble than I want and my back has been feeling a bit better lately, I decided today was the day to finish the deal and get that replacement CRT. 

I'll finally be able to get back to actually implementing the GPU, instead of fighting with components I barely understand. The image is still in black and white, but tomorrow I'll move the CRT closer to my setup again, and hook up the CRT and we should have sweet, sweet RGB color again, in all its 4 bit RGBI glory that KAPE GPU outputs!

Now all that said... Having a composite out in addition to SCART would be a nice thing to have on the GPU (if not separately, then just populate the SCART Composite pin with proper Composite data)... Maybe I should get back to MC1377 (or some other RGB to composite encoder chip) at some point in the development cycle? But at least for now, I'll let it be, get the CRT setup again and I can get back from this detour and get back to defining the GPU commands and actually making sprites work!