nesdev.parodius.com

ikari_01 · Joined: 04 Jul 2009 Posts: 53 Location: Wunstorf, Germany

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. Smile

koitsu · Posted: Sun Jul 05, 2009 7:19 am Post subject:

There's no real "limit", since games which are larger than 32-bit use some form of mapper equivalent. You cited some examples there.

kyuusaku · Joined: 27 Sep 2004 Posts: 1354 Location: .ma.us

64M is the largest LoROM can possibly be and it's the largest size supported officially.

Gekko · Joined: 01 Jul 2009 Posts: 13

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)

ikari_01 · Joined: 04 Jul 2009 Posts: 53 Location: Wunstorf, Germany

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. Laughing

kyuusaku · Joined: 27 Sep 2004 Posts: 1354 Location: .ma.us

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.

ikari_01 · Joined: 04 Jul 2009 Posts: 53 Location: Wunstorf, Germany

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 · Posted: Sun Jul 05, 2009 5:10 pm Post subject:

ikari_01 · Joined: 04 Jul 2009 Posts: 53 Location: Wunstorf, Germany

byuu · Joined: 27 Mar 2006 Posts: 307

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.

ikari_01 · Joined: 04 Jul 2009 Posts: 53 Location: Wunstorf, Germany

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

koitsu · Posted: Mon Jul 06, 2009 4:26 am Post subject:

I'll provide proper Slow/FastROM speeds once I get home in a few hours. I'll need to review manuals.

kyuusaku · Joined: 27 Sep 2004 Posts: 1354 Location: .ma.us

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...

koitsu · Posted: Mon Jul 06, 2009 10:26 pm Post subject:

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.

ikari_01 · Joined: 04 Jul 2009 Posts: 53 Location: Wunstorf, Germany

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

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.