Jump to content
IGNORED

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


Recommended Posts

Here is the file I'm working with at the moment - The digit and pattern would stay still if everything was perfect, but I doubt that's possible - I've attached a .mov of how it looks here - you can see a slight subpixel drift on my setup - hopefully this should help to identify whats going on....

 

scrolltest.mov

scrolltest4.bin

It's time for me to go to bed, and it's probably just wishful thinking, but somewhere in my addled brain 1 & 1/3 pixel scrolling makes sense - so here's a nother test with the kernel 2 removed, which is the one your TV doesn't seem to like - let me know how it looks....

 

 

scrolltest5slow.bin

scrolltest5fast.bin

scrolltest5medium.bin

I will look after it tonight, but from my experience I doubt it will look good. Especially on slower scrolling speeds, where the new trick would be really beneficial.

 

So IMO we should try to:

  1. find out about the console differences
  2. find a way to detect those different consoles
  3. if possible, define working kernels for all types of consoles

We already have similar problems with the Cosmic Ark stars effect. Since this is used in Boulder Dash, I had developed a simple check (based on collisions), so that all consoles of Andrew and me are supported. So this check is far from complete, but a start.

So I think Kernels 0 (obviously),1 and 3 seem to be working ok - the quirks I mentioned before are using read-write-modify instructions to do two consecutive stores to VSYNC and using the floating data bus with a mirror of VSYNC to control the value stored.

 

Kernel 1 starts with:

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

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

Kernel 3 starts with:

			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

The aim of Kernel 1 is do nobble the HSYNC into occuring 3 colour clocks early, and the aim of Kernel 3 is to make it occur 3 clocks late. Unfortunately afaik there is no way to store to the same address seperated by two cycles, so Kernel 2 was a bit of a kludge using sta and stx for 3 cycle sepearation, I think I will try for a 6 cycle = 18 clock shift see if I can get that working consistently. It will mean losing more pixels, but it might be the next best option that works....

"Store to same address seperated by 2 cycles" - if it's z-page then it's easy.

 

In some instances (not necessarily 2600), RMW instructions can be useful since they do successive stores (original value then modified by shift, increment, whatever) - although no easy means of changing the seperation.

LSR $40 - read instruction, read operand, read contents, writeback contents, writeback result. 2 writes back to back.

 

STA $40 / STA $40 - 2 writes with 2 cycles in between.

 

STA $40 / STA $0040 (nzp mode on 2nd STA) - 2 writes, 3 cycles in between.

 

STA $40 / STA $40,X (X=00) - 2 writes, 3 cycles in between.

 

Hmmm... looks like you're right. Does TIA have a Page 1 mirror? Maybe some fancy stack manipulation could pull it off?

 

Store, followed by BRK instruction maybe, with the right PC value on entry.

Edited by Rybags

At the very least I think we can scroll 2 pixels at a time by alternating 1 and 3 - attached is a binary which does that, with one which doesn't at the same speed for comparison....please tell me this one at least works?? :?

 

Would be nice to nail the other offset to though....I'll keep trying....

 

 

smoothscroll_2px.bin

notsmoothscroll.bin

The aim of Kernel 1 is do nobble the HSYNC into occuring 3 colour clocks early, and the aim of Kernel 3 is to make it occur 3 clocks late. Unfortunately afaik there is no way to store to the same address seperated by two cycles, so Kernel 2 was a bit of a kludge using sta and stx for 3 cycle sepearation.

How are the code and the first sentence related to the 2nd sentence? I am lost and I wish I would understand what you are doing here. :)

So the important thing is that HSYNC and VSYNC are xored (/xnored) to create CSYNC which is what is actually output, so if we can set VSYNC on for the first three clocks of HSYNC then off again, it should disable the HSYNC for those clocks. If we also turn VSYNC on for the three clocks after HSYNC and then off again - we've essentially shifted the HSYNC forward by 3 clocks. It's all a bit trial and error as HSYNC like the playfield runs off a divided by four clock so things don't line up perfectly.

 

Kernel 1 adds about 3 extra clocks of sync at the start of HSYNC and removes about the same at the end.

Kernel 3 removes about 3 clocks from the start of HSYNC and adds about the same at the end.

 

If we could set VSYNC for 2 cycles = 6 clocks we could probably adapt one of these kernels to shift by 3 more clocks, but I don't think theres an instruction which can do that.

 

Edit: I also probably didn't make it clear that those ROR instructions are running on every shifted scanline, we need to shift the HSYNC for the whole time we are out of phase with the real one....

Edited by eshu

Let's see if I get you:

 

Kernel 1 writes 3 @ cycle 5 and 1 @ cycle 6 to VSYNC. (BTW: does it really address it twice?) So that's just 1 cycle in between, right? And if you can gap this by another cycle (= 2 cycles), you hope to increase the shift?

So if we could set VSYNC (i.e. write say 3 to it) at cycle 5, and then disable it at cycle 7 (i.e. write 1 to it) and then also set it at cycle 11 and disable it at 13 we would have a fake HSYNC running from about cycle 7 to 13, where kernel 1 has a fake HSYNC running from about cycle 6 to 12

 

And yes it really does write to it twice, you could get some other interesting effects with the same method for instance writing to COLUBK. Cycle timings, details of Read-Modify-Write instructions are from:

 

http://nesdev.com/6502_cpu.txt

 

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. By using an appropriate mirror of the TIA registers we can control the values by selecting the high byte of the address, since this will have been the last thing on the data bus before it attempts to read VSYNC which is floated.....

Edited by eshu

Ok - sorry for all the posts and binaries, but I really can't suss this out without people trying stuff on their machines - here is a new sync test file....

 

Up, Down, and Left are the kernels I used in the previous attempt at a scroller:

 

Up - +3 pix right

Down - -3 pix left

Left - + 6 pix right (This is the one that doesn't seem to be working on other setups)

 

Right is an alternate version of +6, to be honest it looks worse on my TV (it seems to be significantly brighter than the others) - but it still synchronizes - could people try these out and let me know how they look?

 

 

 

 

newsynctest.bin

Have you tried to set HMOVE bars to hide the color line at most left? Wondering to know if it affect HMOVE bars too...

 

At a guess it might be the edge of the coulourburst which I don't think can be covered with VBLANK or HBLANK (which is extended by HMOVE).......will worry about this kind of stuff if I can get the actual scrolling working....

Up, Down, and Left are the kernels I used in the previous attempt at a scroller:

 

Up - +3 pix right

Down - -3 pix left

Left - + 6 pix right (This is the one that doesn't seem to be working on other setups)

 

Right is an alternate version of +6, to be honest it looks worse on my TV (it seems to be significantly brighter than the others) - but it still synchronizes - could people try these out and let me know how they look?

Up: + ~4 pixel right

Down: - ~4 pixel left

Left: +~6 pix right

Right: same as Left, absolutely no difference, even the colors are identical

At the very least I think we can scroll 2 pixels at a time by alternating 1 and 3 - attached is a binary which does that, with one which doesn't at the same speed for comparison....please tell me this one at least works?? :?

 

Would be nice to nail the other offset to though....I'll keep trying....

This works ( the smooth version).

It's time for me to go to bed, and it's probably just wishful thinking, but somewhere in my addled brain 1 & 1/3 pixel scrolling makes sense - so here's a nother test with the kernel 2 removed, which is the one your TV doesn't seem to like - let me know how it looks...

Fast looks OK, medium is already jerky. Slow looks like it is even moving backwards half a pixel (or less) in kernel 3.

Hi Eshu,

 

Attached are videos of scrolltest5slow and newsynctest.

 

On my CRT scrolltest5slow looks good but without stage 2 the scrolling speed is uneven.

 

On newsynctest I'm not sure what I'm supposed to be seeing so I'll leave it up to you to interpret. The dark bar across the screen is an artifact of the iphone video and doesn't actually appear on the screen.

 

BTW on early versions of Rally I was INC and DECing VSYNC and it doesn't work on every atari model out there (apparently, 7800 for example). So you might end up having the same problem with your rolls of vsync.

newsynctest.MOV

scrolltest5slow.MOV

Thanks Ed - that should be useful - it looks like down is the only one working as it's supposed to :(

 

Edit: Hmmm I wonder if PAL and NTSC 2600's have different HSYNC lengths, the standards define different lengths but I just assumed it would be the same for both....does anyone know if there are PAL TIA schematics available?

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...