Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
  • entries
    62
  • comments
    464
  • views
    86,882

Proposed "Magic Zeepy" banking method

supercat

Entry posted by supercat

828 views

 Share

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?

 Share

5 Comments

Recommended Comments

mos6507

Sounds similar to something we were thinking about attempting for Chimera, which is the "nobanking" thing, where a 2600 program can only run 4K of code at once but can read and write to 32K at a time, separated by 4K gaps. So you'd decide whatever you want to be in your 4K execution window and which 32K half would be in the data window. It seemed useful other than the annoying 4K gaps.

Link to comment
supercat
Sounds similar to something we were thinking about attempting for Chimera, which is the "nobanking" thing, where a 2600 program can only run 4K of code at once but can read and write to 32K at a time, separated by 4K gaps. So you'd decide whatever you want to be in your 4K execution window and which 32K half would be in the data window. It seemed useful other than the annoying 4K gaps.

 

Some similarity in concept, but huge difference in execution. Chimera requires some pretty fancy stuff. The "Magic Zeepy" banking scheme could work in a 22V10 (it would be nicer if I either had another macrocell, or could manage 24 product terms in one, but such is life). To be sure, Chimera could probably access the whole 4K out of each bank instead of being limited to 3K, but being able to access 24K directly would still be pretty cool.

Link to comment
batari

I like the idea, but it would be much better if all 4k of the data banks were available. Is this possible, even though it may have limitations elsewhere?

Link to comment
supercat
I like the idea, but it would be much better if all 4k of the data banks were available. Is this possible, even though it may have limitations elsewhere?

 

The reason for having only 3K be addressable via the pointer is to ensure that code in the top 1K of address space won't get "yanked out" under the CPU. If there were only 1K of code that ever wanted to access certain banks of data, that code could simply be replicated in all such banks, but that would be pretty confining. Splitting the address space avoids that issue, though I've got an even cooler idea if it's acceptable to go to an ATF750 . . .

Link to comment
supercat

Alternative proposal, if something a little fancier than a 22V10 is acceptable (the Atmel ATF750 is a 24-pin DIP with 20 macrocells instead of 10).

 

Wild and Zeepy Banking

 

The basic concept would be to have a four-bit banking register for the top 1K and one for the lower 3K, along with a "Wild and Zeepy" mode bit.

 

When "Wild and Zeepy" mode is turned off, everything would work pretty much normally; some addresses in the range $0400-$0FFF would be used for bank switching.

 

With "Wild and Zeepy" mode turned on, any access in the top 1K of address space would copy D5-D7 to three bits of the lower bank select and set the fourth. Zero-page accesses $C0-$FF would do likewise. Zero-page accesses $80-$BF would copy D5-D7 to three bits of the lower bank select and clear the fourth.

 

The net effect of this is that while one would want to avoid running code from $1000-$1BFF while "Wild and Zeepy" mode was active, 24K of ROM would be accessible via abs,x or abs,y addressing, or by (ZP),Y addressing with pointers in the second half of RAM, and a different 24K would be accessible via (ZP),y addressing with pointers in the first half of RAM. An alternative arrangement would be to make the zero-page areas be $A0-$BF and $80-$9F, with the other areas of zero-page not having such effects. That would allow code to run in $1000-$1BFF provided it didn't touch those areas of RAM. Note that in that case one could JSR or JMP directly from code in the $1C00-$1FFF range into 24K worth of code in the lower range.

 

Perhaps it would be nice to have separate enables for the auto-banking in the $1C00-$1FFF and zero-page regions (so that subroutines in the lower banking region could manipulate pointers). Trying to take advantage of direct JMP/JSR's would likely result in considerable confusion, however, so such notions might be best avoided.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...