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
becomes
$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
$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?
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
Code:
lda #$xx
sta $9003
sta $9004
sta $9003
sta $9004
becomes
Code:
lda #$xx
jsr elsewhere
----
pha
lda #$0D ; single irq control field parameter
sta $8100 ;
pla
sta $a100 ; write enable disable flags
rts
----
jsr elsewhere
----
pha
lda #$0D ; single irq control field parameter
sta $8100 ;
pla
sta $a100 ; write enable disable flags
rts
----
$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
Code:
lda #$xx
sta $9006 ; low byte
to
lda #$xx
jsr lowbytewrite
----
pha
lda #$0E
sta $8100
pla
sta $a100
rts
----
sta $9006 ; low byte
to
lda #$xx
jsr lowbytewrite
----
pha
lda #$0E
sta $8100
pla
sta $a100
rts
----
$9005 always succeeds the $9006 write, usually with the same value from what I can see. So
Code:
sta $9005
becomes
jsr hibytewrite
becomes
jsr hibytewrite
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?