Hi there guys! You fellas seem like the knowledgeable sort to run this by, so here goes. For ages, I've wanted to own a number of Japan-only SNES games in English. Then I heard it's possible to take a SNES game and replace the original ROM with one of the many fan-translated versions available on the internet and play them on the original hardware! I've been reading up on how to make SNES reproductions and I think I understand how to make them now, but I thought I'd check with you guys first
Donor Carts
As I understand it, you can make an English version of a Super Famicom game by using the original Super Famicom cart. This is appealing to me, as it greatly simplifies the process (no need to find which game is compatible) and I also get the original label and packaging as well
Is this correct?
The chips
One thing that bothered me with many reproductions I'd seen is the larger games needed multiple eproms soldered together. This really tweaked my sense of aesthetics. But now I see you can get TSOP adaptors that fit the spot that the original ROM was in, no need to solder together multiple eproms, no rats' nest of wires. Much better! Now, as I understand it, the parts required for this style of reproduction are:
29F032
DIP36-TSOP40 Adapter (III)
I've been looking to get these parts from buyicnow.com, and I see they sell what
appears to me to be a 29F032 and a DIP36-TSOP40 Adapter (III) pre-assembled. This appeals to me, because this would save some fiddly soldering, plus buyicnow.com also have a programming service, so I wouldn't need a programmer either! Also, is the brand of the 29F032 and it's speed important?
Now, this would be for larger games, but it seems wasteful if the game I'm trying to make is less then 32 Megabit in size. So what are my options in this case? Keep in mind, I'm looking for something neat and tidy in appearance
So what do you guys think? Do I have all the facts right? Let me know!
I was unaware that they started selling pre-populated TSOP adapters, that is
not a horrible price for it either. If I didnt already have about 20 of those made up in my workshop, I would probably pick a few up.
I would use a TSOP for any game over 16mbit up to 32mbit. For 16mbit games, just use a 2 mask board.
Speed of a 29F032 is not important, as every version of that particular chip is more than fast enough for the SNES. That being said, I would not spend any extra money on a faster one, as it would just be wasted capability.
Yes, you can use a SFC cart as a repro donor for an English translation of the same game. Depending on your region, you might need to swap out the CIC for one from your region though. A lot of people here have very strong opinions on repros, especially if you're using a good game as a donor. Personally, unless it's a special chip game, I would rather see you buy the Japanese game (you know, so you legitimately own the game), then buy a crappy sports game to use as your donor, then just swap the boards, so the original Japanese board stays intact, but that's just me I suppose.
Brand doesn't matter as long as it is a *29F032 part number, speed doesn't matter as long as it is -120 or less. More than -120 won't run FastROM games. More than -200 won't work, period (although I've never seen a 29F032 that slow).
I'm pretty sure the SKU that goes with that photo of a pre-assembled board is actually for ordering just the board. The SKU listed as "on board" really makes me think it just hasn't been pulled yet, rather than being on one of the TSOP-DIP adapters (seeing as it's cheaper than either the AM29F032 OR the adapter board separately, it really can't be a preassembled adapter board).
I just received a lot of 10 AM29F032's, which is probably more than I'll ever need, and I ordered the BuyICNow adapter boards to go with them. If you're just interested in one or two, shoot me a PM and I'd be willing to sell you a couple (yes, I know I'm brand new here, long time guest, but I'm good for it, PM me and you can decide if you feel comfortable with it). I'm still waiting on the boards from BuyICNow, and if you want it programmed, that would take a little longer (I don't have a programmer up and running yet...), but we could work something out.
Also, you should take a look a this project:
http://nesdev.com/bbs/viewtopic.php?t=9013
Even if you don't want to have a USB port in your cart, you could still solder in female headers in the pin slots rather than male pin headers and then you'd have a cheap USB programmer for 29F032's already mounted on to an adapter board.
rkrenicki wrote:
I would use a TSOP for any game over 16mbit up to 32mbit. For 16mbit games, just use a 2 mask board.
"2 mask board"? Can you elaborate? Is that like, 2 eproms or something?
rkrenicki wrote:
Speed of a 29F032 is not important, as every version of that particular chip is more than fast enough for the SNES. That being said, I would not spend any extra money on a faster one, as it would just be wasted capability.
As qwertymodo said, so long as it's less than 120, it's all good, and every one of the 29F032s on buyicnow.com are
qwertymodo wrote:
Yes, you can use a SFC cart as a repro donor for an English translation of the same game. Depending on your region, you might need to swap out the CIC for one from your region though.
I have both an NTSC and PAL SNES, so I'm all set. Since SFC are NTSC, I shoulden't need to worry about having the swap the CIC right?
qwertymodo wrote:
A lot of people here have very strong opinions on repros, especially if you're using a good game as a donor. Personally, unless it's a special chip game, I would rather see you buy the Japanese game (you know, so you legitimately own the game), then buy a crappy sports game to use as your donor, then just swap the boards, so the original Japanese board stays intact, but that's just me I suppose.
I don't fully agree. While it would be really sad to see someone gut a good game to turn it into a different game, in my case, if I could read Japanese, I'd be taking the same game out of circulation anyway
qwertymodo wrote:
I'm pretty sure the SKU that goes with that photo of a pre-assembled board is actually for ordering just the board. The SKU listed as "on board" really makes me think it just hasn't been pulled yet, rather than being on one of the TSOP-DIP adapters (seeing as it's cheaper than either the AM29F032 OR the adapter board separately, it really can't be a preassembled adapter board).
I dunno... The DIP36-TSOP40 Adapter (III) only cost $0.65, so I'd say the price is right. I might fire off an email to them an confirm though.
qwertymodo wrote:
I just received a lot of 10 AM29F032's, which is probably more than I'll ever need, and I ordered the BuyICNow adapter boards to go with them. If you're just interested in one or two, shoot me a PM and I'd be willing to sell you a couple (yes, I know I'm brand new here, long time guest, but I'm good for it, PM me and you can decide if you feel comfortable with it). I'm still waiting on the boards from BuyICNow, and if you want it programmed, that would take a little longer (I don't have a programmer up and running yet...), but we could work something out.
Thanks for the offer! But since neither of us have a programmer, I think it would be eaiser to just pay the buyicnow.com guys $0.50 to program it for me
That project sounds interesting, but as I said, buyicnow.com can program them for me for the nominal cost of $.50
*EDIT* I just got an email from buyicnow.com, they said:
Quote:
Yes, this item (item ID
00002503) is for am29f032B solder on dip36-tsop40 adapter III .
We can burn it for you.
Please add programming service(in the end of item page) into shopping cart.
And send the rom file(s) to
buyicnow@gmail.com So yeah, sounds like they are indeed selling the 29f032 chip soldered into the TSOP adaptor.
So yeah, would this be as simple as buying this chip and adaptor combo, and sending them the English-patched ROM to burn? Or is is it a bit more complex/are other precautions involved?
Not to sound rude or anything but everything you need to know about that subject is already on the board and were explained numerous time before.
fireaza wrote:
So yeah, would this be as simple as buying this chip and adaptor combo, and sending them the English-patched ROM to burn? Or is is it a bit more complex/are other precautions involved?
Depends. What game is it?
SkinnyV wrote:
Not to sound rude or anything but everything you need to know about that subject is already on the board and were explained numerous time before.
Some information, but not all (i.e the fact that buyicnow.com are selling the two parts pre-assembled)
qwertymodo wrote:
fireaza wrote:
So yeah, would this be as simple as buying this chip and adaptor combo, and sending them the English-patched ROM to burn? Or is is it a bit more complex/are other precautions involved?
Depends. What game is it?
Seiken Densetsu 3 (AKA Secret of Mana 2) namely. Like, what are the general rules? Are there limits on what characters can be used in the file name? Maximum number of characters? What should the file extension be? Does the ROM need to be edited in some fashion? That kinda thing.
fireaza wrote:
Does the ROM need to be edited in some fashion?
It needs to be headerless (.sfc), not with a copier header (.smc, .swc, .fig, etc). And it needs to run in bsnes for two reasons: 1. bsnes enforces a lot of hardware limitations that ZSNES and Snes9x fail to enforce, and 2. bsnes needs ROMs to be headerless.
Gotcha! Do you recommend SNEStool or SNEStuff to remove the header? Out of curiosity, why would the header have been added to the ROM if it wasn't there in the original cartridge? Are there no limitations on what the ROM can be named, so long as it ends in ".sfc" (short for "Super Fami Com" I'm guessing?)?
fireaza wrote:
Out of curiosity, why would the header have been added to the ROM if it wasn't there in the original cartridge?
For much the same reason that iNES adds a 16-byte header. Old floppy disk based copiers stored information in the first 512 bytes of the file. New emulators and the SNES PowerPak ignore the copier header and use the information embedded in the ROM at $7FD0 of a LoROM or $FFD0 of a HiROM.
Quote:
Are there no limitations on what the ROM can be named, so long as it ends in ".sfc" (short for "Super Fami Com" I'm guessing?)?
I don't know how their system works, but I'd recommend making sure the name uses only basic Latin (ASCII) characters, not Japanese characters or anything like that.
Ah, so the SNES itself isn't too bothered, but the programmer might? I follow you.
Well, I think I'm about ready. Sounds like all I need to do is patch the original ROM, remove the header, make sure the file ends in ".sfc", buy the 29f032 TSOP adaptor combo, email them the file, and this should result in a ready-to-solder chip that I can throw into the original SFC cart!
What about repros on new board with new parts? will that be bad?
Im looking into doing this.
By the way, off topic. I am looking into getting an undumped game, which I think it does not have eproms, but epoxy bubble.
Is there any other way to dump the information?
I was thinking Retrode, but I don't want to spend 90 bucks to dump only one game.
pichichi010 wrote:
What about repros on new board with new parts? will that be bad?
I've heard of this, but I didn't think the parts were available to the general public?
Okay, I'm trying to find a suitable Seiken Densetsu 3 ROM to use the English patch on, and I've found two. One with a ".smc" extension and one with a ".sfc" extension, both 4mb. Now, I would think the ".sfc" version would be the better one, since it should be closer to what was on the original cartridge (I'm worried that the .smc version isn't as accurate of a dump as the .sfc version), but the English patcher doesn't handle .sfc files! What's up with that? Am I suppose to patch the .smc, remove it's header and rename it's extension to ".sfc"?
*EDIT* I've found a tool called "SNES Purify" by the bsnes guy. I loaded up the English-patched Seiken Densetsu 3 .smc, and it found that the file had a header, and it's file extension was wrong, and corrected both. The game now plays in bsnes. I take it that this program has, well, purified the .smc and is the same as if it were freshly dumped as a .sfc? I'd hate to get this new .sfc burned then find I was suppose to go about the process a different way and the cart won't play
As long as the file is exactly 4,194,304 bytes long, it is correct for burning.
I know that when I burn roms to 29f032s using my GQ-3X, I leave the smc file as-is with no stripping of headers.
It is indeed 4,194,304 bytes, thanks for the tip!
Alright, so I've got the English patched ROM. It's the correct size, it's been though SNES Purify (headers removed, renamed ".sfc"), it plays correctly in BSNES, is this bad boy ready to rumble? Is it simply a matter of burning the .sfc and soldering the whole shebang into the donor Seiken Densetsu 3 Super Famicom cart?
You need to check the readme on the patch file. Some patches are meant to be applied to headered ROMs (because some people are ignorant and continue to use headered ROMs >.<). Just be sure that the final ready-to-burn file has the header removed. Also, filename doesn't matter AT ALL when it comes to burning to the ROM. Raw flash ROMs don't have a file system, they have no concept of files, much less file names. It's just one big binary blob.
Actually, the re-translation patch for Breath of Fire II specially calls to it to be applied to a ROM with no headers
Something odd I noticed, if you check back to the page 1, I was worried about applying the Seiken Densetsu 3 English patch to a .smc instead of a .sfc. Well, I tried to apply the .ips to the .sfc version, ignoring the installer that came with the English patch. This horribly corrupted the game's graphics! Is this a normal thing?
Thanks for the tip on eprom file names! That helps matters! So you think this is all ready to go?
It shouldn't have mattered that you applied the patch to an .smc file, chances are that between the .smc and the .sfc, one had a header and one did not. Applying a patch intended for a headered ROM to an unheadered ROM or vice versa will corrupt it (that's why I said to check the README for the patch, but removing the header after applying all of the patches is fine, it's just an issue before patching). The other thing I usually do is before patching, I run the original ROM through NSRT to verify that it was a proper dump. Any decent patch will require the verified good dump (usually denoted with [!] in the filename, but I never trust that). Other than that, it should be good to go. Since it's already a 32Mbit ROM, you don't need to mirror anything like you would for a smaller ROM, so yeah, I'd say it's ready to burn.
Great!
I'm looking to apply a Breath of Fire II hack that re-translates the game, and also adds an animated opening sequence that includes a song with actual singing! Somehow, the size of the rom is still the same (witchcraft!), so do you think this hack would be playable on real hardware? I know it often causes BSNES to freeze, so I'm not sure.
*EDIT* solved issue with SD3 bad checksum
Use the one with the good checksum. If it doesn't work, see if it has a header or not. If it does, try removing it, if not, add it (in NSRT, right-click on it and add or remove header, it doesn't matter what type of header you add). The checksum might be bad after patching, some ROM hacks don't bother fixing their checksums, it doesn't matter.
Ha ha, I actually solved the issue (found an .smc version of the game with a good checksum) and edited my post to reflect this
But yeah, as mentioned above in my edited post, I'm not sure that BoFII hack would be playable, since BSNES is suppose to be console-accurete, you would assume that if the hacked ROM cases BSNES to freeze, that the real hardware would too right?
Another issue I'm having is with "Ranma Nibunnoichi - Akanekodan Teki Hihou", I've got a .smc with a good checksum, I've patched the game, run it through SNES Purify (which only detects that the extension is wrong, yet for some reason, despite saying it corrected it, actually doesn't, I need to rename it manually) but I get a black screen in BSNES when I try to load it. The game works before I patch it. Any ideas?
Not all patches actually work on real hardware. A lot of times, patches are built using ZSNES, not realizing that ZSNES utilizes a lot of hacks to get games to run such that hacks designed for ZSNES often won't run on an actual SNES. That's part of the reason byuu is so devoted to accuracy with BSNES (or is it ASNES now...?). His motivations are archival preservation and creating a hardware-accurate debugging and development environment for ROM hacks or homebrew games so that the resulting ROM would be playable on real hardware. Sadly, a lot of people hate on BSNES just because it has such hefty hardware requirements. On the other hand, BSNES is not entirely flawless either (though it should be pretty darn close), I can't for the life of me get the 96Mbit NoSDD-1 hack of Star Ocean to run in it (it shows a framerate as though it is running, but all I get is a black screen), even though I KNOW that hack works on copiers.
Hmmmm, well, there's a patch for the BoFII hack that removes the new opening, and this one seems to work fine on BSNES, so again, that would mean this hack should work on real hardware? The next tricky thing would be the donor cart, for you see, this hack is based on the American version of the game, not the Japanese. Would this hack still work on a Japanese copy of BoFII anyway?
Regarding your black screen in BSNES with Star Ocean, that's the exact same issue I'm having with Ranma Nibunnoichi - Akanekodan Teki Hihou. And I've seen English patched repos of this game, so I know it's possible to make a repo out of it.
I just checked my SD3 ROM, and it seems that the patch doesn't fix the checksum, so you should get a bad checksum on the patched ROM. In case you want to compare, the CRC32 on my patched, unheadered ROM is 7DBDE871 (CRC32 != internal checksum). After manually fixing the internal checksum, I get a CRC32 of 8D748300.
My understanding is patched ROMS will ALWAYS give a bad checksum since you've altered the ROM
Oh, and I found out why SNES Purify wasn't renaming my .smc, it didn't like the folder name :\
*EDIT* And now the English patched Ranma Nibunnoichi Akanekodan works fine in BSNES! It's filesize is only 1,572,864 bytes though, seems wasteful to put it on a 32 megabit chip, what would you guys suggest instead?
get the eprom 27xxxx and do the swaping method?
its fairly simple, and it only involves limited wiring.
fireaza wrote:
My understanding is patched ROMS will ALWAYS give a bad checksum since you've altered the ROM
The patch can include a new checksum value. Just a lot of times ROM hackers don't bother.
pichichi010 wrote:
get the eprom 27xxxx and do the swaping method?
its fairly simple, and it only involves limited wiring.
Having trouble finding a 12 megabit eprom, do you know what model I should be looking for? I can only seem to find 8 megabit eproms :\
And do you have more information on the "swapping method" you mentioned? Googling "snes repo swapping method" actually leads me back to this thread
prepare to be amused!
this is in spanish but I'm sure you can translate it in google.
it teaches you ALL the methods.
http://www.elotrolado.net/hilo_tutorial ... es_1633607
fireaza wrote:
Having trouble finding a 12 megabit eprom, do you know what model I should be looking for? I can only seem to find 8 megabit eproms :\
EPROMs come in powers of two. You'd need to get a 16 megabit or an 8 + 4.
pichichi010 wrote:
prepare to be amused!
this is in spanish but I'm sure you can translate it in google.
it teaches you ALL the methods.
http://www.elotrolado.net/hilo_tutorial ... es_1633607Google translate breaks the spoiler tags, I can't open them to see the instructions (good job Google!) Is this is swap method you mentioned?
tepples wrote:
EPROMs come in powers of two. You'd need to get a 16 megabit or an 8 + 4.
They DO make 16 megabit eproms in a DIP36 flavour right? I can only seem to find DIP42 :\
Yes, you swap the rom with a snes tool, burn it, then straight solder it, but those 2 pins, you swap the wiring.
"swap the rom with a snes tool"? I don't see a "swap" option in SNESTOOL, what am I missing? And the swap method, you need to do this on all DIP36 eproms do you?
Sorry I ment the Snes ROM utility rom romhacking.net
Ah, you're talking about the "swap bin" option?
This is the process you're talking about right? Just so I understand the process, why do we have to do a "swap bin"? I take it this related to having the slightly re-wire the eprom? Like, the ROM in it's default state isn't compatible with the eprom so you need to slightly alter it? And you only need to do a swap bin and re-wire if you're using that style of eprom correct? You'd never need to do this with the 29F032 DIP36-TSOP40 Adapter (III) combo I mentioned earlier?
fireaza wrote:
They DO make 16 megabit eproms in a DIP36 flavour right? I can only seem to find DIP42 :\
No, they don't. No one makes any EPROMs or EEPROMs or FlashROMs that are compatible with SNES maskroms. All require rewiring.
Sorry, I meant DIP32, not DIP36
These are the eproms used in the Swapbin EPROM Method correct? I haven't been able to find any 16 megabit versions, I only seem to be finding them in DIP42 flavour. Do they exist?
More than likely, for anything above 4-8Mbit, you'll need multiple (E)EPROM's with a decoder to select between them. If you only need two, try stacking them one on top of the board, one on bottom, then clip the legs short on the bottom one.
or he can use
NBA live 95, try aikman football.. Secret of mana 2 7th saga. secret of mana boards.
qwertymodo wrote:
More than likely, for anything above 4-8Mbit, you'll need multiple (E)EPROM's with a decoder to select between them. If you only need two, try stacking them one on top of the board, one on bottom, then clip the legs short on the bottom one.
Hmmmm... I think I'll stick with the 29F032 and DIP36-TSOP40 Adapter (III) for those games to keep everything all neat and tidy
It doesn't matter that there will be some free space left over? For games 8 megabit and smaller, from what I can see, you can only get DIP32s in the form of eproms and not eeproms? Is that correct?
pichichi010 wrote:
or he can use
NBA live 95, try aikman football.. Secret of mana 2 7th saga. secret of mana boards.
Those boards have room for two chips don't they? So you'd split the game across two eproms or something like that? Does that effect the game's performance?
yeah those have 2 mask roms and they would work, but since you using dip32 you have to carefully see which one supports hirom or lo rom.
That's the speed of the chips right? You can't just pop any eprom that runs at 120 or less and lo roms just won't make use of the extra speed?
Im not sure on that one if it depends on the chip speed or the rom speed.
i mean that you need to burn a hirom ROM into the eprom and them solder it into a compatible hirom.
"compatible hirom" in this case being an eprom that runs at 120ns or less correct?
No i believe the ROM (the game file) you are burning has to be Hirom as the board.
I'm not really sure about this because I use the tsop adapter only.
As I understand it, LoROM and HiROM have nothing to do with speed. There are SlowROM and FastROM, and FastROM games need 120 ns or faster memory, but (correct me if I'm wrong) FastROM games can be either LoROM or HiROM.
LoROM vs. HiROM: Function of A15 vs. A22
SlowROM vs. FastROM: Whether or not 130 to 200 ns memory is acceptable
I have a list of all or most of the ROMS available with the information from
how much ram does it need, special chip and Fast rom and slow rom.
as soon as I get home Ill post the link so you can see which games could be good donors, etc.
it is really useful.
tepples wrote:
As I understand it, LoROM and HiROM have nothing to do with speed. There are SlowROM and FastROM, and FastROM games need 120 ns or faster memory, but (correct me if I'm wrong) FastROM games can be either LoROM or HiROM.
LoROM vs. HiROM: Function of A15 vs. A22
SlowROM vs. FastROM: Whether or not 130 to 200 ns memory is acceptable
Ah, so LoROM and HiROM have nothing to do with the eprom, but more the design of the cart's board?
pichichi010 wrote:
I have a list of all or most of the ROMS available with the information from
how much ram does it need, special chip and Fast rom and slow rom.
as soon as I get home Ill post the link so you can see which games could be good donors, etc.
it is really useful.
That would be handy for the Satellaview (i.e Radical Dreamers) repos I would be interested in making, since these didn't get a cartridge release, so I can't just buy the Super Famicom version and use that as the donor.
fireaza wrote:
Ah, so LoROM and HiROM have nothing to do with the eprom, but more the design of the cart's board?
Yeah. LoROM uses 32 KiB banks, while HiROM uses 64 KiB banks. In NES parlance, they might be considered "mappers", much as UNROM (#2) differs from BNROM (#34).
Good to know! Thanks!
Okay, I think I know almost everything I need to know about SNES repos! Thanks for all your help guys! A few final questions:
1) If I'm using a 29F032 eeprom (a 32 megabit chip) and I put a ROM that's smaller than that on there, do I need to worry that there's free space on the eeprom?
2) If I'm using a 8 megabit eprom, do I always need to add those two crossed wires, and are they always soldered to the same legs on the eprom and the same spots on the board?
3) Are the American and Japanese carts considered to be the same for the purposes of reproductions? For example, the Breath of Fire II re-translation patch must be applied to a ROM of the American version of the game, but could I use the original Japanese Super Famicom version of the game as the donor cart?
4) Any other odd things I should know about that we haven't already discussed?
*EDIT* qwertymodo: About the black screen problem you were having, have you tried downloading the ROM from a different website? I ran into this problem just now, and despite the first ROM having a good CRC, I got a black screen in BSNES. I downloaded the ROM (same extension) from a different website, and this one patched and played fined.
fireaza wrote:
If I'm using a 29F032 eeprom (a 32 megabit chip) and I put a ROM that's smaller than that on there, do I need to worry that there's free space on the eeprom?
As long as you tie the unused address lines to ground. For example, with an 8 megabit game on a 32 megabit chip, you'd ground the two most significant address lines.
Quote:
3) Are the American and Japanese carts considered to be the same for the purposes of reproductions?
As long as the (J) and (U) versions of the game are the same size, they should be using the same board. It's not like NES, where games often had to be mapper-hacked to use an NOA-approved mapper similar in capability to the original (e.g. City Connection from #87 to #3 or Castlevania 3 from #24 to #5).
tepples wrote:
fireaza wrote:
If I'm using a 29F032 eeprom (a 32 megabit chip) and I put a ROM that's smaller than that on there, do I need to worry that there's free space on the eeprom?
As long as you tie the unused address lines to ground. For example, with an 8 megabit game on a 32 megabit chip, you'd ground the two most significant address lines.
Is that still true if you're using a DIP36 TSOP40 adaptor?
*EDIT* Found a quote from MottZilla on this very forum regarding the 29f032, smaller ROMS and if you need to mod them:
Quote:
For most games, you don't have to do anything different. The only games that rely on mirroring that I know of are Mega Man X and Demon's Crest.
Sounds like I'm good for the repros I'm looking to make
Has anyone ever made a Tales of Phantasia repro? It's 48 megabit game, so obviously, it won't fit on the 32 megabit 29f032. I can't find any larger TSOP 40 EEPROMs, however, from what I can see, the board uses 2x ROMs. So I should be able to use 2x 29f032s right? Well, Snes Central says the smallest size that Phantasia's board takes is 40 Mbit. Would that means that the board will not recognise eproms smaller than that, such as the 29f032?
As far as putting a small game on a large ROM, it doesn't hurt to mirror the ROM file to fill the chip. If it's a power of two in size (1, 2, 4, 8, 16Mbit) just copy the entirety of it using a hex editor in order to make it 32Mbit. If it's not a power of two (12, 24, 28Mbit, etc), you first copy the end portion of the file back to the nearest power of two, then copy the entire result to get your 32Mbit total. For instance, say you have a 12Mbit ROM. Copy the data from 8Mbit to the end and paste it at the end of the file, then you'll have 16Mbit. Then copy the entire thing and you have 32Mbit.
I know nothing about hex editing
Can you give me a quick run-down on how to do what you've just described? Google's not coming up with the goods. I mean, I've got the ROM opened up in Hex Workshop, but I have no idea what I should be copying. I mean, where's the notches that indicate where each megabit is? I feel like chimp who trying to drive a bulldozer
*EDIT* When I look at the ROM in Hex Workshop, I notice there's a whole bunch of 0s at the end of the ROM, obviously to pad the game out to 12 megabits. Could I just stick a whole bunch more 0s on the end of the rom to achieve the same effect?
Do you know how to work a command prompt?
copy /b toki.sfc+toki.sfc tokidoki.sfc
Back in the day I used to use DOS... I'll give it a shot...
*EDIT* CHANGE DIRECTORY TO F:\ YOU BASTARD!! WHY WON'T YOU OBEY?
*EDIT* AH HA! GOTCHA! Okay, I've got the ROM to 24 megabits. Putting a second copy inside the ROM seriously doesn't break it? Madness!
*EDIT* There's apparently a program called "ROM Padder" that's suppose to pad out ROMs. I can't seem to get it to work, I think it's incompatible with 64-bit versions of Windows.
Like MS-DOS and unlike UNIX, Windows maintains a separate current working directory for each mounted file system. To change to a directory on a different file system, you may first need to specify the drive letter on a line by itself. So instead of
Code:
cd F:\
use
Code:
F:
cd \
If a ROM size isn't a power of two, doubling it up is more complicated. You first have to use a split tool such as
dd (which comes with Cygwin, MSYS, Linux, or *BSD) to break it into the file for the larger chip and the file for the smaller chip. Then you double up the smaller file until it's as big as the larger file, and doubling after that depends on how the board is wired.
"larger chip and smaller chip"? Don't forget, I'm using a single 32 megabit eeprom here
Or are you describing this process?
Quote:
If you want to pad your rom with zero's. You can use ucon64 to do it and then split it into two 8mbit files.
ucon64 -p rom.smc (do this 4 times)
ucon64 -s rom.smc (do this after the desired size is reached)
If you want to mirror the last chunk of the rom, use snestool to split the rom (8mbit split size). You'll get two files: rom.1 (8mbit) and rom.2 (4mbit). Make sure you use "delete header" on rom.1 before exiting. It will also automatically delete the header on rom.2 as well. Finally do this in command prompt:
copy /b rom.2 + rom.2 rom.2+2
Rom.1 and rom.2+2 should be suitable for burning onto 8mbit eproms.
Yes, I was referring to "use snestool to split the rom". The non-power-of-two sized ROMs were originally carts containing two mask ROM ICs, one larger and one smaller. The smaller one has to be doubled up to match the size of the larger one before the whole thing is doubled.
Here's the best free, lightweight hex editor I've found:
http://mh-nexus.de/en/hxd/ Play around with it, just keep a backup of the original file and you should be fine. It's fairly trivial to copy/paste.
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
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.
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?
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.
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?
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"?
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?
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.
so is not like they burned multiple files in the memory chip?
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.
how difficult is this to program?
what do you recommend to be better?
Menu or resets?
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.
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.
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.
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!
tepples wrote:
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"?
I have now...?
This comes back to the design philosophy of "if it looks good, it is good", having a final product that consists of 4 copies of the back half the ROM and 2 of the front in the one ROM doesn't "look good", but hey, that's why I study design and not programming!
Turning this thread back around again, there's what hopefully should be the last remaining questions that I have (at which point I should be ready to rumble, as well as write my own "idiot's guide" for the forum detailing all that I've learned in simple terminology and steps):
1) eprom brands: important or not? I've got a choice between ST, ATMEL, MXIC and NEC, with NEC being the only familiar brand to me.
2) ROM splitting: it's it a problem that SNES ROM Utility split the ROM in what I would think isn't the ideal place?
fireaza wrote:
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.
Brand isn't a big deal. I've used Atmel and ST parts before as well, I know Nintendo used NEC parts for various things in their consoles. Also, something to consider is if you only need 4 or 8Mbit, check out the SST39SF040 by Microchip. It's a 5V x8 parallel flash ROM in a 32 DIP or TSOP package that's still in production. It's basically the only one I know of that's still in production, most have gone to 3.3v, and it's even hard to find x8's period (thankfully there are a few selectable x8/x16's like Micron's M28W/M29W line).
As far as doubling up the file to fill the ROM, maybe I can help explain that. Think of the address lines as though they were switches. Take the highest address line and if you turn it on, you are pointing at the "top" half of the ROM and if it's off, you're pointing to the "bottom" half. Now go to the next highest line and if it's on, it points to the top half of the half selected by the highest address line, if it's off, the bottom half. You keep doing that all the way until you've switched all of your address lines the way you want and you've cut it in half enough times that now you're pointing at a single byte. Now, imagine that you're using a 16Mbit game on a 32Mbit ROM. You want the highest address line to always be off because nothing should be in the top half of the ROM. However, depending on how the chip is wired in, that address line might not be pulled to ground. If an input pin is not connected to anything, it is what is called "floating", which means it is susceptible to EM interference in the air and will appear as though you are rapidly flipping the switch on and off and you can't guarantee which it will be at any given moment. So, if you duplicate your ROM so that you have the same data in both the bottom and top half of the chip, it won't matter whether that high address line is on or off, it will read the same data regardless. The other option is to just guarantee that the high address line is always off, which is easy to do (connect the pin to ground), but if you're only putting a single ROM file on the chip anyway, why not fill it just to be safe? It's simple when you have ROMs of powers of two because of the way the address lines "cut it in half" over and over, it's a bit more complex with 12/24/28Mbit ROMs because they aren't powers of two and don't line up with the "halfway mark" so you first have to copy a small part to fill it to that point, then duplicate the entire thing from there. Does that help at all?
qwertymodo wrote:
fireaza wrote:
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.
Brand isn't a big deal. I've used Atmel and ST parts before as well, I know Nintendo used NEC parts for various things in their consoles. Also, something to consider is if you only need 4 or 8Mbit, check out the SST39SF040 by Microchip. It's a 5V x8 parallel flash ROM in a 32 DIP or TSOP package that's still in production. It's basically the only one I know of that's still in production, most have gone to 3.3v, and it's even hard to find x8's period (thankfully there are a few selectable x8/x16's like Micron's M28W/M29W line).
Is
THIS the chip you're talking about? I notice it's an eeprom, while the 8 megabit chip I was looking to use is an eprom, it's safe to mix eeproms and eproms right? Also voltage? Does the voltage requirements of eeprom/eproms very?
qwertymodo wrote:
As far as doubling up the file to fill the ROM, maybe I can help explain that. Think of the address lines as though they were switches. Take the highest address line and if you turn it on, you are pointing at the "top" half of the ROM and if it's off, you're pointing to the "bottom" half. Now go to the next highest line and if it's on, it points to the top half of the half selected by the highest address line, if it's off, the bottom half. You keep doing that all the way until you've switched all of your address lines the way you want and you've cut it in half enough times that now you're pointing at a single byte. Now, imagine that you're using a 16Mbit game on a 32Mbit ROM. You want the highest address line to always be off because nothing should be in the top half of the ROM. However, depending on how the chip is wired in, that address line might not be pulled to ground. If an input pin is not connected to anything, it is what is called "floating", which means it is susceptible to EM interference in the air and will appear as though you are rapidly flipping the switch on and off and you can't guarantee which it will be at any given moment. So, if you duplicate your ROM so that you have the same data in both the bottom and top half of the chip, it won't matter whether that high address line is on or off, it will read the same data regardless. The other option is to just guarantee that the high address line is always off, which is easy to do (connect the pin to ground), but if you're only putting a single ROM file on the chip anyway, why not fill it just to be safe? It's simple when you have ROMs of powers of two because of the way the address lines "cut it in half" over and over, it's a bit more complex with 12/24/28Mbit ROMs because they aren't powers of two and don't line up with the "halfway mark" so you first have to copy a small part to fill it to that point, then duplicate the entire thing from there. Does that help at all?
That does help, thanks! I feel a more relieved about using a doubled ROM, but burning a eprom that's made up of a ROM consisting of 4 back halves and 2 front halves of a ROM still kinda freaks me out
I think in this case, I'd definitely go for a 2 eprom configuration, assuming all non-power of 2 games used 2x mask roms
Just to to be sure, would altering the ROM trip the copy protection on games that have it? Take EarthBound's sadistic (it erases your saves at the end boss!) protection, at multiple points, the game checks to see if it's been altered, and the copy protection will spring into action if it has. From what you've described, the game should be reading the same data from the ROM as if there were only one copy in the eprom, but I thought I'd check!
fireaza wrote:
Is
THIS the chip you're talking about? I notice it's an eeprom, while the 8 megabit chip I was looking to use is an eprom, it's safe to mix eeproms and eproms right?
The SST39SF040 isn't an EEPROM, it's a Flash ROM (which, I suppose is technically an EEPROM, but you don't typically call Flash ROMs EEPROMs).
Here's the official product pageThat does help, thanks! I feel a more relieved about using a doubled ROM, but burning a eprom that's made up of a ROM consisting of 4 back halves and 2 front halves of a ROM still kinda freaks me out
I think in this case, I'd definitely go for a 2 eprom configuration, assuming all non-power of 2 games used 2x mask roms
fireaza wrote:
Just to to be sure, would altering the ROM trip the copy protection on games that have it? Take EarthBound's sadistic (it erases your saves at the end boss!) protection, at multiple points, the game checks to see if it's been altered, and the copy protection will spring into action if it has. From what you've described, the game should be reading the same data from the ROM as if there were only one copy in the eprom, but I thought I'd check!
I don't know what kind of copy protection different games have, but IIRC the typical check is for a game designed for 64K SRAM to check if 256K SRAM is present because many copiers contained that much SRAM (in order to support games that used 256K) and if it detects that there is in fact more than 64K, it assumes you are using a copier and that triggers the copy protection. Doubling the ROM will not affect this. The game will have no way of detecting it. It would be the same if you grounded the high address lines or doubled the ROM or whatever. I don't know of any copy protection that could possibly be triggered by a larger ROM as long as the upper address lines are properly dealt with. You technically aren't modifying the ROM as far as the console is concerned (as long as you do it right).
qwertymodo wrote:
fireaza wrote:
Is
THIS the chip you're talking about? I notice it's an eeprom, while the 8 megabit chip I was looking to use is an eprom, it's safe to mix eeproms and eproms right?
The SST39SF040 isn't an EEPROM, it's a Flash ROM (which, I suppose is technically an EEPROM, but you don't typically call Flash ROMs EEPROMs).
Here's the official product pageOh, I thought flash ROMs were eeproms since they're electronically erasable, thanks for the clarification! Either way, is it OK to use a mix of flash ROMs and eproms? And it will require the two crossed wires, just like the 27C801 correct?
And I may have ninja'ed you with that edit I made to the previous post, but what's the deal with voltage on eproms/eeproms? Is this something I should be checking when I'm looking at chips?
qwertymodo wrote:
I don't know what kind of copy protection different games have, but IIRC the typical check is for a game designed for 64K SRAM to check if 256K SRAM is present because many copiers contained that much SRAM (in order to support games that used 256K) and if it detects that there is in fact more than 64K, it assumes you are using a copier and that triggers the copy protection. Doubling the ROM will not affect this. The game will have no way of detecting it. It would be the same if you grounded the high address lines or doubled the ROM or whatever. I don't know of any copy protection that could possibly be triggered by a larger ROM as long as the upper address lines are properly dealt with. You technically aren't modifying the ROM as far as the console is concerned (as long as you do it right).
That makes sense, thanks! Upon further reading, the protection I mentioned earlier all ties back to attempting to defeat the code involved in the first layer of copy protection (if there's more SRAM than there should be) if you haven't altered that code (which would be unnecessary if you're using the original SFC version of the game as the donor), then you should be sweet.
*EDIT* On the subject of ROM padding, I've been pointed to
THIS PROGRAM. It looks pretty good to me! Thoughts guys?
EEPROMs were around before Flash technology, so Flash ROMs are usually considered a separate technology. EEPROMs run on 5v, where most Flash ROMs run on 3.3v. Converting a 3.3v ROM to work with the SNES (which expects 5v logic) is a real pain. However, there are a few 5v Flash ROMs (the AM29F032 being one of them, the SST39SF040 being another), just most have become obsolete in favor of the 3.3v ones. For the most part, you won't be able to use a 3.3v ROM for the SNES. You also won't be able to use an x16 ROM (so be careful there, I've made that mistake. For instance the vast majority of Microchip's parallel Flash ROM lineup is x16). I'm not sure about mixing Flash and EEPROMs, but I think it should work so long as both ROMs are faster than 120ns (the speeds shouldn't have to match so long as both are fast enough). I managed to pick up a lot of 10 AM29F032's for $40 shipped, so honestly to me it's just easier to use them rather than messing with other ROMs (at least for now... I'm in the process of trying to make a currently in-production 3.3v ROM work so I don't have to keep sourcing obsolete parts, but that's down the road a ways...).
As far as the wiring, be sure to check (and double/triple check!) the datasheets for the relevant pinouts. Just connect the correct signals together and you'll be fine.
Thanks for the info!
qwertymodo wrote:
You also won't be able to use an x16 ROM (so be careful there, I've made that mistake. For instance the vast majority of Microchip's parallel Flash ROM lineup is x16).
x16? Like, 16 bit or something? That's not a term I'm familiar with (unsurprising, since I've only just recently looked into how to make SNES repros
)
qwertymodo wrote:
As far as the wiring, be sure to check (and double/triple check!) the datasheets for the relevant pinouts. Just connect the correct signals together and you'll be fine.
Does the wiring occasionally change? I was kinda hoping it would always be in this position:
Yes, the wiring is different depending on the chip used. A lot of the chips use standard pinouts, but even then, the "standard" pinout can be different depending on the capacity of the chip (in the case where you have 2 different capacities with the same pin count). Check the datasheets and compare them to the relevant
ROM pinout. Any pins that match up can be soldered in straight. Any that don't need to be lifted and rewired to match. Also, any input pins that exist in an EEPROM/Flash ROM but not in a Mask ROM (/WE is the only one I can think of) also need to be lifted and tied either to GND or to VCC (for instance, /WE should go to VCC to disable writing to the ROM once it's been programmed).
Also, be sure whether or not the address and data pin numbers are indexed from 0 or from 1 (basically whether or not there is an A0/D0 pin), and (for single supply voltage diagrams) Vcc=Vdd, Vss=GND
qwertymodo wrote:
Yes, the wiring is different depending on the chip used. A lot of the chips use standard pinouts, but even then, the "standard" pinout can be different depending on the capacity of the chip (in the case where you have 2 different capacities with the same pin count). Check the datasheets and compare them to the relevant
ROM pinout. Any pins that match up can be soldered in straight. Any that don't need to be lifted and rewired to match.
Okay, so let me get this straight. The mask ROMs in a SNES cart are consistent (I could only find two sets of pin outs, one for 32 pin, the other for 36 with the note of "This seems to be consistent with all their mask ROMs" on that site you linked to) however this may differ depending on what eprom/eeprom you choose, in which case, you would need to compare the design? In that case, does the design of a particular eprom (say, a 27C801, which requires the wiring in the above photo) stay consistent, even between brands?
qwertymodo wrote:
Also, any input pins that exist in an EEPROM/Flash ROM but not in a Mask ROM (/WE is the only one I can think of) also need to be lifted and tied either to GND or to VCC (for instance, /WE should go to VCC to disable writing to the ROM once it's been programmed).
Okay, so normally both the mask ROM and an eprom would both have data pins, but on the rare occasion, you'll find games that that used mask ROMs that don't have these data pins? In this case, would the mask ROM have less pins?
qwertymodo wrote:
Also, be sure whether or not the address and data pin numbers are indexed from 0 or from 1 (basically whether or not there is an A0/D0 pin), and (for single supply voltage diagrams) Vcc=Vdd, Vss=GND
As with the question in my first paragraph, would whether or not a eprom is indexed from 0 or 1 be consistent between different types and brands? If I had an eeprom that I knew was suitable, I could continue buying it without issue?
The Mask ROM is always the same. Take a look at that diagram and you'll see that even between the 32 and 36 pin versions, all of the pins are the same except the extra 4 on the one end (you can even see it marked on 36-pin boards where you could put a 32-pin one in instead if you didn't need a large ROM). As far as indexing from 0 or 1, that is purely in the diagrams and making sure you match up the pins correctly (i.e. if one diagram indexes from 0 and the other from 1, then A0 from the first diagram matches with A1 from the second, and so on. Same for the data pins). The only "extra" pins you might find on an EEPROM that don't exist on the Mask ROM are the /WE (write enable, Mask ROMs were read only, so no need for a write enable pin), and maybe a second CE (chip enable, sometimes they would have a CE and a /CE for extra protection during power-up and power-down). Read the data sheet for the EEPROM/Flash ROM you intend to use, compare it to the pinout for the Mask ROM and just connect the dots. Any pins that are in different places need to be lifted and rewired. If there are extra pins or pins named differently, try to figure out what they're for. Also, be aware that pins marked like /PIN or PIN# (the actual symbol "#", not a number) or have a line over the pin name, indicate that those pins are enabled when the signal is low, so keep that in mind with things like /WE (so you need to connect it to ground when you're programming it, but after it's programmed, connect it to +5v in order to disable writing and set it as read-only).
Okay, thanks!
I'd always been curious about that little extra bit where the mask ROMs were soldered in, the markings clearly indicate that it's for a larger mask ROM, but I've never seen on that big being used.