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?

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.

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

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.

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

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.

Who is online

Users browsing this forum: Bing [Bot] and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum