Treating oldschool right

After completely redesigning our A/V chain last year, this year will be one of improvement and refinement.

We’re adding more integrated overlay graphics, comfort outputs for operators, and perhaps most importantly, upgrading our handling of oldschool signals. This is a post about the latter, so strap in for some hardcore video talk!.. :)

Last year, we used the Framemeister, which is a product that can do almost anything to convert incoming analog signals, but unfortunately is fairly buggy, which caused problems. Instead of the Framemeister, we are basing this year’s oldschool A/V chain around the OSSC (Open Source Scan Converter).

The OSSC is a much simpler unit than the Framemeister; it doesn’t do scaling, just converts each line from analog to digital as it goes (with a line buffer, so that it can line-double). The advantage is that it is much easier to get it to convert the signal correctly; the disadvantages are perhaps best illustrated by looking at the case of the Commodore 64 signal.

The curious case of Benja.. the C64

The C64 is a difficult case because its output signal is out-of-spec in so many ways, and thus difficult to hook up to more modern equipment that expects a more regular signal. Last year, we ended up using its composite output via a scaler known as the Framemeister, which worked well, but left the picture quality somewhat lacking. Thus, we’re testing a somewhat more involved avenue this year, involving the Y/C signal (luma/chroma) from the monitor port.

The problems start already at the cable. The Y/C signal was never designed for anything except Commodore’s own monitors; it happens to be fairly close to an S-video signal, but the signal levels are too high. (Also, even though all signals from the era were supposed to be interlaced, it only ever sends even fields so that it gets a fake 312-line progressive signal instead of a 625-line interlaced one, but that’s fairly common in oldschool devices, and the OSSC is designed for exactly this kind of case.) Thus, when converting to S-video, one needs a few resistors on the chroma line, or the signal levels will tend to be too high, and you’ll lose sync in very bright scenes. (Thankfully, if you buy a pre-made cable made for the C64, it will already contain such a resistor, but be sure to check!)

Unlike the Framemeister, the OSSC doesn’t accept Y/C signals, only RGB. (This is a hardware limitation; it just doesn’t contain the converter circuitry needed.) Thus, you need a Y/C to RGB converter between the C64 and the OSSC (and it needs to be analog, since as we will see later, digitizing the signal is not that easy). These used to be fairly commonplace in the 80s and 90s, and some VHS players contained them, but no suitable ones are in production anymore.

The Sony YR-1000 and YR-3000 (as well as a special French model, the SFR-3000) are fairly popular choices, but tend to be gobbled up fairly quickly on eBay; we found a fairly cheap JVM KM-V7EG second-hand in Switzerland and managed to get it home, and it works well. (The Canon RGB-100 also seems to show up every now and then used, but there seems to be little data on whether it would actually work with the C64 or not. It’s probably worth a shot if you could find one for cheap, though.)

Post-conversion step

After the conversion step is done and the OSSC has converted the 312p50 Y/C signal into a 576p50 HDMI one, you’d think everything was fine. But alas; the C64 has more idiosyncracies up its sleeve. The PAL C64 signal isn’t 50 Hz as one would expect; instead, it’s frequency-divided from the same oscillator as is used for the CPU clock, which means it ends up at 50.12 Hz (the OSSC says 311p at 50.27 Hz instead of 312p at 50.12 Hz, but supposedly, 50.12 Hz is correct).

This was presumably done to save money on oscillators in the early 80s, but also has a nice side effect that the CPU and the screen is synced up nicely, with a fairly consistent 63 cycles per display line (ignoring the so-called “bad lines”). You could imagine just reducing the speed of this master clock by 0.24%, but then the color subcarrier (which is the master clock divided by 4) would be off and you wouldn’t have colors anymore. (Also, it would throw off the timing to the disk drive, so that the most sensitive fast loaders would no longer work.)

50.12 Hz, however, is way out-of-spec for a signal that’s supposed to be 576p50, and our display chain promptly refuses to accept it.

Thus, a third device is needed.

Time to decimate

We’ve rented a Decimator MD-CROSS v2 which is capable of taking in the signal and converting it to a clean, in-spec 720p50 on SDI. (This means it needs to drop a frame every eight seconds or so, but there’s really no alternative unless everything in your chain, including the projector, is happy with running at 50.12. We reconfigure the chain from 60 to 50 Hz when running oldschool demos, though!)

So that makes for no less than three converters in the chain between the C64 and our (software) video mixer. The result is worth every bit of it, though; compare the image from the composite output (top) to the Y/C variant through the OSSC (bottom):

ZOMG! TOTES WORTH IT! This project wouldn’t be possible without the following people, who all lent out invaluable equipment:

  • Sir Garbagetruck / ACC (OSSC)
  • Frode van der Meeren (C64 and 1541, for pre-testing)
  • SLC / Kvasigen (diskettes with demos, for pre-testing)
  • Stig Roar Aftret (Decimator, for pre-testing)

PS: As the Ultimate 64 is rapidly maturing, we’d be very interested in feedback from C64 sceners on whether it is considered an acceptable device for running demos on. It would certainly be easier just having a device that outputs a HDMI signal in the first place (even though it’s still 50.12 Hz), but we’d love your opinions in the comment field on whether we should go for it or not!

Oh, and here’s a bonus: a capture of Deus Ex Machina through the OSSC chain described in this post:

Note: 50.12 Hz dropped down to 50 Hz, so you’ll see a one-frame glitch every eight seconds or so. The interlaced effects certainly look the best in 50 Hz, so they will look funny on a 60 Hz screen :-)

3 Replies to "Treating oldschool right"

  • comment-avatar
    June 11, 2018 (15:11)

    Well done, although I lack a modern webbrowsing device that runs on 50Hz, so I cannot check the interlace quality right now! ;-) A dropped frame all 8 seconds is a bit meh though, imagine something like the FLT/Offence demo with the continuous scrolling with a jerk every 8 seconds! have you considered simply resampling the audio by factor 1.0024 after capture and letting video run at 50Hz?

    Now, since you’ve done so well, go capture Risen from Oblivion. VIC *and* VDC side! ;-D

    DeeKay/Crest (what’s dun dat Deus Ex Machina gfx! 8)

  • comment-avatar
    June 19, 2018 (18:58)


    This solution isn’t meant for capture; it’s how we’re running demos live. So no, we can’t just slow down the video; that’s not going to work. :-) Not to mention the problem mentioned in the article itself, namely that our equipment doesn’t support 50.12 Hz signals in the first place. So even if we had some way of slowing everything down live, we couldn’t get the 50.12 Hz signal into the chain.

  • comment-avatar
    June 30, 2018 (02:04)

    As usual things are way more complicated than expected! Interesting read!

Got something to say?

This site uses Akismet to reduce spam. Learn how your comment data is processed.