eshu

Thanks - I sort of have the powerups down, the one issue is that I can't use the ball which is doing the background colour in the bricks (They're drawn using the playfield as well as playfield and background colour changes), I'm not sure yet whether to have the powerups come from the enemies (ala off the wall), or to have threm drawn differently until they leave the brick area. I'm leaning towards the second - maybe sort of dashed lines falling quickly until it leaves the brick area, or a question mark until it leaves the brick area - anyway that's a way away for now, I'll do some tests once/if I get that far....

Hey theloon, please don't feel like I'm hijacking your project, theres no reason two versions couldn't be done (see the current donkey kong projects). I couldn't resist having a crack at a kernel which handled multi-colour bricks which I think would be tricky with the standard Bb kernels without giving up a lot of objects. I had a feeling you had stopped working on it as you've been active on other projects. I really would like to complete this one but there's a long way to go yet, and the kernel tends to be the most fun part for me...

Here's a sneak peak of something I've been working on - it's just a kernel test at the moment really - I ran into a couple of bugs in stella, so theres two binaries attached, one for stella and one for the real machine.....I'm due to work on the proper ball movement and bat collisions next, the ones in this version are not how I plan on implementing it, they are a bit buggy but I need to rework all the code for different speeds of the ball etc... If anyone does have a chance to test it on real hardware - I need to make sure the paddle read is working ok, seems fine on my hardware, but my paddles are bit jittery anyway so it's hard to be sure - Omegamatrix mentioned issues with paddle reads and early hmove here: http://atariage.com/forums/topic/223653-maintaining-p0-horizontal-position-after-previous-resp0/ I'm not planning to do an exact clone of arkanoid as I prefer to do things in a way that suits the 2600 - the enemies won't go into the brick area or cross the same scanlines as I'm flicker averse, also multi-ball will only have two balls and a few other changes I'm sure.... The bricks are just a random mix of colours at the moment to test the kernel - it supports three different colour bricks per line with some limitations Excuse the programmer graphics The screenshot below is with Stella's NTSC ratio set all the way down at 81 - this is about the ratio I see on my screen. paranoid_0.01_stella.bin paranoid_0.01_real.bin

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

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

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?

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?

I think I found a bug that would be causing the issue with the 2 digit - fixed binary attached... scrolltest2_alt.bin

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

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

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

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.

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

Unfortunatley it still looks like there is a definite jerk to me - I'm out all day today, so I won't get much of a chance to look at this 'til much later...

Ok - heres a quick and dirty attempt to copy those kernel versions into the smooth scroller....I'm bound to have got something wrong, but please try it out and let me know.... scrolltest_alt.bin

Am in the middle of something but saw you'd posted - up, down and right look like they'll do the trick - I'll work on something later - very pleased - thanks for all your help with this.....

Ug - ok maybe I went the wrong way last one for now I promise .... newsynctest_alt2.bin

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

It would be quite handy to see the new sync test if you could? Thanks 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....

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?

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

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

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

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

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