pouët.net

Go to bottom

Capturing C128 demo "Risen from Oblivion" + messy PAL signal + screenshots

category: offtopic [glöplog]
 
This demo is well-known for doing evil things with the PAL signal and thus looking different on different monitors. My one also shows a few bugs (topmost 1/4 of gnomes and top half of top frog image have red/green swapped, a few miscolored & shifted lines in the huge pic).

I wondered what's going on and thus connected the composite out to an oscilloscope and captured a number of frames for examining later on PC.

The reconstructed frames (greyscale with color carrier visible as fine waves) look really ugly with sync totally crippled and color burst also tampered with.

Finally I also implemented a simple software PAL decoder. It worked well so far... except for one thing: There's no longer any colorswapping at all, even the bottom frog image shows no more colorswapping (frog looks reddish as in the top image).

I implemented the color decoder like this:
(1) Get phase from color burst
(2) Compare with old phase (to determine whether to swap the color phase)
(3) Add +45° or -45° to phase from burst depending on result of step (2)

Does anyone know why some monitors fail to sync correctly and thus swap red and green (as intended with the bottom frog image or not as intended as described above)?

Pictures from demo after software decoding:
BB Image BB Image BB Image BB Image BB Image BB Image

The color info in the last picture is so messed up in 2 lines that I cannot imagine any monitor displaying this one correctly. Click for a modified version with correct colors.

Alsmost raw data, clearly showing how messed up the PAL signal is, including a shot with unmodified PAL signal for reference:
BB Image BB Image BB Image BB Image
added on the 2010-10-29 00:31:41 by Kabuto Kabuto
Quote:
Does anyone know why some monitors fail to sync correctly and thus swap red and green (as intended with the bottom frog image or not as intended as described above)?

The sign of V is inverted every rasterline in a PAL signal. So let's say odd rasterlines have +V and even ones have -V. The C64 has to generate a signal like that and because of this has to know if it is on an odd or even rasterline. If this counter is messed up, the sign of V is inverted.
added on the 2010-10-31 12:56:20 by Zonkham Zonkham
"The color info in the last picture is so messed up in 2 lines that I cannot imagine any monitor displaying this one correctly."

analog CRTs are more tolerant than moderns displays and capture cards...
added on the 2010-10-31 22:20:56 by Oswald Oswald
Doesn't the C128 have a DE-9 vga out? I think that was how my monitor was connected. But then again, the monitor that came with my 128 (donno what happened to it) had a RCA NTSC in that didn't quite work. The monitor had a switch that went from that would switch from the VIC to the VDC to RCA.
added on the 2010-11-01 17:47:00 by QUINTIX QUINTIX
proofread fail, but you understand what I mean
added on the 2010-11-01 17:48:14 by QUINTIX QUINTIX
Quote:
Doesn't the C128 have a DE-9 vga out?

I think it was a typical TTL video output and as far as i remember, it only does the monochrome 80 columns video out, so it won't help much ...
added on the 2010-11-01 19:49:51 by Paranoid Paranoid
As far as i remember, lots of the VIC effects are done by switching the C128 to 2MHz which messes up the PAL output but lets the VIC skip over... things :) faster.

So, just capture the video out at above 33ish MHz, let the decoder auto-detect the MHz switches somehow and go for it. Easy as pie :D
added on the 2010-11-01 22:41:13 by kb_ kb_
Ok, I've got a new guess.

The color burst is shifted +45° and -45° on alternating lines to tell the monitor whether to use +V or -V. So there are 2 pieces of information within a single color burst: the color burst phase and whether to invert V or not. By looking at a single line thus one cannot reconstruct both pieces of information; the color burst makes sense only in context with previous lines.

My initial approach was (not exactly, but effectively) to compare the color bursts of each pair of consecutive lines. The average phase is the actual phase (because +45° and -45° cancel out each other) and the phase difference tells whether to use +V or -V. This, however, also removed the red/green swap effect seen on real monitors so they must work differently.

My new guess is that real monitors use two different circuits for color phase and
+V/-V that both adjust slowly to the color burst. What generates the false colors in the frog picture would thus be the +V/-V circuity failing to readjust itself quickly enough after a line was skipped so it swaps the color phase in the wrong lines, effectively swapping red and green.

kb_: I've captured the video at 25 MHz, capturing at higher rates won't help IMO since there's a 2nd order (C64) / 3rd order (C128) lowpass with ~ 5 MHz cutoff.
added on the 2010-11-02 11:38:15 by Kabuto Kabuto
"As far as i remember, lots of the VIC effects are done by switching the C128 to 2MHz which messes up the PAL output but lets the VIC skip over... things :) "

2mhz doesnt messes up the PAL output, only the VIC can not control the bus anymore, so it will read what the CPU left there.

These tricks are using the test bit of the 128 type VIC, which does some weird things like skipping a rasterline each cycle or smth like this but I'm not sure at all.
added on the 2010-11-02 13:13:59 by Oswald Oswald
Sorry to resurrect an old thread, but is there anyway to PM you Kabuto? Could you possibly email me? shinobinz at gmail.com
added on the 2013-05-28 02:44:53 by KAPSY KAPSY

login

Go to top