REQUEST: Support for 6k Supercharger Roms

[Primordial Ooze]

I think the next build of Batari BASIC should have and option to allow you to make 6k Supercharger rom games. I understand the supercharger uses 3 2k ram banks and it needs to be individually banked from and to. I also know the atari can only address 4k of ram at a time. What i don't understand is how come when i write a 4k game i don't need to bank between two banks (2k + 2k) but for 6k you need to bank? Does the supercharger automatically split your game into 2 2k pieces? I think this would make a great feature as well as allow people who have a supercharger use it's full potential.

 

2600 Hero

[Nukey Shay]

The 2600 console can natively address 8k of memory...as dictated by bits 12 to 0 in a 16-bit address. The 12th bit determines if the address relates to RAM or ROM. The reason that 4k roms work as-is in the Supercharger is that nothing is being bankswitched (unless the program indirectly attempts to do so...crashing the program).

 

By itself, the console has no provision for bankswitching. When bit 12 is off, a 16-bit address relates to RAM. When it's on, it pertains to ROM. Bits 15, 14, and 13 have no effect due to the 6507's hobbled address line, so the remainder of the bits only have the ability to call upon a maximum of 4k of space in either memory. An important thing to note is that memory which is not physically present is just "shadows" of memory that is (writing to $2080 has the same effect as writing to $0080...tho cycle time may vary depending on the instruction's "addressing mode"). One could advertise the 2600 console as having 4k of RAM and 4k of ROM...but neither is really true. The console only has a small portion of RAM physically present...and ROM programs are external.

 

Programs and data that are stored on cartridge ROMs cannot be altered...hence "Read-Only Memory". The Supercharger, however, uses it's own three 2k blocks of RAM (Random-Access Memory) to place a loaded program into memory. NOTE: I'll refer to Supercharger addressing as "ROM" here for the sake of explaination. As far as the console knows, it is ROM. Anyway...the unit monitors a couple of addresses to determine if the following operation is read or write to this memory, and if the alternate 2k bank should be accessed.

 

Concerning the latter, it's like a house on a lot with only one parking space for 2 vehicles. The "house" is the second 2k of "ROM" memory...which occupies addresses $1800 to $1FFF (the "lot"). This 2k block is always present regardless of bankswitch flip status. The other two 2k "vehicle" portions of "ROM" memory occupies addresses $1000 to $17FF (the "parking space"). Just by updating the monitored memory locations, the unit can choose between either of the latter 2k blocks (or "vehicles"). This is why some unaltered cartridge programs will crash the unit. The monitored locations are ROM addresses as far as the 2600 knows, so calling them could cause the Supercharger unit to swap to the other 2k "vehicle". Because nothing exists in that 2k block when loading a 2k or 4k cartridge ROM, the program cannot proceed. Just a house with an empty parking space...whatever was in the parking spot had been moved out into the street Alternately, the monitored locations could instruct the unit to perform a write operation to following memory addresses that are mentioned by the program...overwriting itself. This ability is what makes programs designed for the Supercharger to be so versitile...the program can modify itself to meet any condition it needs, well before it needs it. Just as easily as if you bought a new knick-knack for your home or vehicle. The program is held in the unit's RAM memory, so nothing is there to prevent it.

 

The mentioned problems can be fixed by physically modifying the unit itself...by adding a switch that the user can turn on or off at will. When flipped on, the unit ignores any attempt to change the status of those monitored locations...rendering the unit incapable of writing to or swapping it's memory blocks.

 

 

As far as adding support to bB goes...it might be a little beyond the reach of what bB was designed for. Self-modification tends to get a bit messy (in more ways than one). Precise byte counts for modifications to existing routines, for example. But standard bankswitching schemes are already supported for programs that require more than 4k...and Superchip is also supported for those that require added RAM). And because such 6k programs are (currently) not possible to convert to an actual cartridge program, support might be more trouble than it's worth.

 

Conclusion: If you can keep track of your program that well already to implement self-modification, you'd be better off just doing it in straight .asm where you have full control over it (and the console's native resources...which become much more limited when using bB's canned routines)

Edited January 15, 2009 by Nukey Shay