Optimizing scroll changes after MMC3 IRQs

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
Bregalad
Posts: 7892
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Optimizing scroll changes after MMC3 IRQs

Post by Bregalad » Thu May 07, 2020 1:38 pm

OK so ignore my previous post.

The only thing that would suppress all waiting is somehow being able to write to $2006.2 between dot 260 and 328, am I correct ?

This means a window of 22.66 CPU cycles, but since we have 6 extra cycles of jitter (carefully avoiding 7-cycle instructions), there's only 16.66 CPU cycles remaining for actually writing to $2006.

IRQ latency on CPU itself is 7 cycles , which leaves 9.66 cycles for the programm.... A "sta $2006" is 4 cycles; this leaves 5 cycles for something before, just enough for a ZP/stack store and an LDA #immediate which should be self-mod code with already the correct $2006/2 value.

So that might be worth a try ! But something tells me I'm probably forgeting some detail again which makes my idea moot like all the previous.

IRQ would be something like:

Code: Select all

IRQ :
  sta zp_save_a      ; could as well be PHA also 3 cycles, but restoring would slower
  lda #$00               ; changed on the fly by means of selfmod code
  sta $2006             ; The crutial $2006/2 write that should happen just behind dot 328 in worst case
  stx selfmod_save_x+1

  (....)  ; logic here

  lda scolltableh, X
  sta $2006           ; write to $2006/1
  lda scrolltablel,X
  sta IRQ+4           ; write to $2006/2 on next IRQ
  
  lda zp_save_a
selfmod_save_x:
  ldx #$00         ; changed on the fly by means of selfmod code
  rti
  

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Optimizing scroll changes after MMC3 IRQs

Post by tokumaru » Thu May 07, 2020 3:25 pm

Bregalad wrote:
Thu May 07, 2020 1:38 pm
The only thing that would suppress all waiting is somehow being able to write to $2006.2 between dot 260 and 328, am I correct ?
That's right.
(carefully avoiding 7-cycle instructions)
I guess this won't be much of a problem. Basically I'd have to avoid indexed RMW instructions, which I hardly ever use anyway.
just enough for a ZP/stack store and an LDA #immediate which should be self-mod code with already the correct $2006/2 value.
OK, putting the IRQ handler in RAM and avoiding 7-cycle instructions gets us down to 22 CPU cycles until the point where the $2006 write finishes. This would place the scroll change at most on PPU cycle 326! That sounds dangerously close to the limit, and if there are any minute hardware quirks I'm not aware of delaying things 1 or 2 cycles, this could definitely blow up! Otherwise, it actually sounds doable! :D
But something tells me I'm probably forgeting some detail again which makes my idea moot like all the previous.
The only thing I can think of is that this is still not good enough for PAL and its slower CPU, where 22 CPU cycles translate to 70.4 PPU cycles, meaning that the scroll change could still happen past PPU cycle 328, where the first X auto-increment happens. :cry:

User avatar
aa-dav
Posts: 92
Joined: Tue Apr 14, 2020 9:45 pm
Location: Russia

Re: Optimizing scroll changes after MMC3 IRQs

Post by aa-dav » Thu May 07, 2020 6:21 pm

How about heavy metal magic - relaying on hdraw-ignited IRQ, but not waste scanline time, but fill it with useful calculations with fixed clock times (do not cross page boundaries, tune up branches and so on)?
So, time will not be wasted and time limit will be reached.
ZX Spectrum has modern games with fixed clock times during almost all VDraw phase, because it just doesn't have ways to trap hdraw/hblank. For example all sprites are drawn (in software of course), but invisible ones are written in ROM.

User avatar
tokumaru
Posts: 11772
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Optimizing scroll changes after MMC3 IRQs

Post by tokumaru » Thu May 07, 2020 6:32 pm

aa-dav wrote:
Thu May 07, 2020 6:21 pm
How about heavy metal magic - relaying on hdraw-ignited IRQ, but not waste scanline time, but fill it with useful calculations with fixed clock times (do not cross page boundaries, tune up branches and so on)?
Yeah, that remains the most likely route for me. I will probably set up the pattern tables so the IRQ fires at the latest possible time, do useful calculations throughout the scanline, and finally change the scroll at the beginning of hblank.
Last edited by tokumaru on Fri May 08, 2020 1:02 am, edited 1 time in total.

calima
Posts: 1160
Joined: Tue Oct 06, 2015 10:16 am

Re: Optimizing scroll changes after MMC3 IRQs

Post by calima » Fri May 08, 2020 12:14 am

lidnariq wrote:
Thu May 07, 2020 10:33 am
Do we need to transclude [[VRC IRQs]] into the VRC4 page?
Actually having it in an iframe or similar would be rather good. No other mapper page has such a split, it breaks user expectations.

Post Reply