Batari Basic Like Bankswitching in Assembly

[Primordial Ooze]

Does anyone have a simple guide or any info on converting a 4k rom into batari basic's 8k bankswitching? From what I gather when 8k bankswitching is used the graphics are stored in the lower bank(bank 1) and the code is stored in the upper bank(bank 0). However I've read that when bankswitching occurs all previous rom data is lost, yet in batari basic when the graphics are bankswitched in the code remains as if it didn't the game would crash. Any assistance would be greatly appreciated.

 

Sincerely,

 

Primordial Ooze

[SeaGtGruff]

I think you have the upper/lower descriptions reversed-- bank 0 is the lower bank and bank 1 is the upper bank, in that bank 0 has a lower address range than bank 1 in the ROM image. Of course, they both occupy the same memory space when they're swapped in, but for an 8K ROM bank 0 is assigned an ORG address of $1000 and a RORG address of $D000, whereas bank 1 is assigned an ORG address of $2000 and a RORG address of $F000. The ORG addresses are for compiling purposes, to keep the banks in separate but contiguous space within the ROM image (i.e., so the ROM image is 8K in size), and the RORG addresses determine the logical addresses that will be used within each bank. Thus, the ORG addresses could be $0000 for bank 0 and $1000 for bank 1, or $1000 and $2000, or $2000 and $3000, etc.-- any two 4K blocks of addresses that are contiguous to each other (the second one begins immediately after the first one ends). But for the standard bankswitching the RORG addresses for the banks must begin at $1000 or one of its "mirrors"-- $1000, $3000, $5000, $7000, $9000, $B000, $D000, or $F000-- since those are the addresses that will coincide with the 4K cartridge area in the memory space.

 

As far as the graphics data, it depends on what type of graphics data you're talking about. Either the graphics data must be in the same bank as the display kernel (so the kernel can load the graphics as it's drawing the screen), or the graphics must be stored in RAM that's always accessible regardless of which bank is switched in (usually meaning in the zero-page RIOT RAM, or in the Superchip RAM if the Superchip option is being used). If the graphics data were not in the same bank as the kernel, the kernel would have to switch banks as the screen is being drawn so the data could be loaded, then switch back to the kernel's bank so the next instruction can be executed. Normally only the playfield data gets stored in RAM, so you should be able to put playfield data statements in either bank, and the data will be moved to RAM when a particular playfield statement is executed. But the player graphics data normally gets loaded directly from ROM, hence the player0 and player1 statements get their data compiled into the same bank as the kernel. If you want, you can create data tables for the players in the other bank, but then you'd need to copy the data to RAM and modify the player graphics pointers to point to the RAM so the kernel will read the data from there.

 

As far as what happens when the banks are switched, anything that's been written to RAM, or to the TIA or RIOT registers, will stay put, but the 4K ROM area will be completely swapped-- so as you say, "all previous rom data is lost." This doesn't cause the display to crash because the "user code" is executed during the vertical blanking, so it doesn't matter whether the graphics data is still in the currently-selected bank or not. Then bank 1 gets switched in when it's time for the kernel to do its thing, and stays switched in until the kernel is done and turns control back over to the "user code." And batari Basic also handles the bank switching process for you, so your code can do a "goto" from one bank to the other, or "gosub" to the other bank and then "return" back to the first bank, without you having to worry about it much-- aside from the need to be aware that switching banks in a "goto" or "gosub" or "return" does eat up more machine cycles than doing a "goto" or "gosub" or "return" within the same bank.