Stable interrupt discussion

LocalH · Post by **LocalH** » Thu Dec 10, 2009 6:02 pm

I come from the C64 where stabilizing the raster IRQ is paramount to doing any high-end VIC effects (since being just one cycle off can be the difference between a routine working or failing). The typical method for doing this on the C64 is to use a double interrupt - you set an interrupt for the line before you actually want to do anything, then you busywait until just before the end of the line using NOPs, after setting the IRQ for the next line. Thus, instead of having up to 7 cycles of jitter before the code for your IRQ is actually running, you have one cycle of jitter which can be handled with a simple CMP/BNE combo that uses one more cycle if you're not actually on the desired scanline - hence from that point the IRQ will trigger on the exact same cycle each line.

Has anyone made any effort to try and duplicate this on the Genesis? Many of the C64's VIC quirks are based on register-banging on specific cycles of the scanline, and I'm thinking the VDP might have a few unlockable "secrets" if we could bang it at just the right time on each scanline. For example, C64 sprite stretching is done by twiddling the Y-expand bit at just the right time on each line. I'm not saying we'd be able to stretch sprites, because the Genesis has no sprite enlargement functionality. I'm merely saying that I would bet on there being a few things the VDP could do if we raped it in such a manner.

At the very least, a stable interrupt would allow mid-line backdrop changes without jitter, which could potentially increase color resolution in properly-designed cases (giving an effective resolution of 16 colors for said cases instead of 15 plus background). One could use black for the border region then change the backdrop shortly within the addressable screen, then change it back to black shortly before the right border. I know there are only so many "slots" for writing to the VDP, but there is still massive jitter.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat Dec 19, 2009 7:29 pm

One thing I can tell you is that you can forget all your ideas when Z80 runs and accesses the ROM, it will mess up anything requiring cycle accuracy like you want to achieve.
My sound engine was causing quite a bit of headache for Fonzie long ago regarding raster effects and Pier Solar.

LocalH · Post by **LocalH** » Mon Dec 21, 2009 2:31 am

One could get past that by using a 68k driver such as S1 SMPS and then simply don't use the Z80 at all, no DAC. =P

I seriously think this might be worth pursuing. Even still today people find new tricks on the C64 thanks to being able to abuse the system with such fine-grained control.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Dec 21, 2009 8:10 am

I would have said that YM accesses will cause trouble too, but then I remembered that Z80 is stopped, and should not be causing trouble, unless there's more fun happening... YM is on the Z80 bus afterall.
No emulator emulates the performance hits both CPUs cause each other when they run and access same resource (the 68K side bus). There would be a very slight increase in performance on Z80 side when you halt the 68K.
I'm not that much into the demo stuff, I like making games more (a fun demo effect every once in a while inside the game would be neat though)