It is currently Wed Nov 22, 2017 10:49 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: working with mapper IRQs
PostPosted: Thu Apr 09, 2015 1:56 pm 
Offline

Joined: Mon Jan 23, 2012 11:27 pm
Posts: 141
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

Code:
lda #$xx
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
----


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


$9005 always succeeds the $9006 write, usually with the same value from what I can see. So

Code:
sta $9005

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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group