What is the largest sane SNES ROM size?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

What is the largest sane SNES ROM size?

Post by ikari_01 »

Hi everyone,

I am currently working on an SNES cartridge that will be able to load and run games from an inserted SD Card. With a working breadboard prototype (which is currently limited to a single 16 Mbit LoROM/HiROM SlowROM with .SRM autosave to SD and also a complete mess), I am now pondering how much RAM the final PCB should have.

Actually, I'm trying to decide between 48 and 64 Mbits.

I was planning to use 48 Mbits of SRAM (+1Mbit work RAM / save RAM) because AFAIK the largest official SNES games sold have 48 Mbits of ROM. Are there any modifications (e.g., translation patches) that expand ROM size beyond 48 Mbits? I think I heard about some 64 Mbit patch but I cannot remember...

I'm not counting the 96 Mbit S-DD1-less version of Star Ocean because I plan to (eventually) support S-DD1 through the FPGA.

Any hints are highly appreciated. :)
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu »

There's no real "limit", since games which are larger than 32-bit use some form of mapper equivalent. You cited some examples there.
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

64M is the largest LoROM can possibly be and it's the largest size supported officially.
Gekko
Posts: 13
Joined: Wed Jul 01, 2009 2:59 pm

Post by Gekko »

If you don't want to change the mapping, I recall LoROM being limited to 16Mb/2MB and HiROM being limited to 32MB/4MB.
Also, how did you get 64Mb/8MB? Are you including or excluding changing the mapping? In addition, are you including or excluding the mirrors in banks 80 through FF as additional space or not? (Although, even if you did, that would achieve 4MB, not 8)
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Post by ikari_01 »

I change the mapping according to the type of ROM that is loaded. The uC detects the mode of the ROM and sets the mapping on the FPGA. Thus for LoROM I don't have slack by leaving half of the SRAM empty / mirrored.

64Mb should be possible with ExHiROM (iirc, banks c0-ff contain the lower 4MB while 40-7f contain the upper 4MB, plus the shadowed space in 00-3f/80-bf:8000-ffff). The question is whether it is actually used by anything real.

The mirrors in 80-ff are present for "normal" LoROM/HiROM by just ignoring A23. When the uC detects an exHiROM or similar "mapper", it would tell the FPGA to change the mapping accordingly.

As my breadboard prototype only has 2MB of SRAM, I can't play with larger ROMs yet. Actually A23 isn't even connected at the moment.
I want to continue further development with a PCB prototype which has all the parts as I don't want to waste more chips by soldering them onto DIL breakouts. :lol:
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

64M is possible with just vanilla LoROM because /ROMSEL is asserted on $8000-FFFF apart from banks $7E-7F (so technically you can have 63.5M of LoROM).

I say just get a 64M RAM and use any unmapped space for BRAM (woo down to one RAM). Since you know you want 48M support would you use a 32M, 16M and 1M chip? Makes no sense.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Post by ikari_01 »

Actually, I was going to use three or four 16M chips and one 1M chip. 16Mx8 is the largest half affordable SRAM chip I could find that more than one supplier actually has in stock. DRAM is virtually unavailable or you never know what exact parts you get. And SDRAM is a b*tch. :wink:

When mapping what you refer to as BRAM (what does it stand for?) to some unused portion of my RAM, I would lose the possibility to run a 64Mbit ROM that still uses extra RAM. OTOH I was kinda put off by the extra 1M chip anyway. So I might go with 4x16M eventually, thanks!
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

ikari_01 wrote:Actually, I was going to use three or four 16M chips and one 1M chip. 16Mx8 is the largest half affordable SRAM chip I could find that more than one supplier actually has in stock. DRAM is virtually unavailable or you never know what exact parts you get.
By "DRAM" do you include PSRAM, which is DRAM with an on-chip controller that works like SRAM?
When mapping what you refer to as BRAM (what does it stand for?)
B == battery-backed
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Post by ikari_01 »

tepples wrote:By "DRAM" do you include PSRAM, which is DRAM with an on-chip controller that works like SRAM?
I did not know about PSRAM. It does look nice.
At a glance though, there are some difficulties (judging from the parts available at digikey), namely 16bit width only, (F)BGA package only and most of them slightly too slow (70ns); I need to fit two RAM accesses in one SNES cycle because memory access is shared between the SNES and the uC for BRAM access.
I think I'll stick with SRAM, I already have the chips anyway.
tepples wrote:B == battery-backed
Ah, thanks.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Post by Near »

With a memory mapper, you can theoretically support an infinite amount of memory. It just depends on what the mapper supports.

Without a memory mapper, 12.875MB, or 103mbits, is the max possible without very complex address translation.

You can map to:
$00-3f:6000-ffff
$40-7d:0000-ffff
$80-bf:6000-ffff
$c0-ff:0000-ffff

$00-3f|80-bf:0000-1fff and $7e:0000-$7f:ffff is reserved for WRAM, and $00-3f|80-bf:2000-5fff is reserved for MMIO. You can map in any unused MMIO registers between 2000-5fff, but it won't be easy, nor will it net you much more space. It also forces you to always use FastROM (~70ns?) instead of SlowROM (~120ns?) for that area. Really not worth the trouble.

As far as the biggest commercially released games:
Tales of Phantasia is 48mbits without an MMC.
Dai Kaijuu Monogatari 2 is 40mbits without an MMC.
Star Ocean is 48mbits with an MMC (S-DD1.)
Far East of Eden Zero is 40mbits with an MMC (SPC7110.)

And of course, the largest fan-made ROM is 96mbits, neviksti's S-DD1 removal hack of Star Ocean.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Post by ikari_01 »

Thanks byuu, that's a nice roundup of what can actually be mapped as ROM. TBH I used the bsnes source previously as a reference for figuring out the mapping details.

I'm a bit confused by the latencies you gave for FastROM and SlowROM, I thought it was 120ns for FastROM and 200ns for SlowROM. If FastROM is really 70ns, I might be in some trouble...

btw, is /ROMSEL the same as /CART or /CS found in some SNES cartridge docs? And is it not asserted when BRAM is accessed on a mode 21h cart? I could save in Seiken Densetsu 2 only after removing the condition '& !SNES_CS' from my IS_SAVERAM equation for HiROM, which now just reads

Code: Select all

!SNES_ADDR[22] & SNES_ADDR[21] & &SNES_ADDR[14:13] & !SNES_ADDR[15]
.

(IS_SAVERAM is factored into the /OE equation, address calculation and SRAM /CE and /WE.)
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu »

I'll provide proper Slow/FastROM speeds once I get home in a few hours. I'll need to review manuals.
User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku »

Yes, /ROMSEL is the official name for /CS or /CART.

FastROM is 120ns, SlowROM is 200ns.

From siudym's MAD-1 connection diagram (and my MAD-1 logic equations):

The MAD-1 decodes HiROM SRAM with:
A13 & A14 & A21 & !A22 & /ROMSEL & /RESET (& Vbat & MODE)

The MAD-1 decodes LoROM SRAM with:
!A15 & A19 & A21 & A22 & !/ROMSEL & /RESET (& Vbat & !MODE)

I'm not so sure about the accuracy of the diagrams since he used a poor pinout and he notes that the A22 pin is sometimes GND on PCBs which would completely disable the RAM. The A21 and A22 pins are also used for ROM decoding so it varies from cart to cart.

The 74139 LoROM decoder uses simply:
!/ROMSEL & /RESET & !A15 & A21 & A20

I can't find my notes to the 74139 HiROM decoder...
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu »

Sorry, kinda zonked out when I got home.

kyuusaku is correct, re: Fast/SlowROM times. "Normal speed" (e.g. "SlowROM") has to be 200ns or faster. "High speed" (e.g. "FastROM") has to be 120ns or faster.

This is defined in the manual, section "Super NES Software Submission Requirements", chapter 1. Revision C, dated 1992/11/02.
User avatar
ikari_01
Posts: 141
Joined: Sat Jul 04, 2009 2:28 pm
Location: Wunstorf, Germany

Post by ikari_01 »

Thanks for the clarifications!
I was busy with other stuff myself, so no sweat. ;)

What I'm trying to figure out (to decide which SNES pins I actually have to connect to the FPGA) is how the SA-1 manages to halt/suspend the S-CPU during concurrent access of the same memory area (e.g. both SA-1 and S-CPU access the ROM).
The Manual[tm] says the S-CPU is put in a wait state when the SA-1 claims access but it doesn't say how this is accomplished.

Does the SuperFX do this, too? Because I noticed that both the S-DD1 and SA-1 are connected to the "CPU clock" pin as well as the REFRESH pin on the SNES, but the SuperFX isn't connected to either.

Watching a bit of Star Ocean I saw that after some seconds the CPU clock (not the 21MHz system clock) is regularly held low for a short time once per line, in addition to the refresh pause.

I can't observe the SA-1 because I don't have one yet.
Post Reply