SRAM mapping & LoROM question

[Charles MacDonald]

I'm working on a RAM-based development cartridge and want to support the most common SRAM mappings. Currently I'm trying to wrap my head around it all.

LoROM games have SRAM mapped at banks 70-7D and mirrored at F0-FF. If there is more than 32K of SRAM present, is A15 used (so that it e.g. spans bank 7x:0000-FFFF) or not, so that each bank has 32K of SRAM at 7x:0000-7FFF, with 8000-FFFF being a mirror of the lower 32K of that bank?

Does Dezaemon (LoROM with 128K SRAM) do anything differently from this? I'm assuming the 128K RAM is divided into 32K chunks across banks 70-73 at offsets 0000-7FFF for instance.

For HiROM games, SRAM is at banks 20-2F and mirrored at A0-AF at offsets 6000-7FFF in each bank. Are there any notable exceptions to that arrangement?

I'm not totally clear on how LoROM games with >2MB ROM work, such as Super Metroid. Can anyone explain that? Is it just a matter of using A23 such that banks 00-3F and 80-BF aren't mirrors, so you have two distinct 2MB regions for up to 4MB total?

[tepples]

Super Metroid is 24 Mbit. As I understand it, a 24 Mbit LoROM will have one ROM mapped at $008000-$3FFFFF and another at $408000-$5FFFFF.

[koitsu]

LoROM games have SRAM mapped at banks 70-7D and mirrored at F0-FF. If there is more than 32K of SRAM present, is A15 used (so that it e.g. spans bank 7x:0000-FFFF) or not, so that each bank has 32K of SRAM at 7x:0000-7FFF, with 8000-FFFF being a mirror of the lower 32K of that bank?

No. Please see this diagram:

download/file.php?id=731&mode=view

With mode 20 (what you call "lorom"), SRAM is mapped within the 65816 address space between addresses $0000-7fff within banks $70-7d. This means you're limited to $8000*14 = 458,752 bytes for SRAM. Addresses $8000-ffff within banks $70-7d are not related to SRAM (they're mirrors of program ROM).

Written more clearly:

$700000 to $707fff = SRAM
$708000 to $70ffff = Program ROM
$710000 to $717fff = SRAM
$718000 to $71ffff = Program ROM
...
$7d0000 to $7d7fff = SRAM
$7d8000 to $7dffff = Program ROM

Does Dezaemon (LoROM with 128K SRAM) do anything differently from this? I'm assuming the 128K RAM is divided into 32K chunks across banks 70-73 at offsets 0000-7FFF for instance.

This sounds correct to me (and differs from your earlier description).

For HiROM games, SRAM is at banks 20-2F and mirrored at A0-AF at offsets 6000-7FFF in each bank. Are there any notable exceptions to that arrangement?

No. Please see this diagram:

download/file.php?id=732&mode=view

With mode 21 (what you call "hirom"), SRAM is mapped within the 65816 address space between addresses $6000-8000 within banks $30-3f. This is also mirrored at addresses $6000-8000 within banks $80-8f. This means you're limited to $2000*16 = 131,072 bytes (128KBytes) for SRAM.

I'm not totally clear on how LoROM games with >2MB ROM work, such as Super Metroid. Can anyone explain that? Is it just a matter of using A23 such that banks 00-3F and 80-BF aren't mirrors, so you have two distinct 2MB regions for up to 4MB total?

It should become fairly apparently in the first link I gave you how games up to (almost) 32mbit in size have their ROM mapped into the addressing space. ROM is mapped to $8000-ffff in banks $00-7d. $8000 * 126 = 4,128,768 bytes for ROM (as said, just slightly smaller than 32mbit (4,194,304 bytes)).

Games which are 24mbit... never mind, Tepples explained it.

[Charles MacDonald]

Thank you tepples and koitsu for the clarification! Just what I needed to know.

EDIT: Like magic my gamebit arrived soon after posting. To satisfy my curiosity, this is what some different games do:

Super Metroid (LoROM with ROM >2MB)

Half of a LS139 is enabled by ROMSEL# and uses A22, A19 to divide the banks as shown. Note A23 and A15 are not connected to the LS139 or any ROMs, and there's a MAD-1 chip to do the SRAM mapping independently of the LS139.

00-1F / 80-9F : ROM #1 (at offsets 8000-FFFF)
20-3F / A0-BF : ROM #2 (at offsets 8000-FFFF)
40-5F / C0-DF : ROM #3 (at offsets 0000-FFFF)
60-7F / E0-FF : LS139 output not used (MAD-1 maps SRAM here, otherwise areas are open bus)

When accessing ROM #3 you'll get the same data that's at 8000-FFFF mirrored at 0000-7FFF, since A15 doesn't factor into anything.

Shin Megami Tensei (LoROM w/ SRAM and no MAD-1)

An LS139 is used the same as before, and the 60-7F/E0-FF strobe is further decoded by the 2nd half of the LS139 to enable SRAM only when A20=1 and A15=0. This gives:

00-1F / 80-9F : ROM #1
20-3F / A0-BF : ROM #2
40-5F / C0-DF : Open bus
60-6F / E0-EF : Open bus
70-7D / F0-FF : SRAM at 0000-7FFF; 8000-FFFF is open bus

This arrangement would allow 512K SRAM maximum (at F0-FF:0000-7FFF); though of course much less is installed.

Illusion of Gaia (HiROM w/ SRAM and no MAD-1)

The ROM is enabled when ROMSEL# is asserted and A23=0, and a LS139 enables the SRAM for offsets 6000-7FFF in banks 20-3F and A0-BF; it ignores A23. This gives the following map:

00-3F : ROM (at 8000-FFFF so ROM A15=1) (SRAM at 20-3F:6000-7FFF)
40-7F : ROM (at 0000-FFFF)
80-BF : Open bus (except SRAM at A0-BF:6000-7FFF)
C0-FF : Open bus

Mario Paint (LoROM w/ SRAM and no MAD-1)

This is identical to Shin Megami Tensei, except the state of A15 isn't checked when enabling SRAM. That input was re-used to qualify SRAM CS with RESET#. This gives:

00-1F / 80-9F : ROM
20-3F / A0-BF : Open bus
40-5F / C0-DF : Open bus
60-6F / E0-EF : Open bus
70-7D / F0-FF : SRAM at 0000-FFFF

SRAM is only 32K, so it appears mirrored at 8000-FFFF from 0000-7FFF.

Maybe these "real world" examples might help people making their own carts.

EDIT #2: I was curious about how the MAD-1 worked so I logged all possible inputs into it and came up with this:

Code: Select all

Pins 12,13,14,15 are ai3,ai2,ai1,ai0 (address inputs)
Pin 10 is lohisel (LoROM/HiROM decoding select)
Pin 16,1,2,3,4 are lowcs,hics,sramcs,nccs,romoe

!lowcs  =  reset  &  lohisel & !romsel & !ai2    & !ai0 
        #  reset  & !lohisel & !romsel & !ai2    &  ai0 
        #  reset  &  lohisel & !romsel & !ai2    &  ai0;
!hics   =  reset  &  lohisel & !romsel &  ai2    & !ai0 
        #  reset  & !lohisel & !romsel &  ai2    &  ai0 
        #  reset  &  lohisel & !romsel &  ai2    &  ai0;
!sramcs =  reset  & !lohisel & !romsel &  ai3    &  ai2    &  ai1    & !ai0 
        #  reset  &  lohisel &  romsel & !ai3    &  ai2    &  ai1    &  ai0;
!nccs   =  reset  & !lohisel & !romsel &  ai3    &  ai2    & !ai1    & !ai0 
        #  reset  &  lohisel &  romsel & !ai3    & !ai2    &  ai1    &  ai0;
!romoe  =  reset  &  lohisel & !romsel & !ai0 
        #  reset  & !lohisel & !romsel &  ai0 
        #  reset  &  lohisel & !romsel &  ai0;

Now to make sense out of this, let's split the equations up for LoROM and HiROM, and replace the generic address inputs ai0-3 with the LoROM specific inputs:

Code: Select all

!lowcs  =  reset  & !lohisel & !romsel & !ba5    &  a15 
!hics   =  reset  & !lohisel & !romsel &  ba5    &  a15 
!sramcs =  reset  & !lohisel & !romsel &  ba6    &  ba5    &  ba4    & !a15 
!nccs   =  reset  & !lohisel & !romsel &  ba6    &  ba5    & !ba4    & !a15 
!romoe  =  reset  & !lohisel & !romsel &  a15

!lowcs  is banks 00-1F / 40-5F / 80-9F / C0-DF, offsets 8000-FFFF
!hics   is banks 20-3F / 60-7F / A0-BF / E0-FF, offsets 8000-FFFF
!sramcs is banks 70-7F / F0-FF, offsets 0000-7FFF
!nccs   is banks 60-6F / E0-EF, offsets 0000-7FFF

This arrangement supports two 1MB ROMs, 512K SRAM, and a spare CS. Maybe for more SRAM?
Here are the equations for the HiROM mode and the HiROM specific inputs:

Code: Select all

!lowcs  =  reset  &  lohisel & !romsel & !ba5; 
!hics   =  reset  &  lohisel & !romsel &  ba5;
!sramcs =  reset  &  lohisel &  romsel & !ba6    &  ba5    &  a14    &  a13;
!nccs   =  reset  &  lohisel &  romsel & !ba6    & !ba5    &  a14    &  a13;
!romoe  =  reset  &  lohisel & !romsel;

!lowcs  is banks 00-1F / 40-5F / 80-9F / C0-DF, offsets 0000-FFFF (as limited by ROMSEL)
!hics   is banks 20-3F / 60-7F / A0-BF / E0-FF, offsets 0000-FFFF (as limited by ROMSEL)
!sramcs is banks 20-3F / A0-BF, offsets 6000-7FFF
!nccs   is banks 00-1F / 80-9F, offsets 6000-7FFF

This arrangement supports two 2MB ROMs, 128K SRAM, and a spare CS. Looks a lot more like spare SRAM with the same 6000-7FFF mapping this time. I like how they use the not-romsel condition to detect non-ROM areas, and then check the lower address lines to restrict it down to 6000-7FFF.

We can see the MAD-1 chip seems to have a very similar mapping for SRAM (and ROM) as the cartridges that use off the shelf TTL chips to do the same thing. But I can't help but think that spare CS output could have been more useful if set up to support a third ROM.

You could shift up (or down) some of the address inputs to support other ROM sizes, but this would map the SRAM incorrectly. For games without SRAM that may be an acceptable use.