SaGa 3 DS - Two Different ROMs?

[Josephine Lithius]

Hello.  It's me again.

I've been interested in playing through the Nintendo DS game, SaGa 3: Rulers of Time and Space - Shadow and Light, for a while now.  Today, I decided to finally pursue this interest.  However, I ran into a small problem.  It seems that the "common" ROM file for the game is not compatible with the translation patch available on this site.  Upon further research, I eventually managed to find that there are two different game ROMS floating around out there – one of which seems to be the one that the translation group "Crimson Nocturnal" used:

"Original" ROM SHA-1 (2011? dump): 03AF60486CEA050F8E3394D4617A097FD5DE31C9
"Common" ROM SHA-1 (2018? dump): 4569D24295FCC37EFA3F6F9C98C4AAFEF40625B8

So, yeah.  Just figured I'd mention this.  It really came as a surprise to me because I thought the ROM dumping community was done with this "alternate dumps" thing back in, like, 2014 2013.  Heh heh.

Cheers.

[FAST6191]

Pointless redumps strike again it seems...

General idea.
For many years part of the header was blank in DS ROMs.
Following the release of the DSi then said area was used to house a RSA signature for all games released after that point. The original dumper methods would still work but the RSA area was blank, this is what many Scene groups used.
When this extra data was accounted for with a new dumper it obviously changed the ROM. Thus we got an avalanche of redumps, which will technically closer to what is on the cartridge (there is still some hidden data).

However no ROM hacker cares about this extra data, no emulator cares about this extra data, no flash cart cares about this extra data, no custom firmware on a 3ds or whatever cares about this data. It is entirely possible the rest of time will happen and nobody at all will care about this extra data (the only scenario is some pointlessly hyper accurate emulator or hardware recreation).
no-intro however have it as their mission to create the most accurate to the cart dumps that can be done with present hardware/techniques so here we are. This is what most of the torrent and possibly usenet set will find, what is available from good old HTTP/file lockers/FTP/whatever varies dramatically.

If it is the original version that is sought you could possibly blank the area in question and create it. If it needs the pointless RSA signature stuff then not much you can do there yourself -- theoretically you could force patch it as it is unlikely it needs the data to work (patching is much akin to compression and references other aspects of the file) but not many tools will bypass an incorrect entry these days, and if you have both versions of the ROM you could make a patch to go from one to the other but that seems pointless for you (the original patch makers or some other kind people might make one though, we saw similar for GBA when that saw something kind of similar). On the Wii they do have various bits of data like this to regenerate variously altered ISOs but nothing like that for the DS at present.

Also re: 2014. I realise it was a random choice from frustration but to be a pedant I do have to note the original release was 2011 (early on as well) and the redump was March 2013.

[KingMike]

And I imagine there will be another effort to redump the whole set if someone finds a way to dump/recreate the remaining hidden area.

We've already seen it with the FDS, with a few people a decade ago bought and dumped sealed games to get more accurate dumps (even though the missing data had no data useful to probably anyone).

I'd be for having more accurate dumps.
And especially about GBA. As I understand, there entire initial mission was to remove the cracktros from games. Which as I understand, cracktros were largely a "we were the first to dump this on the Internet" thing.
I can understand if someone wants to preserve those cracktro versions as some kind of historical thing, but otherwise I'd prefer the game as the developers/publishers made it. The tools were out there since the GBA was still current for anybody to buy and dump a game. Nobody cares who was first. Now something like NES that required some effort (to like RE mappers and such).
The demo coders could release their demos as their own work, if they wanted to show it off.

[Josephine Lithius]

Ah.  It's one of those cases, again...  I mean, yeah?  I'm honestly for "100% accurate dumps" and all... but to me, all that really matters is the game ROM content, not a 1:1 dump of every single byte of data.  Like, every single NDS ROM I've come across has that filler / spacer data at the end of it that's just full of thousands of $𝙵𝙵 bytes.  Sometimes, this actually fills more than half of the ROM file.  I don't care for it and most emulators – or even real hardware – doesn't seem to care about it.  But to be fair, almost all ROMs are like that.  It's just much more noticeable on a 64-megabyte Nintendo DS ROM than it is on a 512-kilobyte NES ROM.

Also...

The demo coders could release their demos as their own work, if they wanted to show it off.

This, I want.  Someoone should compile every single crack-tro into one big demo with a sortable table – "by release order", "by group", "by game name", et cetera.  I freaking love demoscene stuff.  Just... not in my games, be it Amiga, Game Boy Advance, or otherwise.  I just wanna play the game!  Heh.

[FAST6191]

More than half?
I have certainly had those that just tip over the limit to the next size, and even a few with some serious padding inside the files (Tetris DS had several megs after the sound file for the European version I think it was) but not seen any on the DS that could go a size down.

On trimming (removing the padding at the end of ROMs) DS ROMs if I am continuing with the actually in this case not so pointless info then I will note there are three types of trimming.
1) GBA style/classic trimming. Go to end of ROM, work backwards until you find something that is not 00 or FF, delete all after that. Did actually have a few problem games doing this on the GBA (one of the teenage mutant ninja turtles games).
2) Header guiding trimming. Unlike the GBA then there is a value in the header indicating the file size of the ROM, go to there, delete accordingly.
3) Safe trimming. For reasons unknown then various download play I think it was (if not then wifi) did not want to work if 2) or 3) was in play so 2) and add a bit more for safety.


On demoscene if people are interested in that then
https://www.pouet.net/prodlist.php

For intros themselves being made standalone it was a process usually called drawing. GBATA on https://no-intro.org/tools.htm can attempt it though some might need to be a bit more manual
I do occasionally see some collections of those, indeed the "public domain" ROM collections (homebrew was a term that rose to prominence during the GBA lifetime) often feature them but I have no idea how many of those are still live today. You could probably figure out what needed doing by playing on http://www.advanscene.com/html/dbsearch.php (anything that got a pure patch is a candidate for something here, though some will actually be redumps), and the goodtools lists might have something you can figure out stuff from as well.
Though for those still not amused by GBA intros then I am obliged to link
https://www.youtube.com/watch?v=RAeAkwSK5fw

It did get more complicated when they also made trainers that went with such things. I think there might also have been a cracktro released as a separate patch within the ROM but that might have been the DS instead. I do also have to note that for a later ROM with intro then the CRC32 (what most ROM indexing tools used at the time) was forced to match the stock one which I found amusing.

As far as the FDS stuff that I can kind of see but as floppy disc that wrote data to itself that makes things different, though I also can't imagine any games ever did any kind of permanent alterations based on play as that would actually be cool (some board games did this such that you change the board/rules in effect via multiple play sessions) so instead you are probably just blanking a save file/wiping a high score table.