eshu

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

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

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

Crazy idea - maybe it's scrolling 1&1/3 pixels and I just need to drop a frame??

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

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

ah lol - I forgot to reset their positions - RSYNC means there not getting all their clocks - hold on.... Edit: ok - hopefully fixed file attached - so am I right in thinking: 0->1 1 pixel left 1->2 2 pixel left 2->3 no difference (but some anomolies) 3->0 1 pixel left scrolltestframecount_fixed.bin

Ok - I've added a digit indicating which kernel is running - I'm testing in Stella at the moment, and the timings obviously need to be precise, so hopefully I haven't screwed up - if it's running as before, could you let me know which the troubled ones are..... scrolltestframecount.bin

Ug - that sounds like it's really not working at all on there - have you tried some of the tests from the other thread? http://atariage.com/forums/topic/224748-rsyncvsync-experiment/ 1 and 2 are probably just from me trying to mask the pixels that only appear on some kernels (i.e. are too far left and right to appear on all 4) - I've attached another binary with no masking... Edit: ah lol - the post was edited while I was quoting, sounds like the same as RevEng - I haven't looked at it slowed down on my machine yet, maybe I've just made an error with that Kernel......will take a look later... scrolltestslownomask.bin

I'm really keen to see how the slower test works on your setup - maybe it's the same issue as RevEng below? Hmm that's a shame, I think I'll have to do a test with numbered frames so I can make sure I'm looking at the right one... It's basically variants on the technique I explained in the other thread, but to get the small changes to the HSYNC position you have to use a quirk of the 6502 combined with a quirk of the 2600 - I'm planning to start a blog and write up all the details in there.....Hopefully I'll get it done tonight....I'll post here once it's done...

I have to be quick as I'm trying to put the children to sleep - I've attached a binary slowed down to a 16th of the speed....not tested on real hardware, but looks like the slowdown is working in Stella.... With the original binary, the difference is night and day on my setup - it's scrolling by one pixel = 1 colour clock. I can only shift the screen in increments of three pixels, but combining that with a traditional playfield scroll means we can get 1 pixel precision (because 4-3=1 ) Edit: So it uses 4 kernel setups 0 - no shift 1 - +3 pixels right 2 - +6 pixels right 3 - -3 pixels left Mod 4 these are equal to 0 - 0 1 - 3/-1 2 - 2/-2 3 - 1/-3 So these can be combined with PF's at offsets: 0 - 0 1 - -1 2 - -2 3 - 0 To get: 0-0*4 = 0 3-1*4 = -1 6-2*4 = -2 -3+0*4 = -3 I've done that in a rush, but you get the idea.... scrolltestslow.bin

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

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

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

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

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

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

Thanks for this - I was planning something similar (reading paddle with early HMOVE) - I guess I'll have to get the old girl out of the loft and do some hardware testing once I've written the routine....I'm planning on reading the paddle at about cycle 19 so hopefully the extra seperation might mean the issue doesn't show itself......I wonder how on earth HMOVE could interfere with the inputs!

Can you elaborate? - it doesn't sound like it was just that you wanted to use those cycles, does it somehow mess with the reading?

Ian Bogost wrote a nice article about it: http://www.bogost.com/writing/the_squalid_grace_of_flappy_bi.shtml

I think the game that came with the Dynacom Megaboy was original and produced in Brazil - I'm sure someone more knowledgable on these matters can confirm?

I don't think this works I'm afraid - if [TrafficCacheStart+TrafficOffset0]=%11000000 and [TrafficCacheStart+TrafficOffset1]=%00000000 then it will have both cars enabled where only the first should be (where [address] is the contents of memory at address)

I knew there'd be a trick with BIT, but I couldn't see it - ok a little bit of extra rom used, but how about: LDX TrafficOffset0 LDA TrafficCacheStart,X BPL NoCar0 LDX TrafficOffset1 LDA TrafficCacheStart,X AND #%01000000 BEQ Car0NoCar1 LDA #%01110111 BNE StoreCache Car0NoCar1 LDA #%01110000 BNE StoreCache NoCar0 LDX TrafficOffset1 LDA TrafficCacheStart,X AND #%01000000 BEQ StoreCache LDA #%00000111 StoreCache STA PF1Cache I make that 29 cycles in the worst case.....

Guessing at the rest of your code it would be 8 cycles saved for each other pair of cars, and take 6 cycles to save and restore Y so 10+8+8+8-6=28 cycles saved, could be enough to bring you back to 262 lines....

Uses Y, but should do the same and save 10 cycles off the worst case scenario: LDY #%00000000 ;Clear cache DrawCar0 LDX TrafficOffset0 LDA TrafficCacheStart,X BPL SkipCar0Draw LDY #%01110000 SkipCar0Draw DrawCar1 LDX TrafficOffset1 LDA TrafficCacheStart,X AND #%01000000 BEQ SkipCar1Draw TYA ORA #%00000111 TAY SkipCar1Draw STY PF1Cache