Please explain bankswitching in a way a non-programmer would get

[Lendorien]

Ok, in the discussion of Atari games, this term "bankswitching." come up a lot. Can someone please define it for us non programming idiots in a way that we'd be able to understand? I've always been curious about it. I assume it's a way to switch from piles of data to increase the amount if information a program can access, but I'm not really clear on how it works or the exact benefit beyond my supposition above.

 

Anyone able to help me out?

Edited September 30, 2010 by Lendorien

[CPUWIZ]

How Bankswitching Works

--- ------------- -----

 

Bankswitching allows game programmers to include more data into a cartridge,

therefore making (hopefully) a better game with more graphics/ levels.

 

Bankswitching works under similar principals in all cases. Basically, by

reading a certain location in ROM switches banks.

 

 

(this is the F8-style of bankswitching)

 

Bank #1 Bank #2

--------------------------------------------------------------

1000 JSR $1800 (do subroutine) .

1003 (program continues) 1200 _subroutine goes here_

. 1209 RTS

. .

1800 LDA $1FF9 (switch to bank 2) 1802 (rest of program)

1803 NOP 1803 JSR $1200

1804 NOP .

1805 NOP .

1806 NOP 1806 LDA $1FF8 (Switch back to bank 1)

1807 NOP .

1808 NOP .

1809 RTS (We're done w/ routine) 1809 (rest of program)

 

OK, we start out in bank #1 and we want to run a subroutine in bank #2.

 

What happens is this- the processor starts at 1000h in bank #1. We call

our subroutine from here. 1800h: We do a read to change us to bank #2.

Remember that when we change banks, we are basically doing a ROM swap.

(You can think of bankswitching as 'hot-swapping' ROMs) Now that we're

in bank #2, the processor sees that JSR to $1200, which is the subroutine

that we wanted to execute. We execute the subroutine and exit it with an

RTS. This brings us back to 1806h. We then do another read to select bank

#1. After this instruction finishes, the processor is now in bank #1, with

the program counter pointing to 1809, which is an RTS which will take us

back to 1003 and let us continue on with our program.

 

 

[+Random Terrain]

More about bank switching:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#bankswitching

[+5-11under]

Adding to the discussion...

 

Consider the Atari 2600 cartridge. Connections to the cartridge include power, 8 data lines, and 12 address lines (and ground, which is the reference for all of these). The data and address lines are all binary, meaning they're each either a 1 or a 0. A 1 will be about 5 volts, and a 0 will be about 0 volts. The 8 data lines translate into 2^8 (2 to the power of combinations, or 0-255 in decimal. 8 bits (of data)! The 12 address lines translate into 2^12 combinations, or 4096 in decimal (4K). The address lines are what select different locations of memory, and the data lines are the contents of each of those locations. So there's 4096 memory locations, that can be used as part of the program. This is great if your program can fit into these 4096 locations. If you need more program space, then bankswitching can be a fairly simple way to obtain more space. Basically, the way it usually works is that if you touch a certain "hot spot" location in memory, for instance by reading the data from that certain location, part or all of the 4K memory gets swapped with another "bank" of memory, using logic to select the bank. Now your program continues to run using the swapped in memory. Two banks would give you 8K total available program space.

 

5-11under

[+SpiceWare]

The way I explain it is to think of the Atari cartridge as a book.

 

In the same way that you can only see a page* at a time, the Atari can only see 4K worth of cartridge at a time. A 32 K game could then be looked at as an 8 page book. If the routine you need the Atari to run is on page 4, you trigger a hotspot which has the meaning of "turn to page 4".

 

* for this example, each page has text on only 1 side.

[tetrode kink]

IMHO SpiceWare (Mr. Medieval Mayhem) explained it best. The only way I would improve on his explanation is to complete the metaphor: The hot-spot the programmer hits when he wants to switch banks (turn the page) is a apecial "corner" of the ROM, or the corner of the page you reach for when you want to turn the page.

[+Random Terrain]

IMHO SpiceWare (Mr. Medieval Mayhem) explained it best. The only way I would improve on his explanation is to complete the metaphor: The hot-spot the programmer hits when he wants to switch banks (turn the page) is a special "corner" of the ROM, or the corner of the page you reach for when you want to turn the page.

That example reminds me of a Choose Your Own Adventure book.

Edited October 1, 2010 by Random Terrain

[yllawwally]

Do all the bank switching schemes require you to have executable code in all the banks? For example if I wrote a small game that took up only 1.5k, however it needed access to 60k of space, for images. Like a video player type of application. Looking at the 3f version, it seems that there would need to be code in each bank.

[+SpiceWare]

No, some bank switching schemes use banks that are smaller than 4K. Parker Brothers uses 1K banks, so you see four of them concurrently and can switch them out independently.

[Blacklight]

After reading all that, I'm still completely lost. Hehehe

It's going to have to be explained a LOT simpler for me to get it.

[+Gemintronic]

Imagine a book factory that can only print books with 256 pages. An author writes his novel that takes up 512 pages. In order to get his book published he gets 2 books made - one with the first 256 pages and another with the last 256 pages. If a reader wants to read the whole novel they must book switch from the first book to the second book.

 

I'm just regurgitating SpiceWare's analogy but sometimes slightly different words help

Edited September 21, 2012 by theloon

[+FujiSkunk]

Ever played games on a computer? Ever played games loaded from floppy disks? Ever played games that were so big, different sections of the game had to be loaded from disk at different times? That's exactly the concept behind bank switching, only it's with cartridges instead of disks.

[Blacklight]

NOW I get it!!!

[bennybingo]

I switched banks recently...got tired of paying for my checking!

[Bryan]

Another way to think of it is like virtual cartridges. Let's say your game does not fit in a standard 4K cartridge, but it does fit in 2 4K cartridges. If there were a way to stop the 2600's CPU, swap cartridges, and continue, you could play the 8K game albeit with constant annoying delays. If the cartridges could be swapped instantly (that is, in the time between CPU instructions) then the 8K game could run without any perceptible delays but the 2600 would never have access to the entire 8K game all at once.

 

In practice, it's up to the programmer to arrange all his code and data so that code in one bank doesn't try to jump to routines or use data located in the other bank or things will go very wrong. When it's time to perform tasks located in the other bank, the bank-switch mechanism is triggered and execution continues from the current address in the other virtual cartridge. Everything must be carefully managed but the bank switches can occur as frequently as you wish.

 

There are many different banking schemes out there and sometimes only part of the cartridge changes with a bank switch, allowing a routine in the fixed (non-banked) area to access data from any of the available banks (as long as it selects the bank first).