Jump to content
IGNORED

Smooth scrolling playfield - I think I've done it :)


Recommended Posts

Looks like the consoles are different there.

 

BTW: I can create a video too, if you want me to. Just tell me which ROM I should test.

 

It would be quite handy to see the new sync test if you could? Thanks

 

I would think the HSync length would be directly proportional to the clock speed.

 

PAL master clock = 3.546894 MHz, so CPU would be 1.182298 MHz vs 1.1931816 Mhz (NTSC)

From Wikipedia:

The format of the horizontal sync pulse varies. In the 525-line NTSC system it is a 4.85 µs-long pulse at 0 V. In the 625-line PAL system the pulse is 4.7 µs synchronization pulse at 0 V . This is lower than the amplitude of any video signal (blacker than black) so it can be detected by the level-sensitive "sync stripper" circuit of the receiver.

 

So the PAL sync pulse should be shorter, but if they run for the same number of cycles I think it would be longer because of the clock speed?

 

Ed - If it's ok, I'd like to another sync test binary that I know won't work on my system but based on your video might have the desired results.... I'm away from my computer for a little while now....

So here is an alternative version of the sync test - Ed, can you let me know if this runs any better, and can a nyone else let me know how the first one - "newsynctest.bin" looks. There should only be very minimle bend like the down kernel in Ed's video, if the others bend a lot - like in the video maybe try this version and let me know....

 

 

newsynctest_alt.bin

Every chance the HSync signals don't match spec anyway. VSync on Atari is very different to the specification and still works.

I'd say so long as the signal isn't too short it'll work. A bit too long... the receiver shouldn't care.

For reasons I don't fully understand the RMW instructions on the 6502 read a value, write it back again on the next cycle (while modifying it), and then write the modified value.

 

It's writing the _just read value_ back, while internally modifing it, and _then_ writes back the new value. From what I know, on each cycle the CPU must do a read or write, but on the modify step of RMW, which needs one cycle just to run internally, re-reading the same value from memory would destroy the internal state, so a dummy write was done.

 

At least that's how I remember the explanation of one of the back-then-developers of VICE. ;-) Afaik it's used on purpose with the C64's io-chips in some corner cases.

That above test is really scrolling the playfield horizontally 1 pixel at a time.

Can't be done... until now!

Congratulations on your historic achievement.

On cinco de tres, VCS smooth scrolls playfield pixels.

Cool. That looks the real deal there.

 

My suggestion - get it tested on as many devices as possible, ie 2600 types, various CRT and LCD TVs, PVRs, VCRs, video capture cards etc.

If it works without trouble on at least 90% of them then you could probably say it's something "production worthy".

Frame advance the video... using a camera to record from TV isn't a reliable way to guage smoothness. There's frames in the video which seem to blend 2 adjacent TV frames, with the blurry after-effect of the previous scroll value.

Frame advance the video... using a camera to record from TV isn't a reliable way to guage smoothness. There's frames in the video which seem to blend 2 adjacent TV frames, with the blurry after-effect of the previous scroll value.

Then its easier to frame advance the demo. :)

This is awesomely clever. Well done.

Is it possible to "reset" things so that the TIA is behaving normally after the scrolling area? What are the limitations; e.g., must the scroll area be the top of screen? Can sprites appear over the scroll area correctly? Can a static non-scroll area appear after the scroll area?

Thanks

A

You have to set this line by line. Afterwards the display returns to normal. So you can do this everywhere on the screen.

 

Not sure about the sprites, but I suppose they display correctly. Movement might become interesting.

Based on my RSYNC/VSYNC experiments I think I've managed to get a smooth scrolling playfield - works fine on my VCS and TV, could people try it out and let me know if it works?

 

A simple test binary is attached...

 

Cool, someone rediscovered this effect. I always remembered that 1 pixel horizontal playfield movement was discovered by someone on [stella] more than a decade ago, but whenever I was searching for the particular postings in later years I couldn't find it.

You are a genius! Great work so far. ;-)

 

...it's not perfect yet, however. :-D On my PAL Jr. and a Grundig CRT, the scrolling is a bit jerky. It looks like it does scroll a little bit every step (opposed to skipping one step, then scrolling two pixels), but somehow it looks like the scrolling distance is a bit different each time and not exactly one pixel. I hope that makes sense somehow; it's hard to describe.

 

What's also very weird is that step (kernel?) #2 sometimes fails to display the number correctly. Most of the time it works, but maybe one out of ten times, the "2" and the first square below it gets distorted, like the object is displayed some pixels to the left and then shifted one pixel to the right each scanline until it has reached its correct position, showing the rest of the object scanlines normally. That doesn't happen for the other kernels, and for kernel #2 only sporadically, with no discernible pattern.

 

If needed, I could try to make a video of this. What would help testing though would be a version where we can manually trigger the next kernel, e.g. by pressing a button or so. Right now, even with the slow scrolling speed, it's a bit hard to see on my TV set how far each kernel scrolls exactly, or how the distorted number for kernel #2 looks like. Being able to manually advance the scrolling by one pixel would be nice.

Edited by Kylearan

Using a macro, I've done several tests with different timings for RSYNC and the delay afterwards. But I only got shift of +/- 0, 1, 3, 4 or more. Not 2.

 

Also i noticed that the shift sometimes takes some lines before it reaches the final position and sometimes not. Same after the shift is over.

Thanks for all the compliments, please bare in mind this is very much a work in progress, and I'm happy for any help I can get. The TV I'm working with is very unsuitable for the job, it assumes the signal is interlaced for a start and I'm much more concerned with getting this working on CRTs than anything else.

 

 

This is awesomely clever. Well done.

Is it possible to "reset" things so that the TIA is behaving normally after the scrolling area? What are the limitations; e.g., must the scroll area be the top of screen? Can sprites appear over the scroll area correctly? Can a static non-scroll area appear after the scroll area?

Thanks

A

 

At the moment I'm entering shifted scanlines a couple of lines into the visible display and exiting just before overscan, this is more visible in the synctest/newsynctest binaries - from my current understanding there is a tiny bit of distortion around the points where you enter/exit - maybe one/ max 2 scanlines that might not be dead on, apart from that I think you can switch in and out of normal display as you please, at least that's the aim. It seems from Ed's videos that the colour signal, which is partly controlled by colourburst stays fine with these small shifts on NTSC. The colourburst on PAL (incidently SECAM doesn't have a colourburst, so should be fine) is a more complicated beast and it looks like this gets knocked out of phase. This does mean the technique can be used to get otherwise unachievable colours on PAL systems, but that this would have to be compensated for in any scrolling routine.

 

From: http://en.wikipedia.org/wiki/Colorburst

 

In NTSC, its frequency is exactly 315/88 = 3.57954[a] MHz with a phase of 180°, whereas PAL uses a frequency of exactly 4.43361875 MHz, with its phase alternating between 135° and 225° from line to line. SECAM is unique in not having a colorburst signal, since the chrominance signals are encoded using FM rather than QAM, thus the signal phase is immaterial and no reference point is needed.

 

I think player graphics etc.. should display fine. Although you can see there seems to be an intermitent issue in one of the kernels, Kylearan mentions it below. The one gotcha is with positioning, because the use of RSYNC means HBLANK is unusually long in the scanlines we're entering/exiting I think the player/missile motion counters don't get all their clocks. This could be compenstated for by spamming RSYNC the right amount of times out of the visual display, but it's probably just easier to reposition every frame.

 

 

Cool, someone rediscovered this effect. I always remembered that 1 pixel horizontal playfield movement was discovered by someone on [stella] more than a decade ago, but whenever I was searching for the particular postings in later years I couldn't find it.

 

I stand to be corrected but I don't think anyone has used RSYNC combined with VSYNC before, I've definitely read some stuff about RSYNC on the list before that I can no longer find. "site:www.biglist.com/lists/stella/ rsync" in google only seems to turn up a lot of stuff about the interlacing experiments, but I'm sure I remember reading some stuff more like the topic Andrew linked to earlier in this thread.

 

You are a genius! Great work so far. ;-)

 

...it's not perfect yet, however. :-D On my PAL Jr. and a Grundig CRT, the scrolling is a bit jerky. It looks like it does scroll a little bit every step (opposed to skipping one step, then scrolling two pixels), but somehow it looks like the scrolling distance is a bit different each time and not exactly one pixel. I hope that makes sense somehow; it's hard to describe.

 

What's also very weird is that step (kernel?) #2 sometimes fails to display the number correctly. Most of the time it works, but maybe one out of ten times, the "2" and the first square below it gets distorted, like the object is displayed some pixels to the left and then shifted one pixel to the right each scanline until it has reached its correct position, showing the rest of the object scanlines normally. That doesn't happen for the other kernels, and for kernel #2 only sporadically, with no discernible pattern.

 

If needed, I could try to make a video of this. What would help testing though would be a version where we can manually trigger the next kernel, e.g. by pressing a button or so. Right now, even with the slow scrolling speed, it's a bit hard to see on my TV set how far each kernel scrolls exactly, or how the distorted number for kernel #2 looks like. Being able to manually advance the scrolling by one pixel would be nice.

 

This fits with what I'm seeing on Ed's video. I think this may be because of some subpixel scrolling going on. It looks to me like between steps 1 & 2 it is scrolling about 1/2 a 2600 pixel/colourclock and between 2 & 3 about 1 1/2 pixel. This could be because of a horizontal sync pulse which is about 3 clocks/pixels longer or shorter than standard.

 

From: http://www.cpcwiki.eu/index.php/Programming:Hardware_scrolling

 

Fine horizontal hardware scrolling is much more difficult to achieve. It is based on the way the monitor handles the width of the horizontal sync signal (CRTC register 3) coming from the CRTC (which gets modified by the Gate Array). Basically, by reducing the width of the horizontal sync period by one (MODE 1) character, the screen will shift by half a (MODE 1) character. This allows single MODE 1 character scrolling. The exact timing of the HSYNC change is important, and will cause the monitor to bend the display slightly for a number of pixel rows (scan lines).

 

I will try and work up a test binary with more options, hopefully tomorrow. e.g. It should let you control the speed of scrolling and also manually scroll forward or backward in 1 "pixel" increments. I'm a bit confused by the "2" graphics at the moment, but that shows up in Ed's video to.

 

Using a macro, I've done several tests with different timings for RSYNC and the delay afterwards. But I only got shift of +/- 0, 1, 3, 4 or more. Not 2.

 

Also i noticed that the shift sometimes takes some lines before it reaches the final position and sometimes not. Same after the shift is over.

 

So I think the "best" setups are ones where the shift takes as few lines as possible, otherwise you're likely to see differences between monitors. I would be interested to see what RSYNCs/delays are working for you. Here are the ones I'm using in the test binary which is working the best so far on Ed's setup, I assume that is also the binary Kylearan was using above?

 

Kernel 1:

			sta WSYNC
			sleep 73
			sta RSYNC			;	76/75
			ror $0300			;	3...
							;	4	-	03->VSYNC
							;	5	-	01->VSYNC

			ror $0300			;	9...
							;	10	-	03->VSYNC
							;	11	-	01->VSYNC

                        ....

                        Then ror $0300, ror $0300 at cycles 0-11 on every scanline...

                        ....

                        Then exiting with:

                        sleep xxx  			;	71
			sta RSYNC			;	74/75


Kernel 2:

			lda #0
			ldx #%00000010
			sta WSYNC
			sleep 74
			sta RSYNC			;	77/75
			ror $02fe,x			;	4...
							;	5	-	03->VSYNC
							;	6	-	01->VSYNC

			stx VSYNC			;	9
			sta VSYNC			;	12

                        ...
                        Then ror $0300, stx VSYNC, sta VSYNC at cycles 1-12 on every scanline
                        ...

                        Exiting with:

                        sleep xxx                       ;       70
                        sta RSYNC                       ;       73/75

Kernel 3:

			sta WSYNC
			sleep 71
			sta RSYNC		        ;	74/75
			sleep 3                         ;       2
 			ror $0300			;	6...
							;	7	-	03->VSYNC
							;	8	-	01->VSYNC

			ror $0300			;	12...
							;	13	-	03->VSYNC
							;	14	-	01->VSYNC

                        ...
                        Then ror $0300, ror $0300 at cycles 3-14 on every scanline
                        ...

                        Exiting with:
                        
                        sleep xxx                       ;       73
                        sta RSYNC                       ;       76/75
Edited by eshu

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...