79 replies to this topic

[batari]

Wickeycolumbus, on Mon Jun 15, 2009 2:23 PM, said:

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]

batari, on Fri Aug 14, 2009 2:16 PM, said:

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).

batari, on Fri Aug 14, 2009 2:16 PM, said:

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 by SeaGtGruff, Fri Aug 14, 2009 1:52 PM.

[batari]

SeaGtGruff, on Fri Aug 14, 2009 2:49 PM, said:

batari, on Fri Aug 14, 2009 2:16 PM, said:

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).

batari, on Fri Aug 14, 2009 2:16 PM, said:

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.

Attached Files

•  Bankswitching 9.zip   36.66K   95 downloads

[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