2600 in 2006 - Proposed "Magic Zeepy" banking method

[RSS Bot]

Magic Zeepy banking is a proposed banking method to allow up to 32 zero-page pointers used within certain parts of the code to access up to 24K of ROM directly. It does put some restrictions on the code to be run, but for some applications the ability to access so much memory directly may be more than worth it. The scheme is designed around using a 22V10 as a controller; this entailed some slight compromises, but the scheme should nonetheless be very powerful. The board layout would have to be different from Albert's current cart, but the assembly procedure would be the same. The Zeepy chip would support up to 64Kbytes of ROM.

 

The 64K of ROM space is divided into two 32K sections of eight 4K banks. One banking control bit is used to select between the two sections; code running within a section may access data only within that section (code in the first section may access 24K of data in that section; code in the second section gets 24K of data in that section).

 

The eight banks in a section are selected using a 3-bit "primary bank register" and a 3-bit "temporary bank register".

 

Any access in the range $1C00-$1FFF will copy the primary bank register to the temporary bank register and use it for the access.

 

Any access in the range $1000-$1BFF will use the temporary bank register for the access (ignoring the primary bank register).

 

Any access to $0FnF (or more precisely 011xxnnnn1xxx) will select bank 'n' immediately (loading the section-select bit along with both temporary and primary registers).

 

Any access to $07nF (or more precisely 001xxxnnn1xxx) will load the primary bank select register with 'n'. This will not actually switch banks until the next access in the $1C00-$1FFF range. This will ease jumps between banks when jump target is in the $1C00-$1FFF range.

 

When bank 0-3 is selected via the primary register, any access in the range $80-$BF will load the temporary bank register with DATA bits 5-7. This would primarily be useful when performing (zp,y) addressing. In that case, the bank number would get latched with the normally-ignored upper address bits stored in the pointer.

 

If code is running from address $1C00-$1FFF, the only effect of a change to the temporary bank register will be to affect a memory access that occurrs between the change and the next instruction fetch. Most notably, the data fetched by a "lda (zp),y" or similar instruction.

 

The net effect of all of this would be to allow 4K of code within each 32K section to access 24K of data within that section with minimal overhead.

 

Thus, simple code like:

  lda (pf1a),y
 sta PF1
 lda (pf2a),y
 sta PF2
 lda (grp0p),y
 sta GRP0
 lda (pf2b),y
 sta PF2
 lda (pf1b),y
 sta PF1
 lda (grp1p),y
 sta GRP1

would be able to access up to 24K of playfield and sprite data without any 'manual' bank switching, and the bank for each pointer could be independently selected.

 

Any thoughts?

 

http://www.atariage.com/forums/index.php?a...;showentry=4443