It is currently Thu Dec 14, 2017 7:45 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 31 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Thu Nov 17, 2005 1:27 am 
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?


Top
  
 
 Post subject:
PostPosted: Thu Nov 17, 2005 1:33 am 
Offline
User avatar

Joined: Mon Jun 06, 2005 12:47 pm
Posts: 67
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 17, 2005 9:16 am 
Offline

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 17, 2005 9:26 am 
Online

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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Nov 17, 2005 10:44 am 
Offline
User avatar

Joined: Mon Jun 06, 2005 12:47 pm
Posts: 67
Did Nintendo make the boards for the Sufami Turbo?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 29, 2005 10:33 pm 
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?


Top
  
 
 Post subject:
PostPosted: Tue Nov 29, 2005 10:36 pm 
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? :)


Top
  
 
 Post subject:
PostPosted: Tue Nov 29, 2005 10:45 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Nov 29, 2005 10:51 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 11:34 am 
Offline

Joined: Thu Oct 13, 2005 10:39 am
Posts: 66
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...


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 11:45 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 12:21 pm 
Offline

Joined: Thu Oct 13, 2005 10:39 am
Posts: 66
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 12:42 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
CaH4e3 wrote:
Simple logic - simple description.


It sounds easy until you're faced with the MMC5...

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 1:18 pm 
Offline

Joined: Thu Oct 13, 2005 10:39 am
Posts: 66
I think MMC5 may be emulated independantly as it is. ;) One mapper instead 255 is better huh? ;)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 30, 2005 1:38 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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