If I wanted a true UNIF dump, would it be better to convert the iNES header into UNIF with ucon64, or should the ROM just be redumped into UNIF? Does this make a difference?
You don't necessarily need to re-dump the game. Assuming that the iNES version you have is a good dump, there's no reason to re-dump. However, UNIF has a lot more metadata about the game in it than iNES so you need to add that in somehow. I am unfamiliar with how ucon64 does this, since the info you need (bard name etc.) is not available in the .nes file. Maybe it has a database of games it uses?
teaguecl wrote:
the info you need (bard name etc.) is not available in the .nes file. Maybe it has a database of games it uses?
Well,
here is a list that tells which games use what board table. Not all games are listed though. :/
I was just wondering if there is a difference, however subtle, in an iNES->UNIF converted dump and a redump in the UNIF format. I guess as long as you have the same header data, they will be the same.
I know that Low G Man had to be redumped into UNIF for it to work properly (converting to UNIF doesn't work), so that's what confuses me. :/
Anonymous wrote:
I know that Low G Man had to be redumped into UNIF for it to work properly (converting to UNIF doesn't work)
Low G Man relies on open bus in the area normally used for cart WRAM. It needed a conversion followed by some manual edits to the header in order to work. In fact, such a manual review of the header is strongly recommended for all conversions from iNES to UNIF, as iNES's board type specification is usually far too coarse to represent what is actually on the cart PCB.
I am too lazy to open my Low-G-Man cartridge right now, but as I recall it is nothing more than a standard TLROM cartridge. However, TLROM does not contain S-RAM, but iNES doesn't make a separate provision for carts that have S-RAM and those that don't unless the S-RAM is battery backed. To the emulator, it sees writes to the 6000-7FFF range and assumes that S-RAM should be there like it usually is.
With UNIF, the problem should not require any "tweaking", just a strict adherence to board types. TLROM = No W-RAM/S-RAM; TSROM = 8KB of W-RAM/S-RAM; TKROM = 8KB of W-RAM/S-RAM battery backed. Of course, unless the emulator can emulate an open bus, the significance of this distinction isn't meaningful.
The important information about a cartridge is the mapping hardware and arrangement, and the PRG and CHR data. iNES reliably stores the latter; it's the mapping hardware that you might need to fill in when converting to UNIF.
Great Hierophant wrote:
TLROM = No W-RAM/S-RAM; TSROM = 8KB of W-RAM/S-RAM; TKROM = 8KB of W-RAM/S-RAM battery backed.
And a strict "conversion" from iNES would result in TSROM or TKROM depending on the battery bit. The specific header editing in this case would involve replacing "TSROM" with "TLROM".
Thanks for all the info, everyone.
A couple more questions:
Ideally, should UNIF headers have mirroring set to "controlled by mapper hardware", or should they be specifically set to horizontal/vertical?
Also: Why do NES ROMs actually need headers anyway? Other ROMs, such as SNES ROMs, don't need them and can safely have their headers removed. This is something I've wondered for a long time, actually.
SNES emulators really do need some kind of reformat, but few people are aware of that need.
Overload, of Super Sleuth and Snes9x's DSP project has, in fact, included a db of cart PCBs in his emulator because of this.
Here are examples of why SNES ROMs do need mapping assistance:
Yuuyu no Quiz de Go! Go! (J): internal header claims game is "Mode 21". It won't boot in that configuration.
Ys 3: some versions contain 31 headers, 29 of which are incorrect.
My favorite example:
Ys3: requires sram be given full banks
Lagoon: probably the same PCB as Ys 3, known to map sram to full banks at bank 70 AND bank F0. this one we can document:
Charles MacDonald has it in his snestech doc.
Big Sky Trooper: requires sram in bank F0.
Tokimeki Memorial: requires ROM in places where the above need sram.
try Tokimeki in ZSNES to see the problem these create as a set (ZSNES broke this when fixing Big Sky Trooper). Nearly every emulator either has this kind of bug (or the inability to save Ys3 in bsnes), or uses hacks (Snes9x).
Go look at the number of special-cased mappings in Snes9x.
Tell me again how "SNES doesn't need headers"...
Anonymous wrote:
Ideally, should UNIF headers have mirroring set to "controlled by mapper hardware", or should they be specifically set to horizontal/vertical?
Ideally... they should be set to "controled by mapper hardware" if it's controlled by mapper hardware =P. And set to another option only if hardwired on the cart. If emus are doing things properly, they would ignore writes to mapper mirror regs when mirroring is hardwired and only allow mirror reg writes when it's controlled by the mapper.
Quote:
Also: Why do NES ROMs actually need headers anyway? Other ROMs, such as SNES ROMs, don't need them and can safely have their headers removed. This is something I've wondered for a long time, actually.
I'm actually amazed that SNES ROMs don't need headers. I think they have all the necessary info stored in them already without needing an extra header.
Anyway... the biggest reasons for having a header is to seperate PRG and CHR data. If you have a 256k ROM, how are you supposed to know what the PRG is without a header? it could be 256k PRG and 0k CHR (CHR-RAM) or 128k of each. There's no way to know without a header.
Also, which mapper... any hardwired mirroring... is the SRAM battery backed... that kind of thing.
SNES games generally don't have unusual hardware. There are only 50 or so titles that use special or custom chips. The rest multiplex S-RAM and thats about as complex as it gets. Basically, for a normal SNES cart, you only need to know:
FastROM or SlowROM;
LoROM or HiROM;
Amount of Battery Backed RAM, if any, generally 2, 8 or 32KB.
ZSNES and SNES9x can auto-detect these settings or use CRC databases as can emulators for the Atari 2600 and the Sega Master System/Genesis.
That works perfectly for the T*ROM series but not for the S*ROM series.
Here are the board differences:
SAROM = 128KB PRG (28-pin), 64KB CHR, 8KB S-RAM or W-RAM
SBROM = 128KB PRG (28-pin), 64KB CHR (28-pin)
SCROM = 128KB PRG (28-pin), 128KB CHR (32-pin)
SEROM = 32KB not banked, 64KB CHR (28-pin)
SFROM = 256KB PRG (32-pin), 64KB CHR (28-pin)
SGROM = 256KB PRG, 8KB C-RAM banked
SHROM = 32KB not banked, 128KB CHR (32-pin)
SJROM = 256KB PRG, 8KB C-RAM, 8KB S-RAM or W-RAM
SKROM = 256KB PRG, 128KB CHR, 8KB S-RAM or W-RAM
SLROM = 256KB PRG, 128KB CHR
SLRROM = 256KB PRG, 128KB CHR (non JEDEC-pinout)
SNROM = 256KB PRG, 8KB C-RAM banked, 8KB S-RAM or W-RAM
SOROM = 256KB PRG, 128KB CHR, 16KB S-RAM or W-RAM thru CHR bit
SUROM = 512K PRG thru CHR bit, 8KB C-RAM banked, 8KB S-RAM
SVROM = 512KB PRG thru CHR bit, 8KB CHR banked, 16KB S-RAM or W-RAM thru CHR bit
Compare with the T*ROM Series:
TEROM = 64KB PRG (28-pin)lose addressing line for EPROM compatibility, 64KB CHR (28-pin), optional hardwired mirroring
TFROM = 512KB PRG (32-pin), 64 CHR (28-pin), optional hardwired mirroring
TGROM = 512KB PRG, 8KB C-RAM
TKROM = 512KB PRG, 256KB CHR, 8KB S-RAM
TLROM = 512KB PRG, 256KB CHR
TLSROM = 512KB PRG, 128KB CHR (32-pin), lose addressing line for bankswitching control
TNROM = 512KB PRG, 8KB C-RAM, 8KB S-RAM or W-RAM
TR1ROM = 512KB PRG, 64KB CHR (28-pin), "4KB" Nametable RAM (4-screen mirroring)
TSROM = 512KB PRG, 256KB CHR, 8KB W-RAM
TQROM = 128KB PRG (28-pin), 64KB CHR (28-pin), 8KB C-RAM
TVROM = 128KB PRG (28-pin), 64KB CHR (28-pin), "4KB" Nametable RAM (4-screen mirroring)
Great Hierophant wrote:
Basically, for a normal SNES cart, you only need to know:
FastROM or SlowROM;
LoROM or HiROM;
Amount of Battery Backed RAM, if any, generally 2, 8 or 32KB.
ZSNES and SNES9x can auto-detect these settings
How? A lot of games that come with 2 KB try to use 32 KB and then crash with an error message if the full 32 KB is present (not mirrored).
Quote:
or use CRC databases as can emulators for the Atari 2600 and the Sega Master System/Genesis.
CRC databases of commercial games used to control mapping don't leave any option for homebrew programs to add their own titles other than by forging a commercial game's CRC (which is trivial and has always been trivial, but that's beside the point). Anything that hurts homebrew while helping pirates is despicable in the eyes of the law.
SNES games don't have "unusual hardware", they have "a wide variety of quirks that are known to cause glitches and problems".
Example: Demon's Crest and Megaman X require proper mirroring to avoid copy protection. But proper mirroring is hardly the same between ROMs in the same general class.
For example, ROMs arranged in 32K chunks... may or may not mirror ROM within a bank. Some do, others do not. There is no internal signal that specifies which is used. Either you can stuff every ROM known to man into an internal database, which is just blatantly a hack, or you can admit they need a real format with real PCB information.
Or take a 12 Mbit ROM. does it mirror to 16 Mbit? or does it mirror to fill memory space? or does it not mirror at all?
And look at Tales of Phantasia, which has 4 possible arrangements of the same data because the raw binary format is totally ineffectual at describing carts that have separate ROMs selected by the A23 address line. That's why for so long, DKJM2 needed a patch to run: it has just 1 internal header, where ToP has two.
Look at PCB SHVC-1J3M versus SHVC-2J3M, and tell me how an emulator can distinguish between the two boards for a 16 Mbit ROM. Notice the fact that there's a "huge" difference in how 256K of address space is handled.
Compare ROM mirroring on SHVC-1A5B and SHVC-1A5M. THe boards support the exact same specs, but look about as different as you can get to the SNES.
Unusual hardware is the least of your worries on the SNES. "PCB wiring" is the real problem, and a crc database in the emulator is a "lame" idea. Besides, then if you hack a game to correct a typo, you have to hack the CRC to get proper board support, and that makes "no sense".
If there's anything to be learned here, it's that PCBs rise to the level of "unusual hardware". Especially with the number of games that rely on reading from unmapped areas of the SNES to actually "work"...
Quote:
How? A lot of games that come with 2 KB try to use 32 KB and then crash with an error message if the full 32 KB is present (not mirrored).
You could ask the ZSNES or SNES9x people, but as they display CRC: OK when you start up a game, I assume that they are using a database to determine how much RAM a game requires.
Quote:
CRC databases of commercial games used to control mapping don't leave any option for homebrew programs to add their own titles other than by forging a commercial game's CRC (which is trivial and has always been trivial, but that's beside the point). Anything that hurts homebrew while helping pirates is despicable in the eyes of the law.
Homebrew games, as opposed to demos are few and far between on a NES or above. However, ZSNES and SNES9x do support headers and the major copiers. z26 and Stella allow the user to set the proper bankswitching format for 2600 homebrews if the program doesn't successfully autodetect it and supports it. There isn't much variety among the Genesis, Master System and PCEngine carts, so I would suppose a homebrew author would be best to stay within the available cartridge hardware.
I had no idea SNES PCBs were so complicated, especially when a 65816 can address 16 Megabytes of ROM and RAM. Makes me wonder whether tototek's products are a good buy for those games that don't require a DSP/SA-1/FX chips.
Great Hierophant wrote:
Quote:
How? A lot of games that come with 2 KB try to use 32 KB and then crash with an error message if the full 32 KB is present (not mirrored).
You could ask the ZSNES or SNES9x people, but as they display CRC: OK when you start up a game, I assume that they are using a database to determine how much RAM a game requires.
That is only a verification of the checksum in the header.
Snes9X has a small database of checksums for known bad dumps, but that is only to stop erroneous bug reports. Last time I checked, that was only indicated by displaying the load-time status text in yellow instead of white.
As mentioned above, ZSNES doesn't have perfect solutions for any of that mess. If it did, it would not be breaking Tokimeki Memorial in the name of fixing Big Sky Trooper.
Snes9X doesn't even have to deal with this because it maps SRAM to both 70 and the bottom half of F0. This "just works" for Big Sky Trooper and Tokimeki, but breaks Ys3. So then it hacks Ys3 to make it work.
So, without special casing, any two of those three titles can work in a given configuration. Fun, eh?
Crap, that last one was me. I was about to apply this edit:
The Snes9X source code also says this, in its special casing:
//not MAD-1 compliant
if(strcmp (ROMName, "WANDERERS FROM YS") == 0)
{
for(int c=0;c<0xE0;c++)
{
Map[c+0x700]=(uint8*)MAP_LOROM_SRAM;
BlockIsROM[c+0x700]=FALSE;
BlockIsRAM[c+0x700]=TRUE;
}
WriteProtectROM();
}
At the time when that was written, that is what the developers said. "not MAD-1 compliant", as if there were some "standard" that dictated what sort of hardware you could stick into a cartridge. There never really was anything to stop a developer from sticking whatever the hell they wanted into a cartridge, so long as it exposed reset vector to the processor and could map itself. Then, since they're so clever to be custom hardware, even if it is only slightly different from the "norm", they can write their code to break if someone tries to use a copier that doesn't support their changes. It could be as simple as a few different traces on the board, or a few extra cheap parts.
For normal carts, the most exotic chip would be a MAD-1, which seems to be a glorified demultiplexer like the LS138 and 139 chips it replaced. It doesn't seem like a really difficult challenge to emulate.
So, it seems like SNES emulation really needs a systematic emulation of board types to make games work correctly. A header would need to be added to the ROMs. The real problem is the work involved in identifying the various boards and how they differ from each other. As you can see with UNIF, it has taken years to adopt some of the standard and does not have the support to be a true replacement of the inferior iNES standard.
kode54 wrote:
There never really was anything to stop a developer from sticking whatever the hell they wanted into a [Super NES Game Pak], so long as it exposed reset vector to the processor and could map itself.
Other than the requirement that Nintendo manufacture the games?
Did Nintendo make the boards for the Sufami Turbo?
Another n00b question, I just want to make sure I'm right.
Disch wrote:
Anyway... the biggest reasons for having a header is to seperate PRG and CHR data. If you have a 256k ROM, how are you supposed to know what the PRG is without a header? it could be 256k PRG and 0k CHR (CHR-RAM) or 128k of each. There's no way to know without a header.
If that's true, then...
How did the real NES know how much PRG/CHR data to allocate to run the game properly? I assume that this is just hardwired info that is "undumpable", if you know what I mean?
BTW, I seem to have posted this thread in the wrong forum. I didn't notice that there was a n00b forum. Would someone like to move this thread?
Quote:
How did the real NES know how much PRG/CHR data to allocate to run the game properly? I assume that this is just hardwired info that is "undumpable", if you know what I mean?
Upper bits of bank select registers are ignored, so you get mirrors due to the modulo effect this has. If there are 4 PRG banks, selecting the fifth bank really selects the first one (100 AND 011 = 000). This is also how a dumper figures out how big the PRG and CHR are: keep selecting higher banks until the contents match earlier banks.
Anonymous wrote:
How did the real NES know how much PRG/CHR data to allocate to run the game properly?
The NES does not allocate any memory. Only the 2k of RAM ($0000-07FF) and various areas of VRAM (CHR excluded) exists on the NES. CHR-ROM, CHR-RAM, PRG, and SRAM all exist on the game cartridge... and it's all managed by cartridge hardware (PRG/CHR/SRAM are usually each on their own memory chip, for example).
Unfortuntaly, ROM dumps can only contain software, not hardware... so it's up to headers to give the jist of how the hardware was layed out so the dumped software can be used appropriately.
How about idea for connecting ROM software and hardware info in one file? It may be some sort of microcode, script or asm code for representing mapper hardware all along with ROM data in ROM file (as extended chunk of UNIF format, for example).
Emulator should handle this microcode or run scripts on virtual machine. All mapping work perform that running code.
All roms will be as standalone cartriges, you can fix it or modify for properly working personally, no need to write all mappers support for all emulators... Many advantages...
Emulating hardware is what emulators do... that's what they're for. There's no way to really short-cut that.
What you're basically suggesting is "build an emulator and put it in the ROM, and force all other emulators to work with it".
I think it more likely some sort of script or config file, simple input signals (PPU clock, CPU clock, SL clock), defined operations... Hardware emulated by emulator anyway, but HOW it should be done, described in ROM file...
Emulating mappers it is not emulating... It is simulating non-CPU hardware. Just simple logic. Simple logic - simple description.
CaH4e3 wrote:
Simple logic - simple description.
It sounds easy until you're faced with the MMC5...
I think MMC5 may be emulated independantly as it is.
One mapper instead 255 is better huh?
What about Mapper 90? Or MMC2/MMC4? How about the VRC7's sound hardware (i.e. FM synthesis)?
The other main problem is that this would require duplicating the same mapper code across hundreds of ROMs, and if new information was acquired about a mapper's behavior then every single one of those ROMs would have to be updated (which is largely impossible). This is why mapper logic is kept within the emulators and simply enumerated within the ROMs.
Not to mention this would require building a VM into every emulator... seriously restricting how the emulator operates and limiting the kinds of optimizations emu authors can make... on top of slowing down emulation by bringing it a layer of abstraction higher than it needs to be.
Hardware emulation should definatly be left to the emulator. And yes... emulating mappers is part of emulating. "simulating non-CPU hardware", as you put it, is part of emulation (PPU, APU, controllers, mappers, etc -- everything except for software must be done by the emulator). In fact... "simulating hardware" is pretty much the definition of emulation.