eshu Posted May 1, 2014 Author Share Posted May 1, 2014 Ok - everyones in bed, and I'm back on the real hardware - the timings are screwed on the last couple of binaries - attached is a correct framecount one.... scrolltest3.bin Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 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 Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 Crazy idea - maybe it's scrolling 1&1/3 pixels and I just need to drop a frame?? Quote Link to comment Share on other sites More sharing options...
Ed Fries Posted May 2, 2014 Share Posted May 2, 2014 Hi Eshu, Here's a video of scrolltest4 on my crt. scroll4.MOV Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2014 Share Posted May 2, 2014 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: find out about the console differences find a way to detect those different consoles 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted May 2, 2014 Share Posted May 2, 2014 Fascinating I might need to rewrite post #27 in this thread... http://atariage.com/forums/topic/27595-session-13-playfield-basics/page-2 Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 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.... Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 2, 2014 Share Posted May 2, 2014 "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. Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 (edited) yep - thats what i call seperated by one cycle.....I'm pretty sure these no way to store-waste a cycle-store, also I called RMW RWM above....oops... Edited May 2, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 2, 2014 Share Posted May 2, 2014 (edited) 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 May 2, 2014 by Rybags Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2014 Share Posted May 2, 2014 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. Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 (edited) 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 May 2, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2014 Share Posted May 2, 2014 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? Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 (edited) 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 May 2, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 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 Quote Link to comment Share on other sites More sharing options...
LS_Dracon Posted May 2, 2014 Share Posted May 2, 2014 Have you tried to set HMOVE bars to hide the color line at most left? Wondering to know if it affect HMOVE bars too... Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 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.... Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2014 Share Posted May 2, 2014 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 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2014 Share Posted May 2, 2014 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). Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2014 Share Posted May 2, 2014 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. Quote Link to comment Share on other sites More sharing options...
Ed Fries Posted May 2, 2014 Share Posted May 2, 2014 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 Quote Link to comment Share on other sites More sharing options...
eshu Posted May 2, 2014 Author Share Posted May 2, 2014 (edited) 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 May 2, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 2, 2014 Share Posted May 2, 2014 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. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.