Been reading up on SNES repos, have I got my facts straight?

fireaza · Post by **fireaza** » Thu Jul 05, 2012 6:38 pm

Hmmm, it seems like I've got quite a few options when it comes to padding out the size of my ROMs. I can use a hex editor to duplicate some of the data, I can split the file (does SNES ROM UTILITY achieve the same splitting results as SNES TOOL?), pad out the smaller one, re-join them then double the size of the ROM. Sorry if this sounds like a stupid question, but do all these techniques work just as well as each other? It sounds to me like they're accomplishing the same thing, in two different ways, but you never know. It still boggles me that putting a second copy of half the ROM, into the ROM and doubling that (ending up with 4 copies of the back half the ROM and 2 of the front in the one ROM) doesn't break the ROM horribly. And what about games that had strict copyright protection? For example, EarthBound's famously sadistic copy protection. At various points, the game does a checksum of it's code and detects if anything has been altered. If it finds alterations, it does everything from spawning more enemies to erasing your game. Wouldn't games like this be tripped since the ROM has been edited to be larger than it should be?

tepples wrote:The non-power-of-two sized ROMs were originally carts containing two mask ROM ICs, one larger and one smaller.

This brings up something I hadn't realised, for the carts that use two mask ROMs, would it be better to use two EPROMs instead of one large one? Take for example the ROM I've been experimenting with so far, it's a 12 megabit ROM, so that would mean the original cart used 2x 6 megabit mask ROMs right? So wouldn't the best option be to mimic this by splitting the 12 megabit ROM in half, and burning each half to a suitable EPROM/EEPROM, such as the 8 megabit 27C801? Though that still leaves us with a ROM that's slightly too small for the EPROM, hmmm... What if we added a whole bunch of 0s to the end of each half, like how they were originally written (if I'm interpreting what I'm seeing in the hex editor correctly that is)? Well, doing it this way would put my mind at ease anyway

Post by **lidnariq** » Thu Jul 05, 2012 10:29 pm

fireaza wrote:the original cart used 2x 6 megabit mask ROMs right?

tepples wrote:The non-power-of-two sized ROMs were originally carts containing two mask ROM ICs, one larger and one smaller.

As far as you're concerned, all ROMs that you'll be able to program are a power of two in size. 6 is not a power of two.

The SNES did something funny where size of die finally actually became more expensive than package, so developing a 10, 12, 20, or 24mbit game was actually a reasonable decision.

fireaza · Post by **fireaza** » Thu Jul 05, 2012 10:46 pm

Whoops, I'd forgotten tepples had said that

Hmmmm, in that case, and following on the idea of using two eproms like the original cart, what about if I used 1x 8 megabit eprom (say, a 27C801) and 1x 4 megabit eprom (say, a 27C040)? That adds up nicely to 12 mega bits, which means no mirroring and it also follows the design of the original cart by having two ROM chips. Would that work?

Post by **lidnariq** » Thu Jul 05, 2012 11:20 pm

That would work perfectly fine, if it's actually cheaper for you to do it that way. Using a single larger prom may be cheaper than two separate smaller roms and decoder logic.

fireaza · Post by **fireaza** » Thu Jul 05, 2012 11:45 pm

It works out to be about $6 for both chips, vs $12 for the 29F032 and TSOP adaptor

With regards to brands, obviously AMD is a good choice for the 27C040. For the 27C801, I've got a choice between ST, ATMEL, MXIC and NEC. NEC is the only brand I recognise there, so them maybe? They're all DIP32 with a speed of 120ns or less, so I'm not sure how much brand matters.

On the topic of splitting the ROM, I've tested this with SNES ROM utility. When I opened up the two split ROMS in a hex editor, I noticed it seems to have been split in an odd way. Okay, so, the un-split ROM looks like this:
DATA
BUNCH OF 0S
DATA
BUNCH OF 0S

Obviously, the two "breaks" are where each mask ROM ended, they padded out the end of each ROM in order to fully fill the mask ROM. You'd think that splitting the downloaded ROM would put a nice slice at the end of the first break. But when I looked at part 1 with a hex editor, it looked like this:

DATA

and part 2:
DATA
BUNCH OF 0S
DATA
BUNCH OF 0S

It's obviously hasn't split the ROM in the ideal way. Is this a problem?

Post by **tepples** » Fri Jul 06, 2012 5:53 am

fireaza wrote:It still boggles me that putting a second copy of half the ROM, into the ROM and doubling that (ending up with 4 copies of the back half the ROM and 2 of the front in the one ROM) doesn't break the ROM horribly.

It's called "incomplete decoding". As long as a given set of signals on the address bus produce the expected signals on the data bus, the program can't tell the difference. Have you ever heard of an "overdump"?

pichichi010 · Post by **pichichi010** » Fri Jul 06, 2012 7:14 am

Guys any of you have experience with multi carts?

I grew up in mexico so we had a lot of pirated games.

My friend still owns a couple of them,

Instead of adding a Menu, sometimes the multi carts would be made in a way that whenever you hit reset on the console, the game would change.

I can ask my friend to send me one that works like that if someone wants to take a look at it.

It is pretty weird, but it might be a convenient way to make a multi cart instead of going through writing a menu etc.

Although with menu it adds to the quality.

Do they just burn the roms in the chip and the snes picks up by resetting it?

Post by **tepples** » Fri Jul 06, 2012 7:27 am

In the reset-based multicarts, there's a circuit to detect soft resets, and there's a counter on the cart that increments after reset. The output of this counter goes to high address lines.

pichichi010 · Post by **pichichi010** » Fri Jul 06, 2012 7:28 am

so is not like they burned multiple files in the memory chip?

Post by **tepples** » Fri Jul 06, 2012 7:29 am

Yes, they did burn multiple files in the memory chip. The counter selects a file in the memory chip by controlling the high address lines.

pichichi010 · Post by **pichichi010** » Fri Jul 06, 2012 8:00 am

how difficult is this to program?

what do you recommend to be better?

Menu or resets?

Post by **tepples** » Fri Jul 06, 2012 8:08 am

If you're going to be doing more than 4-in-1, I'd recommend not wearing out your users' reset buttons. There's a reason that TVs have come with number keys for changing the channel since cable was invented.

pichichi010 · Post by **pichichi010** » Fri Jul 06, 2012 8:10 am

Well, we are planning on making 2 games in one cart.. may be 3 if we find someone else's game that we think is good and they want to put it in a cart.

But actually I believe that making a cool menu (ie: Dragon quest 1&2)

would add to the user experience.

Post by **tepples** » Fri Jul 06, 2012 8:47 am

You're right about the user experience. I would recommend a reset-based solution only if all games completely fill all bytes of the memory, meaning you can't even spare a couple kilobytes for the most basic menu. But in any multicart, you're going to have to find some way to handle the NMI and IRQ vectors.

pichichi010 · Post by **pichichi010** » Fri Jul 06, 2012 8:50 am

Thanks for the opinion, and yes i think we will encourage the developer to get a menu done, because one of the games is a mini game roughly 8mbit and the other game which is a complete game would be the same size.

If you know someone that has or would like to have his game put in this multicart pls pm me.

they will be paid a percentage based on sales.

Thank you Tepples!