|working with mapper IRQs
|Page 1 of 1|
|Author:||FrankWDoom [ Thu Apr 09, 2015 1:56 pm ]|
|Post subject:||working with mapper IRQs|
context: I'm trying to convert Spartan X 2 from mapper 65 to FME7. I more or less have the bank swap routines in place for prg and chr and I can start the game. It'll run for maybe 10s before I hit a bad opcode and the cpu locks. Onscreen the scrolling and fixed bg graphics don't seem to be split are the right height maybe 6-8 lines below where they should be. This is an irq issue right?
Points of concern:
The #65 has only 1 enable flag on $9003. The fme7 has separate bits for enable counter and enable irq. Setting the flag/s either way on both mappers acknowledges pending irq. For the conversion I'm enabling both flags on the fme7 any time the single flag on the #65 was enabled, and disabling both for the opposite case. Is there any problem with that approach? (I'm testing with the latest nintendulator build with the fixed irq ack process).
Here's how I'm dealing with $9003/4
lda #$0D ; single irq control field parameter
sta $8100 ;
sta $a100 ; write enable disable flags
$9003 and $9004 are always written at the same time afaik. I don't see that fme7 has an explicit write for "reload" equivalent to writing to $9004. Does that mean that reloading the value and enabling (whenever $9003 would be written as such) is the appropriate action?
Both mappers have 16-bit counters that tick down to 0 by 1 every cpu cycle. #65 stops at 0 and fires the irq, where fme7 rolls over from 0 to #$FFFF and then fires. So, they work very much the same excepting a 1 cpu cycle difference in timing? Is that significant? Because the fme7 control writes are chewing up way more than that.
When setting the counter value, we are aiming for it to fire at a specific scanline right? For NTSC we have 262 scanlines/frame, 29780.5 cpu cycles/frame, 113.667 cpu cycle/scanline? So the counter gets set to 113.667 * N to target a scanline relative to whatever scanline I'm on when the irq counter is enabled again? How am I supposed to know what scanline I'm on at any given moment?
counter value writes now look like
sta $9006 ; low byte
$9005 always succeeds the $9006 write, usually with the same value from what I can see. So
which is the same pattern using $0F as the control byte. I'm doing prg and chr banks in a similar fashion.
I'm guessing the counter values that would work for the original mapper aren't going to apply anymore because cpu cycle counts are likely off writing to the fme7 controls vs a single address. Or am I doing something else wrong? Is there a workable solution to this?
|Page 1 of 1||All times are UTC - 7 hours|
|Powered by phpBB® Forum Software © phpBB Group