RSYNC/VSYNC Experiment

[eshu]

I was having a look at the mysterious RSYNC for the nth time the other day, like I'm sure lot's of other people it's always intrigued me whether it could be used for some funky effects, such as playfield scrolling or overscan. The main stumbling block is that the HSYNC signal is tied to the horizontal counter as well as the playfield output, so it would seem like it's impossible to do anything cool, but it occured to me that there is one possible way. Because of the way VSYNC and HSYNC are combined to create the composite sync signal, in theory we might be able to use VSYNC to disable the normal HSYNC signal. I've had a quick play with some success, but I think my TV might be overly flexible with the signal. I was hoping someone might be brave enough to try the attached binary which is probably producing some awful out of spec signals....

 

I've set up four different kernels, three of which do potenitally interesting things. By default the binary runs a simple kernel which shows a playfield with cycled colors for the background.

 

Pressing up runs a kernel which seems to be stable on my TV, if it's working it should produce a black and white image offset quite far to the left.

 

Pressing right runs a kernel which seems slightly less stable on my TV and produces a less offset image, weirdly if you transition from up to right it seems to be stable, however theres some issues with the colourburst.

 

Pressing left runs another kernel which seems stable and produces some colours on my PAL vcs which I don't normally see....

 

So is anyone willing to give it a try and let me what it does with your VCS/TV?

 

Disclaimer: A best case scenario is this is sending slightly out of spec signals, it's quite possible I've screwed up and it's sending all sorts of weird sync signals. I don't think running it for a short burst should harm your TV but I'm no expert....

 

 

 

synctest.bin

[Wickeycolumbus]

Cool We definitely need to see more RSYNC experiments.

 

On my setup, pressing up yielded a left shifted display (perhaps around 10 pixels) with fixed colors on the top fourth and switched between b/w and color on the bottom 3/4. The colors grow downward periodically.

 

Right produced a left shifted display (around 8 pixels) with colors intact.

 

Left produced a right shifted display (2-4 pixels) with colors intact.

 

For left and right, even though all colors were intact the whole time, there was a noticeable change in them. I'd say they actually looked better than normal when right was pushed I don't have a camera or anything at the moment to capture the results, though I may be able to do so next weekend.

 

I ran it with an NTSC 2600 Jr and 13" Sony CRT.

[eshu]

First - thanks for testing - I really appreciate it, second - are you saying all those displays where stable, including transitioning between them - sweet if they were, some kind of hardware scroll might actually be possible

[Wickeycolumbus]

No problem! Yes, no rolling or anything. Nothing weird happens when you transition between them. There are graphical glitches at the top couple scanlines of the screen, and the playfield bends a bit near the top, but it is stable otherwise. I have a feeling that this will vary a lot between TVs and TIA revisions though.

[eshu]

cool - at the moment the sync adjustments are being done on the displayed screen to help me see what is going on - the could easily be done in VBLANK though, so those glitches wouldn't be visible. I really need to get a CRT......Sure I agree it could vary between TV's and TIAs - will wait for some more responses before I get too excited

[LS_Dracon]

Here's my test in a PAL-M tv 29".

 

First, PAL-M runs at 60 frames in NTSC resolution, so it's NTSC compatible, besides the name. And Atari 2600 show all 128 colors in NTSC order.

 

Pressing up looks really bad, loosing correct color information, sometimes flickering in B/W the whole screen, not only part of it.

 

Pressing right and left are stable, with stable colors.

 

Just the artifact at the top in all kernels.

 

If you can move the "left" kernel only 2 pixels (color clocks), you can finally make possible smooth horizontal scrolling, alternating between left kernel (2 color clocks) and PF scroll (4 color clocks).

 

EDIT : My Atari 2600 uses TIA revision 5 I think, not run fine games like Kool aid man.

 

Pictures in this order : Joystick neutral - Up - Right - Left

 

Edited April 26, 2014 by LS_Dracon

[Rybags]

In the video signal for most old Atari gear, the HSync will be XORed with VSync. This automatically generates the inverted signal you need for 3 scanlines around HSync with the short pulses returning to blank/black level and the long ones at sync level.

 

If you could change the control bits fast enough, possibly you could do RSync but not generate a HSync pulse which would reset the counters and in theory make the screen move horizontally. My thinking here is briefly have both HSync and VSync active then disable them both.

 

But the feeling I get is that even if you could hit TIA registers one per cycle it probably wouldn't be enough. Might be worth a try though.

[SeaGtGruff]

I'm not sure how well strobing RSYNC night work with video, since it will alter the scan line length and probably scramble the picture-- if not on all TVs, then certainly on some.

 

However, as it happens the other day I was thinking about a different potential use for RSYNC-- namely, changing the TIA's base audio frequency. I haven't tried it yet, but in theory if you strobe RSYNC after X cycles, you should be able to raise the base audio frequency and get a different set of notes. In other words:

 

X = 76 cycles, base audio frequency = 31399.78 Hz

X = 75 cycles, base audio frequency = 31818.44 Hz

X = 74 cycles, base audio frequency = 32248.42 Hz

etc.

 

These are NTSC values; for PAL/SECAM they would be lower. In general, the base audio frequency equals 3579575 Hz (or 3546894 Hz for PAL/SECAM) divided by the number of color clocks per line, then multiply by 2. But in practice it's a little more complicated than that, since the audio clocks are generated twice per scan line at specific points on the scan line, so if you shorten the scan lines you'll get pulse waves that have differing duty cycles. The TIA has two audio clocks-- phase 1 and phase 2-- but the phase 2 audio clock is when changes occur, similar to the way that the phase 2 horizontal clock is when changes occur in drawing the playfield pixels. The phase 2 audio clocks normally occur every 28 or 29 horizontal counts-- or twice every 57 horizontal counts (where 1 horizontal count equals 4 color clocks)-- which is as close to a 50% duty cycle as possible with the TIA (since 57 isn't evenly divisible by 2). So if you shorten the scan lines, the phase 2 audio clocks will occur every 28/28 counts (a perfect 50% duty cycle), or every 28/27 counts, or every 28/26 counts, etc. But I'm not sure if that's right, because RSYNC would be strobed at the CPU rate (multiples of 3 color clocks), whereas the count rate is different, so I guess the last count on each line could correspond to fewer than 4 color clocks. If you strobe RSYNC often enough, you'll end up with only one phase 2 audio clock per line, but each line will be only half as long (or less) as normal, so you'll still get a higher base audio frequency.

 

Anyway, in theory it should be possible to determine which notes will be most in-tune for any given value of X, then create a kernel for a music player that strobes RSYNC every X cycles depending on which note is to be played, such that every note is as close to being in-tune as possible. But this wouldn't help with game music, since strobing RSYNC will presumably ruin the video, so you'd probably want to blank the video-- i.e., this might be useful for playing music without any picture.

 

Obviously, it would be more useful for game-development purposes to use the Harmony's DPC+ music features-- but it might still be interesting to see what could be done with this idea. Note that since the base audio frequency would be the same for both audio channels, this idea would work best for monophonic music, although both channels could be used as long as the notes to be played on each channel were in-tune for the given X.

 

I'll see if I can write a program to test this idea. My plan would be to set AUDC0 and AUDF0 to specific values and leave them there, then let the user increase or decrease the RSYNC rate by moving the joystick, to see how the sound changes as the RSYNC rate changes.

[eshu]

In the video signal for most old Atari gear, the HSync will be XORed with VSync. This automatically generates the inverted signal you need for 3 scanlines around HSync with the short pulses returning to blank/black level and the long ones at sync level.

 

If you could change the control bits fast enough, possibly you could do RSync but not generate a HSync pulse which would reset the counters and in theory make the screen move horizontally. My thinking here is briefly have both HSync and VSync active then disable them both.

 

But the feeling I get is that even if you could hit TIA registers one per cycle it probably wouldn't be enough. Might be worth a try though.

 

 

I'm not sure how well strobing RSYNC night work with video, since it will alter the scan line length and probably scramble the picture-- if not on all TVs, then certainly on some.

 

Sorry I didn't really explain what I was trying to do very well as I wasn't expecting it to even remotely work, however the two CRT results so far make me hopeful, so I'll try to explain.

 

For now ignore everything except HSYNC (i.e. HBLANK and colourburst).

 

Basically the first step is to use RSYNC to knock the scanline counter out of it's correct position, let's say RSYNC ending at cycle 67. Now the current state is that the normal HSYNC pulse should be sent 8 cycles early. What I'm trying to do is mask this pulse with VSYNC and send our own pulse (again with VSYNC) at about the correct time. Once we have done this for a number of scanlines (which should appear offset), we hit RSYNC ending at cycle 7 which should return us to having the normal HSYNC pulse to the correct time.

 

Based on my reading of: http://www.atarihq.com/danb/files/TIA_HW_Notes.txt and the TIA schematics, the start of a normal scanline looks like:

                1111111111222222222233333333334444444444555555555566666666667777777777
      01234567890123456789012345678901234567890123456789012345678901234567890123456789

VSYNC:
Hi
Low   --------------------------------------------------------------------------------

HSYNC:
Hi                        -----------------
Low   --------------------                 -------------------------------------------

CSYNC:
Hi                        -----------------
Low   --------------------                 -------------------------------------------

Where the numbers at the top are the colour clocks. On our special scanlines, which are running 8 cycles (24 colour clocks) early we would have something like:

                1111111111222222222233333333334444444444555555555566666666667777777777
      01234567890123456789012345678901234567890123456789012345678901234567890123456789

VSYNC:
Hi                        -----------------       -----------------
Low   --------------------                 -------                 -------------------

HSYNC:
Hi                        -----------------
Low   --------------------                 -------------------------------------------

CSYNC:
Hi                                                -----------------
Low   --------------------------------------------                 -------------------

That's pretty much how the up kernel is supposed to be working.

 

The left kernel doesn't use RSYNC and simply tries to extend the HSYNC pulse length (I know there is a hardware scroll technique on the Amstrad CPC which involves extending the length of HSYNC), somethiing like this:

                1111111111222222222233333333334444444444555555555566666666667777777777
      01234567890123456789012345678901234567890123456789012345678901234567890123456789

VSYNC:
Hi                                         --------
Low   -------------------------------------        -----------------------------------

HSYNC:
Hi                        -----------------
Low   --------------------                 -------------------------------------------

CSYNC:
Hi                        -------------------------
Low   --------------------                         -----------------------------------

The right kernel is similar to the up kernel but uses a long stretch of VSYNC to both disable the normal HSYNC and create a new one.

                1111111111222222222233333333334444444444555555555566666666667777777777
      01234567890123456789012345678901234567890123456789012345678901234567890123456789

VSYNC:
Hi                        ---------------------------------
Low   --------------------                                 ---------------------------

HSYNC:
Hi                        -----------------
Low   --------------------                 -------------------------------------------

CSYNC:
Hi                                         ----------------
Low   -------------------------------------                ---------------------------

Now really I fiddled with some of the numbers etc.. until I got something stable on my TV, the timing is extremely confusing between the different clocks (The HSYNC counter runs of a 4 colour clock counter) and the various delays. Also with the processor clock only running at 3 colour clocks I may not be masking the original pulse entirely, it lasts for 16 colour clocks and we can only do a seperation of 15 with the processor, but like I said there are various delays and synchronisations going on.

 

How close to doing anything like that the above, these kernels are I don't really know - I don't suppose anyone has an appropriate oscilloscope?

 

Edit: Edited for typos and clarity

Edited April 26, 2014 by eshu

[eshu]

Ok, so I went back through everything and tried to make sense of the results, and I think I had the HSYNC length wrong - the hardware notes I mentioned above have the end of HSYNC delayed by 4 clocks and not the start, but that's not what the schematics looked like to me - but I don't really understand them, I think the notes are right, it would make sense of the results - attached is another binary that produces 4 stable images on my TV all at different offsets:

 

UP = real HSYNC 8 cycles early = playfield shifted 24 pixels left

DOWN = real HSYNC 9 cycles early = playfield shifted 27 pixels left

LEFT = real HSYNC 10 cycles early = playfield shifted 30 pixels left

RIGHT = real HSYNC 11 cycles early = playfield shifted 33 pixels left

 

The colours are mangled because of colourburst, but I'm not trying to fix that yet (I think there should be a way to fix it)

 

Could people let me know if these are stable on their VCS/TV and if they appear to be shifted by the amounts mentioned above?

 

synctest2.bin

Edited April 27, 2014 by eshu

[SeaGtGruff]

Ok, so I went back through everything and tried to make sense of the results, and I think I had the HSYNC length wrong - the hardware notes I mentioned above have the end of HSYNC delayed by 4 clocks and not the start, but that's not what the schematics looked like to me - but I don't really understand them,

 

The following is taken from a spreadsheet I made to simulate part of the TIA's processing. The HSC (horizontal sync counter) bits are shown in reverse order (i.e., low-to-high) so they're in the same order shown on the schematic. I'm starting with HSC 101001, which is the next-to-last value before the HSC resets itself.

 

HSC = 101001 | END = 0 | SHB = o | RHB = 0 | /HB = 1 | BLANK = 0 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 010100 | END = 1 | SHB = o | RHB = 0 | /HB = 1 | BLANK = 0 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 000000 | END = 0 | SHB = 1 | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 100000 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 110000 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 111000 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 111100 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 1 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 111110 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 1 | SYN = 0 | RCB = 0 | CB = 0

HSC = 011111 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 1 | SYN = 0 | RCB = 0 | CB = 0

HSC = 101111 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 1 | SYN = 0 | RCB = 0 | CB = 0

HSC = 110111 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 1 | HS = 1 | SYN = 0 | RCB = 0 | CB = 0

HSC = 111011 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 1

HSC = 111101 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 1

HSC = 011110 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 1

HSC = 001111 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 1 | CB = 1

HSC = 100111 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 110011 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 111001 | END = 0 | SHB = o | RHB = 0 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 011100 | END = 0 | SHB = o | RHB = 1 | /HB = 0 | BLANK = 1 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

HSC = 101110 | END = 0 | SHB = o | RHB = 0 | /HB = 1 | BLANK = 0 | SHS = 0 | RHS = 0 | HS = 0 | SYN = o | RCB = 0 | CB = 0

etc.

 

I didn't include the LRHB signal above, since you're interested in a "normal HBLANKing" line, but it would occur on the next horizontal count.

 

Note that the BLANK signal is actually delayed by half of a color clock so that it changes from low to high, or vice versa, when the pixel clock (CLKP) goes from low to high.

 

I've used "o" for "off," because-- if I've understood the schematic correctly (which might not be the case)-- the SHB and SYN signals are either "off" or otherwise. In the case of the SHB signal, when it isn't "off" it's high, so you can think of SHB as being 0 wherever I've shown it as "off." But in the case of the SYN signal, when it isn't "off" it's low, so I guess that means you can think of SYN as being 1 wherever I've shown it as "off." I admit that that portion of the schematic is a bit of a mystery to me, because I'm not sure how to interpret it.

 

I didn't include the /VB signal above.

 

To summarize:

 

BLANK is high for 17 counts (68 clocks), but its transitions are delayed by half a clock so they're in sync with the pixel clock (the high-low periods of CLK and CLKP are inverted from each other).

 

SYN is low (active) for 4 counts (16 clocks), beginning about 5 counts (19.5 clocks) after BLANK goes high.

 

CB is high for 4 counts (16 clocks), beginning as soon as SYN is turned off.

 

BLANK remains high for about 4 counts (16.5 clocks) after CB is turned off.

 

But I can't swear that the above is 100% accurate, since my spreadsheet doesn't simulate any propagation delays.

[Mr SQL]

Very cool eshu!

 

I tried it on a JVC NTSC set which is right on the spec (it will roll if the scanline count varies by 1). The image was stable on all three settings. Up produced shimmering colours that changed, left shifted the image and changed the intensities.