Auto arange for bankswitching?

[+grafixbmp]

Are there ways for doing a straight program without worrying about bankswitching and then feed the program (larger than 4k) through an auto arangement software program than breaks up the program automaticaly for bankswitching? I remember something mentioned about this in DASM. Is this true? Or is there something similar out there or would this be a good idea?

[SeaGtGruff]

Are there ways for doing a straight program without worrying about bankswitching and then feed the program (larger than 4k) through an auto arangement software program than breaks up the program automaticaly for bankswitching? I remember something mentioned about this in DASM. Is this true? Or is there something similar out there or would this be a good idea?

If you're referring to writing code for a program, you can just use ORG and RORG to control where each bank will go, you don't need to pass the program through anything else.

 

Michael

[supercat]

A future bank-switching chip may allow some things to be more convenient than they are now, but there's no way to implement a "flat" memory scheme. Stuff will have to be subdivided into banks, and it will almost always be necessary for code to explicitly switch banks. With FE banking it's possible to avoid the need for explicit bank-switch instructions, but I know of no hardware to implement that in anything other the pre-existing cartridges which use it. I don't even know if anyone has fully characterized how FE banking works.

[vdub_bobby]

I did come up with a scheme that allowed me to call subroutines in any bank, from any bank, without worrying where they were. It used the break vector (and opcode), like this:

 

You need something like this at the same place in every bank:

BankSwitchSubroutine5
plp
tsx
dec $01,X
lda ($01,X)
sta MiscPtr
inc $01,X
lda ($01,X)
sta MiscPtr+1
lsr
lsr
lsr
lsr
lsr
tax
nop $1FF4,X

jmp (MiscPtr)

ReturnFromBSSubroutine5
tsx
inx
inx
lda $00,X	 ;get high byte of return address
lsr
lsr
lsr
lsr
lsr
tax
nop $1FF4,X

rts

And then at the end of every bank, point the break vector to your bank-switch subroutine:

	org $5FFC
rorg $9FFC
.word Start5
.word BankSwitchSubroutine5

Then call a subroutine like this:

	brk
.word MusicSubroutine

And when returning from a subroutine, use this code:

	jmp ReturnFromBSSubroutine8

Oh, almost forgot: this requires you to RORG your banks to odd 4K banks, i.e., $1000, $3000, $5000, $7000, etc. At least I think it does; I can't remember exactly why.

[+grafixbmp]

I did come up with a scheme that allowed me to call subroutines in any bank, from any bank, without worrying where they were. It used the break vector (and opcode), like this:

 

You need something like this at the same place in every bank:

BankSwitchSubroutine5
plp
tsx
dec $01,X
lda ($01,X)
sta MiscPtr
inc $01,X
lda ($01,X)
sta MiscPtr+1
lsr
lsr
lsr
lsr
lsr
tax
nop $1FF4,X

jmp (MiscPtr)

ReturnFromBSSubroutine5
tsx
inx
inx
lda $00,X	;get high byte of return address
lsr
lsr
lsr
lsr
lsr
tax
nop $1FF4,X

rts

And then at the end of every bank, point the break vector to your bank-switch subroutine:

	org $5FFC
rorg $9FFC
.word Start5
.word BankSwitchSubroutine5

Then call a subroutine like this:

	brk
.word MusicSubroutine

And when returning from a subroutine, use this code:

	jmp ReturnFromBSSubroutine8

Oh, almost forgot: this requires you to RORG your banks to odd 4K banks, i.e., $1000, $3000, $5000, $7000, etc. At least I think it does; I can't remember exactly why.

 

That is too cool. I may actualy wind up using that, if you don't mind. This may save me alot of hassle. Right now I have just been working on a way to create alot of picture data without wasting too much time. This would allow me to call up the data I need when I need it. The problem is having the tools to create the data I need. I was thinking about creating a new app for drawing atari graphics and saving the bianary data from it. just have to decide on what to code the app in. I was debating on using purebasic and then I can build the graphics with it. If I EVER come up with it, I'll share it free to all.

[TROGDOR]

I have a bank switching strategy that has worked well in my 8k games. I only allow one entry point into bank 2, and one return point back to bank 1. The program flow is:

 

There are several advantages to this system:

 

- The re-entry points from one bank to another don't have to be saved because the program flow is hard-coded with JMPs. (i.e. when you return back to bank 1, a JMP will take you back to the start of the Overscan code.) This saves two stack bytes of RAM.

 

- Calling bank-switched subroutines eats a lot of extra cycles. This is avoided.

 

- It's easy to balance the content between bank 1 and bank 2 to keep ROM use evenly distributed. If your VBlank and Overscan code is larger than your Kernel code, you can relocate some of the end of the VBlank code or the start of the Overscan code into Bank 2, while maintaining the same flow. The same is true if your Kernel code is larger than your VBlank and Overscan. For example, you could move some of the Kernel initialization code into Bank 1 with the VBlank.

 

- Kernel code is usually self-contained. For example, if you're displaying text in your kernel, the graphics for that text will generally only be used inside the kernel. Likewise, many overscan functions, such as random number generators, joystick reading, sound effects, and AI, would never be used in the kernel, so it makes a good logical split for bank switching.

 

- If you need to set up vectors in your Bank 1 VBlank, you can still reference data locations in

Bank 2. For example, if you want to display a 6 digit score in your kernel, you can set up the 12 vector bytes in the VBlank of Bank 1, and then use the vectors in Bank 2. If the score graphics are defined at symbol "Numbers" at location $1C00 in Bank 2, the code in Bank 1 can still reference the symbol Numbers, even though the symbol's data technically lives in Bank 2. It will safely load the correct location, as long as it doesn't try to actually use the vector content until it's in Bank 2.

 

- Bank switching is confusing enough as is. The ROM code for single-point bank switching is small and simple.

By only having one return point, you are less likely to create bugs by mis-referencing data across banks.

Edited March 22, 2008 by TROGDOR