Bankswitching Demos/Templates

[+batari]

Assuming the problem is not on my end (I will look at my code again), is there any chance MC support can be fixed? It looks really promising with it's 128K ROM and 32K RAM.

I looked into the specs - it's similar to 3E in that it maps ROM or RAM by writes to zero page addresses, and also similar to E0 in that it uses 1k blocks but there is no fixed bank except on boot. You can switch any bank into any block. Still, 4A50 is far superior and requires about the same amount of hardware to achieve.

 

The problem with these RAM schemes is that the creators aren't willing to produce hardware until a game exists, and programmers aren't willing to write a game for hardware that doesn't exist in large enough quantities and for a reasonable price. Hopefully, the Harmony/Melody will break through this barrier.

[SeaGtGruff]

The problem with these RAM schemes is that the creators aren't willing to produce hardware until a game exists, and programmers aren't willing to write a game for hardware that doesn't exist in large enough quantities and for a reasonable price.

I still plan to create a game or two for the 4A50 scheme, even if it will only ever be playable on emulators. I'm hoping if (or once) I ever get a 4A50 game finished, supercat will still be interested in creating carts (and able to).

 

Hopefully, the Harmony/Melody will break through this barrier.

Are there developer's programming specs for the Harmony/Melody cart format? How much ROM and RAM will it have, and what are the bank areas and how to select them? From what little discussion I've followed about it, I presume it will be able to emulate existing bankswitching schemes, like E7, F6, F4SC, etc. But would a developer control all of that, and create a game that made maximum use of all available ROM and all available RAM?

 

Michael

Edited August 14, 2009 by SeaGtGruff

[+batari]

The problem with these RAM schemes is that the creators aren't willing to produce hardware until a game exists, and programmers aren't willing to write a game for hardware that doesn't exist in large enough quantities and for a reasonable price.

I still plan to create a game or two for the 4A50 scheme, even if it will only ever be playable on emulators. I'm hoping if (or once) I ever get a 4A50 game finished, supercat will still be interested in creating carts (and able to).

 

Hopefully, the Harmony/Melody will break through this barrier.

Are there developer's programming specs for the Harmony/Melody cart format? How much ROM and RAM will it have, and what are the bank areas and how to select them? From what little discussion I've followed about it, I presume it will be able to emulate existing bankswitching schemes, like E7, F6, F4SC, etc. But would a developer control all of that, and create a game that made maximum use of all available ROM and all available RAM?

 

Michael

The Melody/Harmony doesn't have "bank areas" or "programming specs" per se. It's not conventional hardware with fixed logic - it's a 70 MHz, 32-bit microcontroller with 32k ROM/8k RAM, and a developer could use the existing bankswitching schemes or invent new ones. Or, a developer could use an existing scheme along with a C stub and write custom C code on the microcontroller that controls game logic.

 

That said, I do plan a new "bankswitching" scheme (which is really a sort of graphics coprocessing scheme) that feeds a custom kernel to the 6507 on the fly with data read from a display list.

[Wickeycolumbus]

CommaVid added.

Bankswitching 9.zip

[Willsy]

Interesting topic - I'm a TI99er so please forgive my trespassing

 

Wondering what techniques the Atari guys are using for bankswitching?

 

Of course, the problem is that when you switch banks, your code is suddenly somewhere else.

 

There seems to be two soloutions on the TI, as suggested by Tursi:

 

1) Have some common code in scratch-pad ram (the 256 byte ram built into the TI console) - this will take two arguments:

a) The bank to select

b) The address in the new bank to switch to

 

This neatly gets around the problem.

 

2) Have duplicated code, (for example, the top 1K) in each bank, with similar code to 1) above.

 

Is this similar to the Atari way?

 

Thanks

 

Mark

[zilog_z80a]

Hi!! is there an UPDATED list with Bankswitching codes"name" and specs that i can read to learn?

 

i mean ¿something like Kevin Horton's list format? :

CODE: (3F)
NAME: (Enhanced Tigervision style)

SPECS: (up to 512K)

 

cheers!!

 

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

 

UPDATE: I HAVE FOUND THIS WITH DATE 2012

EXIST IN SOME OTHER PLACE A RECENT ONE?

 

http://blog.kevtris.org/blogfiles/Atari%202600%20Mappers.txt

Edited February 26, 2018 by zilog_z80a

[+stephena]

The most up-to-date documentation will come from looking at the header files (ending in .hxx) in Stella that are named CartXXX (where 'XXX' is bankswitch scheme). These names match the bankswitching naming scheme, and provide a wealth of information on how they work.

[zilog_z80a]

The most up-to-date documentation will come from looking at the header files (ending in .hxx) in Stella that are named CartXXX (where 'XXX' is bankswitch scheme). These names match the bankswitching naming scheme, and provide a wealth of information on how they work.

 

ty stephena!! very nice info!!

 

cheers.