Omegamatrix Posted May 5, 2014 Share Posted May 5, 2014 Eshu, I'm sure you're aware of it, but when you are ROR $0300 you are reading the undefined bits of CXM0P and writing that back to VSYNC. I'm guessing their value is most likely the last value on the bus. This would be why you are using $0300 as last value on the bus is the high address --> 0x03 for the ROR. The issue is this might be unreliable though. It could vary depending even on whether it is a little warmer or cooler during tests... who knows? Read-Modify-Write instructions (ASL, LSR, ROL, ROR, INC, DEC, SLO, SRE, RLA, RRA, ISB, DCP) # address R/W description --- ------- --- ------------------------------------------ 1 PC R fetch opcode, increment PC 2 PC R fetch low byte of address, increment PC 3 PC R fetch high byte of address, increment PC 4 address R read from effective address 5 address W write the value back to effective address, [write $03, enable VSYNC] and do the operation on it 6 address W write the new value to effective address [write $01, disable VSYNC] Quote Link to comment Share on other sites More sharing options...
eshu Posted May 5, 2014 Author Share Posted May 5, 2014 Eshu, I'm sure you're aware of it, but when you are ROR $0300 you are reading the undefined bits of CXM0P and writing that back to VSYNC. I'm guessing their value is most likely the last value on the bus. This would be why you are using $0300 as last value on the bus is the high address --> 0x03 for the ROR. The issue is this might be unreliable though. It could vary depending even on whether it is a little warmer or cooler during tests... who knows? Read-Modify-Write instructions (ASL, LSR, ROL, ROR, INC, DEC, SLO, SRE, RLA, RRA, ISB, DCP) # address R/W description --- ------- --- ------------------------------------------ 1 PC R fetch opcode, increment PC 2 PC R fetch low byte of address, increment PC 3 PC R fetch high byte of address, increment PC 4 address R read from effective address 5 address W write the value back to effective address, [write $03, enable VSYNC] and do the operation on it 6 address W write the new value to effective address [write $01, disable VSYNC] I hadn't actually noticed it was CXM0P - but basically yes, Ed mentioned he had been using inc VSYNC in a binary and it wasn't working on some 7800's. It (ror $0300) seems to work consistently on my machine, I thought their were some commercial roms out there with the common mistake lda $xx instead of lda #$xx that work consistently. From what I've read it also sounds like it's dependent on how the cartridge treats the bus...I'm really not too good at hardware, so I may have that wrong.... Obviously it would be preferable to avoid it, but I don't think you can get these small shifts in the HSYNC without modifying the value in consecutive cycles. Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted May 5, 2014 Share Posted May 5, 2014 I forgot to say, but of course the the value might not be $03 to begin with. The used bits for CXM0P will also be there. The important bits for this though are bits 2 and 1 of the initial read. %XX00 0011 set VSYNC to %XXX0 0001 clear VSYNC Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 5, 2014 Share Posted May 5, 2014 (edited) Is bit 0 required for something? I suppose writing 2/0 would do too. Edited May 5, 2014 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted May 5, 2014 Share Posted May 5, 2014 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. I've been trying to find the original message every once in a while for years, but as you can see here I already failed in 2006 to unearth it (bottom third / second page): http://atariage.com/forums/topic/83289-the-hmove-artifacts/page-2?hl=%2Brsync+%2Bplayfield&do=findComment&comment=1051554 As far as I remember it probably had to do indeed with either interlacing or the Meltdown prototype, where someone described an effect like the playfield was shifting for one pixel during his experiments, albeit at the time I was too busy with other things and then never found that particular message again. So all those years I knew that something like that was possible here, I just had no idea how So I'm incredibly happy that you found that effect again, proofing that I wasn't just dreaming it Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 5, 2014 Share Posted May 5, 2014 (edited) Bingo! Found working +2 pixel shifts. Very simple ones: sta WSYNC SLEEP 72 sta RSYNC ror $0300 ; or ror $0300,x It takes takes ~4-6 lines to the final position. Other SLEEP values work too, but they don't shift smoothly from the normal position. A SLEEP 2 before ror $0300 smoothly shifts by +1 pixel. SLEEP 3 (and above) smoothly shifts by -2 pixel. Edited May 5, 2014 by Thomas Jentzsch 2 Quote Link to comment Share on other sites More sharing options...
eshu Posted May 5, 2014 Author Share Posted May 5, 2014 (edited) Bingo! Found working +2 pixel shifts. Very simple ones: sta WSYNC SLEEP 72 sta RSYNC ror $0300 ; or ror $0300,x It takes takes ~4-6 lines to the final position. Other SLEEP values work too, but they don't shift smoothly from the normal position. A SLEEP 2 before ror $0300 smoothly shifts by +1 pixel. SLEEP 3 (and above) smoothly shifts by -2 pixel. Obviously you should hopefully be able place the scanlines while it's not in final position in VBLANK, so if it's consistent that shouldn't matter. Have you tried without the RSYNC, i.e. SLEEP 75, ror $0300 (or ror $0200 as you were correct earlier, for some reason I wasn't sure $0200 was a valid mirror. but it is). In theory RSYNC at 75 shouldn't do much, but it might do a one pixel shift because of the difference between the /4 and /3 clocks. The fewer cycles taken the better so this would be preferable to the double rors I was using. So you have +1,+2 and -2 do you have +3/-1 by another method as that would complete the scroll. Using a single ror is likely extending or shortening the sync pulse, so I would be weary of half pixels, but then that opens the question of if you can get a super smooth scroll of 8 half pixels - I think this will all take a lot of testing..... Edit: also if you can get these tiny shifts working it will mean less wasted pixels - I.E. you'll only lose three pixels at the edges which won't be displayed in all kernels.... Edited May 5, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 5, 2014 Share Posted May 5, 2014 (edited) I will do those experiments tomorrow. For now, my 1st, very simple test program. With the right difficulty, you can switch between fast and slow bar scrolling. I am not 100% sure why, but it still looks a bit jerky. If you look at slow scroll mode, it seems like it takes 1 or 2 frames until the new scroll position is stable. EDIT: I just tested with orange colored bars. The color changes to green in the 3 shifted positions. And the two jerky frames happens on the two color switches. Hm... Maybe I can avoid that by using a 4 pixel instead of a 0 pixel shift. That's on my setup. How does it look for other people? JTZ_SyncTest_1.bin Edited May 5, 2014 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
eshu Posted May 5, 2014 Author Share Posted May 5, 2014 (edited) I am not 100% sure why, but it still looks a bit jerky. If you look at slow scroll mode, it seems like it takes 1 or 2 frames until the new scroll position is stable. I think this may be an issue with the kernels which take a few scanlines to stabalise, you may be altering the signal too much from the standard or from the one used by the previous frames so the TV gets a bit confused before it latches on to the new signal... EDIT: I just tested with orange colored bars. The color changes to green in the 3 shifted positions. And the two jerky frames happens on the two color switches. Hm... Maybe I can avoid that by using a 4 pixel instead of a 0 pixel shift. I think this will be issues with the PAL colourburst - I don't think people will see this on NTSC machines...maybe a 4 pixel shift will fix it if it's the same colour with all the other shifts - I'll run this on my setup later, but it's not very good for testing... Edit: I mentioned it before but an oscilloscope would be really handy to see what signal is actually being sent - see Edited May 5, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 5, 2014 Share Posted May 5, 2014 Yes, an oscilloscope would be nice. But with some experiments, we should be able to do without it. Regarding my 4 pixel shift, it turned out that all shifts I thought to be +/-4 pixel were actually only +/-3 pixel. So I have to try other variations tomorrow. Bedtime now. Quote Link to comment Share on other sites More sharing options...
eshu Posted May 6, 2014 Author Share Posted May 6, 2014 (edited) Some of those kernels seem very unstable on my setup - but bare in mind the binaries I''m posting recently don't actually work on it, so I don't know that that means much.... I've updated my scrolltest as requested. Left difficulty selects manual or automatic control On manual (Left difficulty A) - pressing the fire button (debounced) should advance one frame On automatic (Left difficulty B) - the right difficulty selects slow (A) or fast (B). I'll probably wait a while now to see how Thomas' tests work on other peoples machines before trying anything more.... scrolltest2_alt.bin Edited May 6, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
eshu Posted May 6, 2014 Author Share Posted May 6, 2014 I think I found a bug that would be causing the issue with the 2 digit - fixed binary attached... scrolltest2_alt.bin Quote Link to comment Share on other sites More sharing options...
iesposta Posted May 6, 2014 Share Posted May 6, 2014 I think I found a bug that would be causing the issue with the 2 digit - fixed binary attached... Tried on 7800 S-Video w/CRT and Heavy Sixer RF w/CRT. On the 7800, effect doesn't work. Heavy Sixer works. #2 seems the most extreme. Slight "wiggle" in each scan line left & right. Hard to describe. Also left (practically invisible) blue burst at left is farthest right, and bottom 3 inches of screen (also practically invisible) is a shade lighter. The number 2 is also not skewed in this last test, so you fixed that. Hope this info helps. Quote Link to comment Share on other sites More sharing options...
eshu Posted May 6, 2014 Author Share Posted May 6, 2014 Tried on 7800 S-Video w/CRT and Heavy Sixer RF w/CRT. On the 7800, effect doesn't work. Heavy Sixer works. #2 seems the most extreme. Slight "wiggle" in each scan line left & right. Hard to describe. Also left (practically invisible) blue burst at left is farthest right, and bottom 3 inches of screen (also practically invisible) is a shade lighter. The number 2 is also not skewed in this last test, so you fixed that. Hope this info helps. All testing helps - thank you. With the 7800 is difficult to know if it could be an issue with the ror $0300 instruction, or the video mod. For the time being I'll probably ignore any video mods as it just adds another variable. It seems like there are still issues with the #2 kernel.Have you tried Thomas' binary? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 6, 2014 Share Posted May 6, 2014 (edited) Another version from me. Not jerky scrolling anymore, but one frame is slightly brighter than the other 3. JTZ_SyncTest_2.bin Edited May 6, 2014 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
eshu Posted May 6, 2014 Author Share Posted May 6, 2014 Have just had a quick look with stella's debugger - will try on real hardware later - theres some odd (to me at least) stuff in there I notice in one of the kernels you're rsyncing on every line - and another has three ror's in a row - from a theoretical point of view that doesn't make much sense, but if it works it works I take it you've tried the three ror one without the middle ror? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted May 6, 2014 Share Posted May 6, 2014 Not yet. Will do tomorrow. I suppose it is still a long way to make this work on every console. I am not even sure if it is only the console. Or if it depends on the TV too. Quote Link to comment Share on other sites More sharing options...
eshu Posted May 6, 2014 Author Share Posted May 6, 2014 Actually the middle ror wouldn't make much sense - I would try removing the first or last one, but I'm pretty sure you would have tried the equivilant in your testing anyway - I'm pretty sure it will depend on the TV to - that's why I was trying to replicate the normal signal as close as possible, but out of phase... Quote Link to comment Share on other sites More sharing options...
eshu Posted May 7, 2014 Author Share Posted May 7, 2014 Ok - yet another attempt - a slightly different version of kernel 2 - shows some promise on my setup, but that doesn't mean much.... scrolltest2_altx.bin Quote Link to comment Share on other sites More sharing options...
Ed Fries Posted May 7, 2014 Share Posted May 7, 2014 I'm on a business trip until Friday so I can't run any more tests until then. Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted May 7, 2014 Share Posted May 7, 2014 I've tried scrolltest2_alt.bin and scrolltest2_altx.bin on a PAL Jr. and a Philips PAL CRT. Most of the kernels show at least a slight subpixel shift. In scolltest2_altx.bin, kernel 2 has a strong shift to the left, which causes noticeable jumping. It also seems that there is some pincushion distortion (only kernel 2). scrolltest2_alt.bin looks actually quite good. The scrolling jitters a bit, because the shifting is not pixel exact, but from some disctance it's less objectionable than color flicker. If there was some source I would probably try to make a demo with this . I've also tested JTZ_SyncTest_2.bin. Unfortunately, the scrolling is very jumpy and there's also color loss on PAL. Quote Link to comment Share on other sites More sharing options...
eshu Posted May 7, 2014 Author Share Posted May 7, 2014 I've tried scrolltest2_alt.bin and scrolltest2_altx.bin on a PAL Jr. and a Philips PAL CRT. Most of the kernels show at least a slight subpixel shift. In scolltest2_altx.bin, kernel 2 has a strong shift to the left, which causes noticeable jumping. It also seems that there is some pincushion distortion (only kernel 2). scrolltest2_alt.bin looks actually quite good. The scrolling jitters a bit, because the shifting is not pixel exact, but from some disctance it's less objectionable than color flicker. If there was some source I would probably try to make a demo with this . I've also tested JTZ_SyncTest_2.bin. Unfortunately, the scrolling is very jumpy and there's also color loss on PAL. Hi Joe, Thanks for testing - to be fair I think their will be colour issues with mine on a PAL system to - I'm deliberately using white for that reason at the moment. I'm still wondering if their is a way round the subpixel issues, but drawing a bit of a blank at the moment. The altx binary was really aimed at ieposta's setup as I see similar issues with that version of kernel #2 on my setup. The video from Ed's setup of scrolltest2_alt.bin is almost as good as the original binary on my system, but the jitter in kernel 2 seems a bit more pronounced. I literally didn't notice the subpixel issues at full speed, but they are there now if I look carefully/at a slow speed. The source code will be forthcoming once I've got this working as well as possible, as usual with my code it's a bit messy, just trying to get it working a.s.a.p. I can see from Thomas' binary in the debugger that it's a lot more elegant 6502 code - The code for mine is basically in this topic already though - see post #75:http://atariage.com/forums/topic/224946-smooth-scrolling-playfield-i-think-ive-done-it/page-3?do=findComment&comment=2983729 Also, when you tested Thomas' binary were the actual screens stable on slow motion? - just trying to figure out if stuff can be combined from both... Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted May 7, 2014 Share Posted May 7, 2014 (edited) This is amazing progress, I'll have to try it on my setup. Edit: I mentioned it before but an oscilloscope would be really handy to see what signal is actually being sent I have a scope, though I'm not too familiar with it yet and only have NTSC equipment. I'll try to get a nice picture of the signal anyway. Any particular binary you want tested? Edited May 7, 2014 by Wickeycolumbus 1 Quote Link to comment Share on other sites More sharing options...
eshu Posted May 8, 2014 Author Share Posted May 8, 2014 (edited) Nice one - I know absolutely nothing about oscilloscopes, so I don't know what different types there are etc...but it seems to be possible to get a nice picture of the composite video signal (I guess you might have to take this from somewhere on the 2600 before the RF modulator?), or it might be possible just to look at the CSYNC signal from the TIA. I'd like to see how the binaries are affecting the HSYNC pulses. What I'm aiming for is to keep as close to the original signal as possible, but with the picture element shifted and the sync pulse remaining in the same position and of the same length.. If you look at the video I posted, or the wiki page: http://en.wikipedia.org/wiki/Analog_television You can see some scope shots on there... This site has a nice picture breaking the signal down: http://www.ntsc-tv.com/images/tv/sync-wf.gif I'm guessing scrolltest2_alt.bin would be the best of my binaries to work with for now, but you might want to see what is working best on your Atari first. Hopefully you should be able to click through the frames and see how the signal looks.... Edit: This looks like it might be useful - http://www.infernosoft.com/community/Tektronix1410/tvScanLine.html Edited May 8, 2014 by eshu Quote Link to comment Share on other sites More sharing options...
eshu Posted May 8, 2014 Author Share Posted May 8, 2014 I had an idea for something that might remedy the subpixel drift - I've rushed it through so theres every chance I've screwed up - but here is a version of scrolltest2_alt with "stabalisers" - could anyone that binary works well for give this a try and let me know if it's any better..... scrolltest3_alt.bin 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.