79 replies to this topic

[Wickeycolumbus]

I have been writing simple demos using different bankswitching schemes, so I thought I would post them for people that are interested in using bankswitching in their games. So far, I have:

F8
F8SC (F8 + RAM)
F6
F6SC (F6 + RAM)
F4
FA (CBS + RAM)
F0 (MegaBoy)
0840 (EconoBanking)
UA Limited

In the next week or so, I will be writing more demos for other schemes (FE, F4SC, E0, 3F, E7, SB, ect...), so stay posted

Attached Files

•  Bankswitching.zip   13.46K   160 downloads

[SeaGtGruff]

Wickeycolumbus, on Tue Mar 31, 2009 9:57 PM, said:

I have been writing simple demos using different bankswitching schemes, so I thought I would post them for people that are interested in using bankswitching in their games. So far, I have:

F8
F8SC (F8 + RAM)
F6
F6SC (F6 + RAM)
F4
FA (CBS + RAM)
F0 (MegaBoy)
0840 (EconoBanking)
UA Limited

In the next week or so, I will be writing more demos for other schemes (FE, F4SC, E0, 3F, E7, SB, ect...), so stay posted

Cool, thanks! Bankswitching is a topic I like, and from time to time I've tried to get descriptions and instructions for all of them together in a single document, but some of them (newer ones especially) are more obscure-- plus, people like batari (Fred Quimby) and supercat (John Payson) keep inventing new ones!

Michael

[roland p]

This should be a sticky.

[Impaler_26]

I found two other Templates, there might be a few more on AA...

F8

F6

[Wickeycolumbus]

Time for an update Now there is a 128K SuperBanking demo included (boy that took for ever to make ). For some reason, I could not get F4SC or FE to work. Also, does anyone have any info on the CommaVid (CV) scheme?

256K SuperBanking is next!

Please note, some of ROMs to not get recognized properly by Stella, so you may have to manually set the BS mode.

Attached Files

•  Bankswitching_2.zip   16.07K   114 downloads

[SeaGtGruff]

Wickeycolumbus, on Sun Apr 5, 2009 2:14 AM, said:

does anyone have any info on the CommaVid (CV) scheme?

According to what I just found by Googling, CommaVid didn't use any bankswitching schemes per se. However, you will see a "CV" method listed among the available bankswitching schemes of most Atari 2600 emulators and programmable carts (e.g., the Cuttle Cart, the Cuttle Cart 2, and the Krokodile Cartridge) because at least one of their games-- "Video Life"-- did use an alternate cartridge scheme. It's still just a 4K cart, but it has 2K of ROM and an extra 1K of RAM. Back then they didn't have supercat's "magic writes" for extra RAM, so any extra RAM had to use up twice as much memory space as the actual RAM chip size-- e.g., 128 bytes of extra RAM (as in Atari's Superchip) actually used up 256 bytes of memory space, and 256 bytes of extra RAM (as in some of CBS's carts) actually used up 512 bytes of memory space. That's because the extra RAM had to be read through one set of addresses, and written to through another set of addresses. So CommaVid's 1K of extra RAM actually used up 2K of memory space. Based on what Eckhard Stolberg wrote in the AtariAge forums on February 1, 2007, the CommaVid scheme has the following format:

$1000 through $13FF (or $F000 through $F3FF) = the read addresses for the 1K of extra RAM
$1400 through $17FF (or $F400 through $F7FF) = the write addresses for the 1K of extra RAM
$1800 through $1FFF (or $F800 through $FFFF) = 2K of ROM

Michael

[stephena]

SeaGtGruff, on Sun Apr 5, 2009 10:34 AM, said:

Wickeycolumbus, on Sun Apr 5, 2009 2:14 AM, said:

does anyone have any info on the CommaVid (CV) scheme?

According to what I just found by Googling, CommaVid didn't use any bankswitching schemes per se. However, you will see a "CV" method listed among the available bankswitching schemes of most Atari 2600 emulators and programmable carts (e.g., the Cuttle Cart, the Cuttle Cart 2, and the Krokodile Cartridge) because at least one of their games-- "Video Life"-- did use an alternate cartridge scheme. It's still just a 4K cart, but it has 2K of ROM and an extra 1K of RAM. Back then they didn't have supercat's "magic writes" for extra RAM, so any extra RAM had to use up twice as much memory space as the actual RAM chip size-- e.g., 128 bytes of extra RAM (as in Atari's Superchip) actually used up 256 bytes of memory space, and 256 bytes of extra RAM (as in some of CBS's carts) actually used up 512 bytes of memory space. That's because the extra RAM had to be read through one set of addresses, and written to through another set of addresses. So CommaVid's 1K of extra RAM actually used up 2K of memory space. Based on what Eckhard Stolberg wrote in the AtariAge forums on February 1, 2007, the CommaVid scheme has the following format:

$1000 through $13FF (or $F000 through $F3FF) = the read addresses for the 1K of extra RAM
$1400 through $17FF (or $F400 through $F7FF) = the write addresses for the 1K of extra RAM
$1800 through $1FFF (or $F800 through $FFFF) = 2K of ROM

Michael

You may also find it useful to look at the Cart header files from the source code in Stella, as they often have a description of how the BS scheme works. I just checked CartCV.hxx, and it does indeed say exactly the same as above (which isn't surprising, since Eckhard wrote that particular class for Stella!).

[Wickeycolumbus]

I added EF and EFSC demos. Stella users, please note that the current version of Stella does not emulate the EF scheme. Stephena has implemented it and it will be present in a future version

SeaGtGruff, on Sun Apr 5, 2009 10:04 AM, said:

According to what I just found by Googling, CommaVid didn't use any bankswitching schemes per se. However, you will see a "CV" method listed among the available bankswitching schemes of most Atari 2600 emulators and programmable carts (e.g., the Cuttle Cart, the Cuttle Cart 2, and the Krokodile Cartridge) because at least one of their games-- "Video Life"-- did use an alternate cartridge scheme. It's still just a 4K cart, but it has 2K of ROM and an extra 1K of RAM. Back then they didn't have supercat's "magic writes" for extra RAM, so any extra RAM had to use up twice as much memory space as the actual RAM chip size-- e.g., 128 bytes of extra RAM (as in Atari's Superchip) actually used up 256 bytes of memory space, and 256 bytes of extra RAM (as in some of CBS's carts) actually used up 512 bytes of memory space. That's because the extra RAM had to be read through one set of addresses, and written to through another set of addresses. So CommaVid's 1K of extra RAM actually used up 2K of memory space. Based on what Eckhard Stolberg wrote in the AtariAge forums on February 1, 2007, the CommaVid scheme has the following format:

$1000 through $13FF (or $F000 through $F3FF) = the read addresses for the 1K of extra RAM
$1400 through $17FF (or $F400 through $F7FF) = the write addresses for the 1K of extra RAM
$1800 through $1FFF (or $F800 through $FFFF) = 2K of ROM

Michael

Thank you for the info, wow, 2K ROM and 1K RAM... seems like overkill!

stephena, on Sun Apr 5, 2009 10:14 AM, said:

SeaGtGruff, on Sun Apr 5, 2009 10:34 AM, said:

Wickeycolumbus, on Sun Apr 5, 2009 2:14 AM, said:

does anyone have any info on the CommaVid (CV) scheme?

According to what I just found by Googling, CommaVid didn't use any bankswitching schemes per se. However, you will see a "CV" method listed among the available bankswitching schemes of most Atari 2600 emulators and programmable carts (e.g., the Cuttle Cart, the Cuttle Cart 2, and the Krokodile Cartridge) because at least one of their games-- "Video Life"-- did use an alternate cartridge scheme. It's still just a 4K cart, but it has 2K of ROM and an extra 1K of RAM. Back then they didn't have supercat's "magic writes" for extra RAM, so any extra RAM had to use up twice as much memory space as the actual RAM chip size-- e.g., 128 bytes of extra RAM (as in Atari's Superchip) actually used up 256 bytes of memory space, and 256 bytes of extra RAM (as in some of CBS's carts) actually used up 512 bytes of memory space. That's because the extra RAM had to be read through one set of addresses, and written to through another set of addresses. So CommaVid's 1K of extra RAM actually used up 2K of memory space. Based on what Eckhard Stolberg wrote in the AtariAge forums on February 1, 2007, the CommaVid scheme has the following format:

$1000 through $13FF (or $F000 through $F3FF) = the read addresses for the 1K of extra RAM
$1400 through $17FF (or $F400 through $F7FF) = the write addresses for the 1K of extra RAM
$1800 through $1FFF (or $F800 through $FFFF) = 2K of ROM

Michael

You may also find it useful to look at the Cart header files from the source code in Stella, as they often have a description of how the BS scheme works. I just checked CartCV.hxx, and it does indeed say exactly the same as above (which isn't surprising, since Eckhard wrote that particular class for Stella!).

I will have to download the source, thanks for the tip!

Attached Files

•  Bankswitching_3.zip   20.33K   107 downloads

[selgus]

Wickeycolumbus, on Sun Apr 5, 2009 8:10 PM, said:

Thank you for the info, wow, 2K ROM and 1K RAM... seems like overkill!

I'm working on a 2600 game now that will be using a minimum of 1K of RAM in the cartridge, as it will have to have a custom banking scheme. Banking in ROM in small windows is very doable if you can have a large block of RAM around too.
--Selgus

[GroovyBee]

selgus, on Mon Apr 6, 2009 1:18 AM, said:

I'm working on a 2600 game now that will be using a minimum of 1K of RAM in the cartridge, as it will have to have a custom banking scheme. Banking in ROM in small windows is very doable if you can have a large block of RAM around too.

What about using M-Network's E7 bankswitching? That allows 2K of banked RAM and 16K of banked ROM (2K is fixed).

[selgus]

GroovyBee, on Sun Apr 5, 2009 8:38 PM, said:

What about using M-Network's E7 bankswitching? That allows 2K of banked RAM and 16K of banked ROM (2K is fixed).

It looks like the E7 banking scheme deals with 1K RAM filling 2K of address space for read/write (similar to what I will be doing), but the second 1K RAM is banked in 256b blocks on-top of the 2K fixed ROM. Not exactly sure how that works, but it seems to mean only the last 2K of ROM can do anything with that on-cart RAM.

My game is going to be doing 1.5K of RAM (taking 3K of address space) and a 1K ROM banked window.
--Selgus

[SeaGtGruff]

selgus, on Sun Apr 5, 2009 8:00 PM, said:

GroovyBee, on Sun Apr 5, 2009 8:38 PM, said:

What about using M-Network's E7 bankswitching? That allows 2K of banked RAM and 16K of banked ROM (2K is fixed).

It looks like the E7 banking scheme deals with 1K RAM filling 2K of address space for read/write (similar to what I will be doing), but the second 1K RAM is banked in 256b blocks on-top of the 2K fixed ROM. Not exactly sure how that works, but it seems to mean only the last 2K of ROM can do anything with that on-cart RAM.

My game is going to be doing 1.5K of RAM (taking 3K of address space) and a 1K ROM banked window.
--Selgus

M-Network has 1K of extra RAM that goes at $1000-$1377 (write) and $1400-$17FF (read). That area ($1000-$17FF) is also used to select between different 2K banks of ROM.

The other 1K of extra RAM is divided into four 256-byte banks that go at $1800-$18FF (write) and $1900-$19FF (read).

The last area, $1A00-$1FFF, is used for 1.5K of fixed ROM.

It's true that the lower ROM banks at $1000-$17FF can't *directly* access the 1K extra RAM at $1000-$13FF/$1400-$17FF, but they can access the extra RAM at $1800-$18FF/$1900-$19FF.

Also, if you put subroutines in the 1.5K fixed ROM area, then your code in the lower ROM banks can *indirectly* access the 1K extra RAM at the same bank region, by JSRing to the fixed ROM to read/write the RAM (using the registers, the zero-page RAM, or the 256-byte extra RAM to pass any parameters or data), then RTS back to the banked ROM.

And you can copy ROM data from the banked ROM into the 1K RAM area, switching back and forth (from within the fixed ROM) as you read the banked ROM and write it to RAM.

Michael

Edited by SeaGtGruff, Mon Apr 6, 2009 6:24 AM.

[selgus]

SeaGtGruff, on Mon Apr 6, 2009 7:23 AM, said:

M-Network has 1K of extra RAM that goes at $1000-$1377 (write) and $1400-$17FF (read). That area ($1000-$17FF) is also used to select between different 2K banks of ROM.

The other 1K of extra RAM is divided into four 256-byte banks that go at $1800-$18FF (write) and $1900-$19FF (read).

The last area, $1A00-$1FFF, is used for 1.5K of fixed ROM.

It's true that the lower ROM banks at $1000-$17FF can't *directly* access the 1K extra RAM at $1000-$13FF/$1400-$17FF, but they can access the extra RAM at $1800-$18FF/$1900-$19FF.

Also, if you put subroutines in the 1.5K fixed ROM area, then your code in the lower ROM banks can *indirectly* access the 1K extra RAM at the same bank region, by JSRing to the fixed ROM to read/write the RAM (using the registers, the zero-page RAM, or the 256-byte extra RAM to pass any parameters or data), then RTS back to the banked ROM.

And you can copy ROM data from the banked ROM into the 1K RAM area, switching back and forth (from within the fixed ROM) as you read the banked ROM and write it to RAM.

Thanks, the missing part I didn't know about was M-Network's scheme used 1.5K of ROM in that upper address, not 2K.

I can see how this scheme could work on many games, it doesn't really lend itself to what I am working on. There is quite a bit of ROM and it needs access to a large chunk of RAM at a time. It seems to me like a lot of work and wasted cycles trying to make this scheme function.

Actually right now I am calculating the exact distribution of ROM and RAM in the address space, and will probably bump down the RAM to 1K per bank.

But this is OT from the bankswitching templates, so I will continue this elsewhere.
--Selgus

[SeaGtGruff]

selgus, on Mon Apr 6, 2009 9:17 AM, said:

Thanks, the missing part I didn't know about was M-Network's scheme used 1.5K of ROM in that upper address, not 2K.

The 256-bytes of extra RAM that begins at $1800, and uses up 512 bytes or 0.5K, which leaves only 1.5K in the fixed ROM area. I wish they'd had a way to switch the $1800-$19FF bank area between the four 256-byte RAM banks or that missing 512-bytes of ROM, but they didn't.

selgus, on Mon Apr 6, 2009 9:17 AM, said:

I can see how this scheme could work on many games, it doesn't really lend itself to what I am working on. There is quite a bit of ROM and it needs access to a large chunk of RAM at a time. It seems to me like a lot of work and wasted cycles trying to make this scheme function.

It really isn't that bad to access the extra RAM. Yes, it takes some extra cycles if you want to access the main 1K of RAM from the 2K ROM banks, but not if you're accessing the little RAM banks.

The 1K RAM bank is good for something that needs a lot of RAM, such as a "hi-res bitmap" for an asymmetrical playfield (hi-res in the vertical direction, not in the horizontal direction). It takes 5 bytes to store one line of asymmetrical playfield pixels, assuming you're using PF0 and are packing both copies of PF0 into a single byte. With 1024 bytes of RAM, that's enough for 204 scan lines, and most games will devote 192 or fewer scan lines to the playfield. Of course, you could use a non-asymmetrical playfield, which would free half of that RAM for sprites and such.

This is assuming that you want to read the playfield and sprite data from some fixed RAM addresses so you can use fewer cycles to read it in your kernel. In other words, you can use something like LDA $1234,X instead of LDA ($89),Y. And if you store your sprites as a tall shape-- similar to the way P/M graphics are done on an Atari 800-- then you can just read the sprite data and draw the sprite on every line, instead of having to use something like "skip draw" to figure out whether or not you should be drawing the sprite on the current line.

Michael

[selgus]

Does someone have a M-Network RAM/ROM bankswitching template out there? Would be interesting to see how it was used.
--Selgus

[Wickeycolumbus]

selgus, on Wed Apr 8, 2009 8:51 AM, said:

Does someone have a M-Network RAM/ROM bankswitching template out there? Would be interesting to see how it was used.
--Selgus

I will post one tomorrow

[Wickeycolumbus]

As promised, the package now includes an E7 template. I could not get the second 1K block of RAM (the one divided into 256b sections) to work for some reason though...

Attached Files

•  Bankswitching_4.zip   21.79K   93 downloads

[stephena]

Wickeycolumbus, on Fri Apr 10, 2009 12:01 AM, said:

As promised, the package now includes an E7 template. I could not get the second 1K block of RAM (the one divided into 256b sections) to work for some reason though...

I've updated Stella to better detect 'E7' scheme. It now picks up the one you've provided, as well as several other test ROMs I had here as well. I still have to work on the 0840 and SB formats.

[selgus]

stephena, on Fri Apr 10, 2009 10:10 AM, said:

Wickeycolumbus, on Fri Apr 10, 2009 12:01 AM, said:

As promised, the package now includes an E7 template. I could not get the second 1K block of RAM (the one divided into 256b sections) to work for some reason though...

I've updated Stella to better detect 'E7' scheme. It now picks up the one you've provided, as well as several other test ROMs I had here as well. I still have to work on the 0840 and SB formats.

Do you have an ETA when that version of Stella will be released with the new 'E7' support? Thanks.
--Selgus

[stephena]

selgus, on Fri Apr 10, 2009 11:45 AM, said:

stephena, on Fri Apr 10, 2009 10:10 AM, said:

Wickeycolumbus, on Fri Apr 10, 2009 12:01 AM, said:

As promised, the package now includes an E7 template. I could not get the second 1K block of RAM (the one divided into 256b sections) to work for some reason though...

I've updated Stella to better detect 'E7' scheme. It now picks up the one you've provided, as well as several other test ROMs I had here as well. I still have to work on the 0840 and SB formats.

Do you have an ETA when that version of Stella will be released with the new 'E7' support? Thanks.
--Selgus

I assume you mean the new 'EF' support (as 'E7' has been present for quite some time). I guess I can do a quick point release for this, probably by the end of next week. If possible, I'd like to get autodetection for 0840 and SB working first.

[stephena]

selgus, on Fri Apr 10, 2009 11:45 AM, said:

stephena, on Fri Apr 10, 2009 10:10 AM, said:

Wickeycolumbus, on Fri Apr 10, 2009 12:01 AM, said:

As promised, the package now includes an E7 template. I could not get the second 1K block of RAM (the one divided into 256b sections) to work for some reason though...

I've updated Stella to better detect 'E7' scheme. It now picks up the one you've provided, as well as several other test ROMs I had here as well. I still have to work on the 0840 and SB formats.

Do you have an ETA when that version of Stella will be released with the new 'E7' support? Thanks.
--Selgus

Stella 2.7.6 was just released, which includes support for 'EF' and 'EFSC' (as mentioned in this thread). Also, autodetection was improved for '0840', 'SB' and 'UA' formats. All test ROMs in the zip file above are now supported and autodetected.

[selgus]

stephena, on Wed Apr 15, 2009 7:25 AM, said:

Stella 2.7.6 was just released, which includes support for 'EF' and 'EFSC' (as mentioned in this thread). Also, autodetection was improved for '0840', 'SB' and 'UA' formats. All test ROMs in the zip file above are now supported and autodetected.

Wonderful, thanks! I will probably use one of these new bankswitching modes to develop my game until I fine-tune my new banking scheme with extra memory.
--Selgus

[grafixbmp]

what are some good places that I can find some info about f4sc bankswitching? and any places to order boards as well?

[Wickeycolumbus]

grafixbmp, on Tue Apr 28, 2009 5:06 PM, said:

what are some good places that I can find some info about f4sc bankswitching? and any places to order boards as well?

To my knowledge, it is the same as F4 (8 hotspots from $1FF4-$1FFB), but there is an extra 128 bytes of RAM mapped from $1000-$107F for writes, and $1080-$10FF for reads, but for some reason, I could never make a working demo for this scheme.

I believe CPUWIZ still has SARA boards in stock.

Edited by Wickeycolumbus, Tue Apr 28, 2009 6:18 PM.

[Mord]

Wickeycolumbus, on Tue Apr 28, 2009 8:14 PM, said:

grafixbmp, on Tue Apr 28, 2009 5:06 PM, said:

what are some good places that I can find some info about f4sc bankswitching? and any places to order boards as well?

To my knowledge, it is the same as F4 (8 hotspots from $1FF4-$1FFB), but there is an extra 128 bytes of RAM mapped from $1000-$107F for writes, and $1080-$10FF for reads, but for some reason, I could never make a working demo for this scheme.

That's essentially all it is yeah. What problems did you have with making the demo? I'm going to assume it was intended to just to the same flashing bars on the non-SCed version of F4 (like how F6 & F6SC were similar)