It is currently Tue Oct 17, 2017 8:16 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Mon Nov 14, 2005 4:40 pm 
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?


Top
  
 
 Post subject:
PostPosted: Mon Nov 14, 2005 5:15 pm 
Offline
User avatar

Joined: Thu Oct 21, 2004 4:02 pm
Posts: 210
Location: San Diego
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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 14, 2005 5:35 pm 
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. :/


Top
  
 
 Post subject:
PostPosted: Mon Nov 14, 2005 9:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19086
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 14, 2005 10:51 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 14, 2005 10:55 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 1:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19086
Location: NE Indiana, USA (NTSC)
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".


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 4:30 pm 
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.


Top
  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 5:01 pm 
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"...


Top
  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 5:01 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 6:29 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 7:24 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
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)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 9:24 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19086
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 9:28 pm 
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"...


Top
  
 
 Post subject:
PostPosted: Tue Nov 15, 2005 10:55 pm 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 615
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 31 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group