Jump to content
IGNORED

A2600 8k bank-switching newbie question


vdub_bobby

Recommended Posts

So, I'm trying my first stab at bank-switching...and I've got this code in bank 1:

	org $1FF5

rorg $FFF5

SwitchToBank2Subroutine

lda $1FF9	;switch to Bank 2

rts  ;return from subroutine

And this code in bank 2:

	org $2FF5

rorg $FFF5

SwitchToBank1Subroutine

lda $1FF8	;switch back to bank 1

jmp Bank2SubroutineSelect

With the idea that, while in bank 1 I can 'jsr SwitchToBank2Subroutine' and it will switch to bank 2 and, once in bank 2, I do whatever I want to do and, then, to switch back I 'jmp SwitchToBank1Subroutine' which will switch me back, grab the rts and go back to the original subr call.

 

This works in PCAE. But in z26 it is grabbing the rts before it switches banks but executing it in the second bank. Here's the relevant part of the z26 log file:

(  1   4  30  22) ( 69  39   8   2   2) nvbdIZc 00 00 00 ff  f03f: 29 3f    and #3f

(  1   4  32  28) ( 69  39   8   2   2) nvbdIZc 00 00 00 ff  f041: f0 02    beq  f045

(  1   4  35  37) ( 69  39   8   2   2) nvbdIZc 00 00 00 ff  f045: a2 00    ldx #00

(  1   4  37  43) ( 69  39   8   2   2) nvbdIZc 00 00 00 ff  f047: 20 f5 ff jsr  fff5

(  1   4  43  61) ( 69  39   8   2   2) nvbdIZc 00 00 00 fd  fff5: ad f9 1f lda  1ff9    <--- bank switch here

(  1   4  47  73) ( 69  39   8   2   2) nvbdIzc 03 00 00 fd  fff8: 60       rts       <--- this is in bank 1?!

(  1   4  53  91) ( 69  39   8   2   2) nvbdIzc 03 00 00 ff  f04a: 85 81    sta  81  <--this is in bank 2!?

(  1   4  56 100) ( 69  39   8   2   2) nvbdIzc 03 00 00 ff  f04c: 4c 5e f0 jmp  f05e

(  1   4  59 109) ( 69  39   8   2   2) nvbdIzc 03 00 00 ff  f05e: a4 f6    ldy  f6

(  1   4  62 118) ( 69  39   8   2   2) nvbdIZc 03 00 00 ff  f060: e6 f6    inc  f6

What am I doing wrong here?

Link to comment
Share on other sites

Nothing wrong that I can see...but some addresses seem to execute slower than others. Have a look here:

http://www.atariage.com/forums/viewtopic.php?t=58667

Very similar to the problem you are describing.

 

 

 

BTW You can use STA's instead of LDA's to trigger the bankswitch (so you can save A from being overwritten). The bankswitch will happen no matter how those addresses are accessed :)

Link to comment
Share on other sites

Nothing wrong that I can see...but some addresses seem to execute slower than others.  Have a look here:

http://www.atariage.com/forums/viewtopic.php?t=58667

Very similar to the problem you are describing.

 

 

 

BTW You can use STA's instead of LDA's to trigger the bankswitch (so you can save A from being overwritten).  The bankswitch will happen no matter how those addresses are accessed :)

Thanks; I found that thread immediately after posting this - I've tried a few things, and nothing's helped :(

 

It seems like z26 is waiting waiting waiting to switch banks until...something? I added a nop after the 'lda $1FF9' and it then grabbed the nop AND the rts before switching banks. I added another nop and it grabbed both nops AND the rts and then switched banks. I tried three nops, same thing. I moved the 'rts' statement in front of the 'lda $1FF9' statement like this:

Bank 1:

	org $3FF0

rorg $FFF0

nop

nop

nop

rts





org $3FF5

rorg $FFF5

SwitchToBank2Subroutine

sta $1FF9	;switch to Bank 2

nop

nop

nop

nop



org $3FFC

rorg $FFFC

.word StartBank1 ;$F003

.word StartBank1 ;$F003

And in Bank 2:

	org $4FF0

rorg $FFF0

SwitchToBank1Subroutine

sta $1FF8

nop



nop

nop

nop

nop



jmp Bank2SubroutineSelect ;this is at addy $4FF8/$FFF8

nop	





org $4FFC

rorg $FFFC

.word StartBank2 ;$F000

.word StartBank2 ;$F000

And got this truly weird log file from z26:

...[snip]...ff  f045: a2 00    ldx #00      

...[snip]...ff  f047: 20 f5 ff jsr  fff5    <--bank 1

...[snip]...fd  fff5: 8d f9 1f sta  1ff9    <--switch to bank 2?

...[snip]...fd  fff8: ea       nop          <--bank 1/2?

...[snip]...fd  fff9: 03 f0    slo (f0,x)   = CXM0P   <--what the...?  F003 is the start/brk vector (in bank1), but it isn't at FFF9

...[snip]...fd  fffb: ea       nop          <--bank 1 or 2?

...[snip]...fd  fffc: 00       brk          <--huh?  I guess we are in bank 2 now; this is the LSB of the brk vector in bank 2.  ???  So that takes us to

...[snip]...fa  f000: ad f8 1f lda  1ff8    <--Where a bank switch to bank 1 is performed, no problem (this time), to 

...[snip]...fa  f003: 78       sei          <--the init code

This doesn't even make sense to me...I'm running z26 v. 2.13.

Link to comment
Share on other sites

Aaaa...I missed something easy!

Your instructions exist past $xFF7!

 

   org $1FF5 

  rorg $FFF5 

SwitchToBank2Subroutine 

($FFF5-7)   lda $1FF9     ;switch to Bank 2 

($FFF8)   rts        ;return from subroutine 

 

And this code in bank 2:

   org $2FF5 

  rorg $FFF5 

SwitchToBank1Subroutine 

($FFF5-7)   lda $1FF8     ;switch back to bank 1 

($FFF8-B)   jmp Bank2SubroutineSelect 

 

 

The program counter itself was probably causing the bankswitch.

Move them back a little:

 

   org $1FF2 

  rorg $FFF2 

SwitchToBank2Subroutine 

($FFF2-4)   lda $1FF9     ;switch to Bank 2 

($FFF5)   rts        ;return from subroutine 

($FFF6)   NOP;unused

($FFF7)   NOP;unused

 

And this code in bank 2:

   org $2FF2 

  rorg $FFF2 

SwitchToBank1Subroutine 

($FFF2-4)   lda $1FF8     ;switch back to bank 1 

($FFF5-7)   jmp Bank2SubroutineSelect 

Link to comment
Share on other sites

Nope...you can't use them at all in either bank. The moment that those addresses are accessed at all it would cause a bankswitch. the 2 NOP instructions above could be replaced with a 2-byte data table tho...if you have one.

 

BTW you also need to make sure that the cart can boot from either bank.

 

 

;boot code (bank1)

START1:

     STA   $1FF9

     NOP

     NOP

     NOP

 

;boot code (bank2)

START2:

     NOP

     NOP

     NOP

     JMP   START;jump to init routine

 

 

That will insure that the cart can boot from either bank (because on power-up, this flip status will be unknown). The init routine exists in bank2 in this example...switch them around if your init routine is in bank1.

The vector at $FFFC would be START1/START2 instead of START.

Link to comment
Share on other sites

So what, exactly, should I be avoiding here? Any code past $xFF7? Can I put data there?

The 6507 does a dummy fetch of PC+1 when executing an RTS, so you can't put an RTS at xFF7 either as it would switch banks. You'd need to bump it up to xFF6. I've found that some emulators don't emulate the dummy fetch, so this might lead to strange bugs that don't turn up until you try to run on a console. I think you're OK with data at xFF7.

Link to comment
Share on other sites

I've found that some emulators don't emulate the dummy fetch, so this might lead to strange bugs that don't turn up until you try to run on a console.

:idea: Usually PCAE only emulates correct code correctly, z26 is much better for developing as it also emulates a lot of incorrect code incorrectly.

Link to comment
Share on other sites

I've found that some emulators don't emulate the dummy fetch, so this might lead to strange bugs that don't turn up until you try to run on a console.

:idea: Usually PCAE only emulates correct code correctly, z26 is much better for developing as it also emulates a lot of incorrect code incorrectly.

 

Yeah, I have noticed that PCAE isn't as accurate as z26 in some weird cases - but that debugging tool is sure handy :)

 

Oh, and thanks for all the help with the bank switching.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...