No-Frills Bankswitching

[vcsrocks]

Hi everybody,

 

Talking to a homebrewer here at AtariAge the topic of large ROMs (128KB+) came up.  One part of the bankswitching schemes which always put me off is the amount of memory used by routing overhead and the hotspots.  Yes, I know that in the great scheme of things that may end up being negligible, but the whole point of using bankswiting is to have more memory available and large ROMs require a larger number of hotspots

 

So I was thinking if a trade off with RAM could be acceptable, why not have a hotspot in RAM and bankswitch according to the value saved in that hotspot.

 

The idea is that a write to that specific address would trigger the bankswitch.  A read to that address would not do anything as the bank is already selected.

 

Using a full byte in RAM, the cart could have 1MB of ROM available (256 * 4096).

 

Coding would be as simple as loading the accumulator with the desired bank number and storing it into the hotspot address in RAM.

 

With one additional RAM byte, the BS routine could route a call to 256 distinct subroutines in the new bank (see diagram below).

 

And a relatively simple one-size-fits-all solution could be created by using another RAM byte and a single dispatch sub-routine:

 

 

 

Does anything like this exist already?  Would it make sense to use it for very large ROMs?

 

[+bcombee]

One of the problems is that the R/W line used by the processor isn't available on the cartridge port.  So the hardware doing the bankswitching can't tell if it's a read or write.  That's why they have different addresses decode as read-only or write-only. See https://old.pinouts.ru/Motherboard/AtariCartridge_pinout.shtml.

 

Hmmm, reading your post again, its unclear to me where you want the RAM-based hotspot to be.  Are you treating one of the ROM-address space memory locations as a bank register for this?

[vcsrocks]

42 minutes ago, bcombee said:

One of the problems is that the R/W line used by the processor isn't available on the cartridge port.  So the hardware doing the bankswitching can't tell if it's a read or write.  That's why they have different addresses decode as read-only or write-only. See https://old.pinouts.ru/Motherboard/AtariCartridge_pinout.shtml.

 

Hmmm, reading your post again, its unclear to me where you want the RAM-based hotspot to be.  Are you treating one of the ROM-address space memory locations as a bank register for this?

Hi bcombee.  I know what you mean, but this BS is for ROM only, so the lack of R/W is not an issue.

 

Whenever the CPU access RAM (addresses 0x80-0xFF) the cart "sees" this access as it gets the full data and address buses.

 

To access the ROM, the CPU uses addresses 0x1000-0x1FFF effectively using A12 as chip select.  For RAM access, A12 is low so a normal cart inverts this line and presents it to the ROM OE or CE ports.  This effectively puts the data lines of the cart in high impedance.

 

A low A12 allows the CPU, RIOT or TIA to take over the data bus, depending on the address being accessed and the R/W line, but the cart still receives all signals so RAM access can still be used by the BS logic to trigger the page selection.

 

As for the access to the RAM itself, at the end it does not matter if the CPU is executing a read or a write.  What matters is what is in the address and data lines.  If the data lines are driven by the CPU or by the RIOT makes no difference.

 

The real use case would be anyway to execute a write first (as it would not make much sense to read before something is stored in the hotspot), but again, it should not matter.

 

Last but not least, the RAM hotspot can be any address in the range 0x80-0xFF, although 0x80 would probably make more sense because of the stack.  As soon as the BS sees an access to address X (0x80 for the sake of argument) it will set the ROM page to whatever value is in the data lines.

[+splendidnut]

Have you looked at the 3F and 3E bankswitching schemes?  I believe they use zeropage locations (not ROM space) to do bankswitching.

[vcsrocks]

On 9/13/2019 at 11:02 PM, splendidnut said:

Have you looked at the 3F and 3E bankswitching schemes?  I believe they use zeropage locations (not ROM space) to do bankswitching.

Very good point!

 

But they switch only half the ROM space, so there is a maximum of 512KB possible.

 

One good thing about the Tigervision scheme is that it uses a hotspot in the TIA space, which saves the RAM byte.  If one byte in the ROM was to be used as indication of the current bank, no RAM would be required at all.

 

The question really is, would anyone ever need 1MB for a VCS game...

[Kroko]

I doubt that anybody would ever need more than 512 MB on a 2600, but ...

 

How about a 16-bit bank number ? 256 * 256 banks (2K per bank) => About 130 GB of ROM space ...

3F write bank-number lo-byte
XX write bank-number hi-byte

XX may be another unused hotspot from TIA space

 

[+Andrew Davie]

31 minutes ago, Kroko said:

How about a 16-bit bank number ? 256 * 256 banks (2K per bank) => About 130 GB of ROM space ...

 

I think it makes 128 MB!

 

[+Andrew Davie]

8 hours ago, vcsrocks said:

But they switch only half the ROM space, so there is a maximum of 512MB possible.

 

 

256 x 2K banks = 512K - out by a factor of 1000 

[+Andrew Davie]

On 9/13/2019 at 8:45 PM, vcsrocks said:

 

Using a full byte in RAM, the cart could have 1GB of ROM available (256 * 4096).

 

 

That would be 1MB, not 1GB.

[Kroko]

Sure you are right:  it is 130 MB of level definitions for Sokoboo

 

 

 

[vcsrocks]

On 9/17/2019 at 12:32 AM, Andrew Davie said:

 

That would be 1MB, not 1GB.

Silly mistake.  Thanks.