Browsing TOSEC I always find rom variants of games... "why" ?

By friguron

Master (169)

friguron's picture

06-02-2020, 11:30

Hi,

The other day, while browsing the TOSEC MSX rom database (for some random project I'm dealing with), I came accross "Goonies.rom" (it's an example). What have I historically found for this (and MANY other) games? That there are many variants for the same rom.

For this case (The Goonies), I could see there are 3 variants, all of them JP, one just "pure name", and then some [a] and [a2] versions.
Where and why do these [a] and [a2] versions appear? Are they betas/alphas/random dumps? Are they region modified versions (don't seem to)?

I compared byte to byte some of these 3 different .rom files and you can only find silly LD, HL XXXX substitutions for NOP's, and such... but not much more (I didn't debug anymore)

Why does TOSEC care about [a] and [a2] versions if they seem some kind of unknown alpha?

Suddenly I had this curiosity attack. Greetings.

Login or register to post comments

By gdx

Prophet (3811)

gdx's picture

06-02-2020, 11:49

[a] is for alternate version. This is used for versions whose number or origin is not known.

By sdsnatcher73

Paragon (1195)

sdsnatcher73's picture

06-02-2020, 20:01

You can find the entire explanation in the TOSEC naming convention. The [a] releases are all original game dumps, from the linked page:

Alternate - [a]

An alternate ORIGINAL version of another ORIGINAL image, e.g. if a game was released, then re-released later with a small change (and the revision/version number is not known).

By eimaster

Master (236)

eimaster's picture

07-02-2020, 01:52

sdsnatcher73 wrote:

You can find the entire explanation in the TOSEC naming convention. The [a] releases are all original game dumps, from the linked page:

Alternate - [a]

An alternate ORIGINAL version of another ORIGINAL image, e.g. if a game was released, then re-released later with a small change (and the revision/version number is not known).

If a game re-released with big or minor changes then why we don't find any difference in the game play between all of the variants?
If the change was about fixing some bugs then it should be known as an update so it's better than the old bugged one.
If the change was about adding new levels or increasing/decreasing difficulty level or adding new spirits then it should be known as a new game which is next in a sequel.
If it changes nothing of the above then why the hell did they had to make such ridiculous changes which is only considered wasting of their tine and energy?

By sdsnatcher73

Paragon (1195)

sdsnatcher73's picture

07-02-2020, 05:34

Well we cannot know with certainty why these variations exist. We know Vampire Killer has had some bug fixes (but which release is the ‘latest’ with ALL the fixes, I would not know). Many bug fixes may involve issues on certain MSX models only and the fix would normally not impact game play, just make the game playable on those machines. The true nature of the fixes could only be identified by disassembling the code and compare the change (and that way also identify which version is the fixed one).

We do know some games were released by different companies (some Konami games were released also by Sony and Casio).

By gdx

Prophet (3811)

gdx's picture

07-02-2020, 08:50

eimaster wrote:

If a game re-released with big or minor changes then why we don't find any difference in the game play between all of the variants?
If the change was about fixing some bugs then it should be known as an update so it's better than the old bugged one.

Admitting bugs implies a recall of the games already sold without discussion even if the warranty is over.

eimaster wrote:

If it changes nothing of the above then why the hell did they had to make such ridiculous changes which is only considered wasting of their tine and energy?

By fixing bugs in the shadows, this limits possible complaints. Only customers who come to complain before the end of the warranty will be entitled to an exchange. It costs less than a massif recall, especially if these issus only occur on certain MSX models.

By eimaster

Master (236)

eimaster's picture

07-02-2020, 18:17

I just came up with a new idea of a possible cause of game variant which does not actually differ in source code but differs in the resulting machine code. If a game's source code was assembled/compiled using an X assembler/compiler and after some time the developers decided to re-assemble/re-compile the same source by another more enhanced assembler/compiler which may produce a more optimized machine code resulting lesser or faster codes or both. Isn't it a possible cause?

By rderooy

Paladin (686)

rderooy's picture

07-02-2020, 19:15

It could be, but I suspect it could also be a result of the way the ROM was dumped. Was it dumped from an MSX (probably different MSX's), or was it dumped with a ROM reader.

Also the MSX TOSEC is rather dated. It is from 2012 and some information that came to light more recently, or more recently dumped programs and games are missing from it. I don't think anyone is maintaining it any longer.

For instance we have clarification on different ROM versions of Antarctic Adventure and Comic Bakery.

By VideoScramble

Supporter (5)

VideoScramble's picture

15-02-2020, 13:48

Hello.
I used to work on some TOSEC sets some 10-15 years ago, when Grendel was running things.
Haven't dealt with ROMs for a long time now, and I'm talking from memory, so might be misremembering things.
I might have worked on MSX. I don't remember to be honest. Definitely worked on some NEC sets.
If I worked on MSX, it must have been just some changes/additions, I certainly didn't start those sets.
State of things back then was like this: You would get ROMs on Usenet/IRC/eDonkey/DirectConnect/eMule/WinMX/FTPs/WWW etc.
China hosted number of big websites, like EmuChina and such. Also Russia.
Typically you would get non-descriptive 8+3 files like zelda.rom or contra.nes. Or there could be foreign characters in names.
Exotic compressions could have been used, like .arj or .lzh
On usenet everything was text encoded.
For www you would use download managers. Sometimes you would have to use proxies to get to some sites.
There could have been number of issues with downloads - files could get corrupted.
It was a mess.
TOSEC was an effort to make sense of all this chaos.
It was not dumping project, however. There might have been relation with Amiga dumping scene, I sort of remember Amiga being constantly updated but might be wrong on that.
TOSEC was volunteer project. Guys would come along and ask "hey what about this system or that?" and typical answer would be "yeah, nobody is working on it now, you can take it on if you want". (If project is still active I'm pretty sure you can get things added to MSX, if you get in contact with them.) Thing with that though is - its not like open source programming project - there's no skill check, you just need basic understanding of how to work with files. So you're often just a guy with files trying to catalogue them within this naming convention. Still, if sets weren't updated for almost a decade, looks like even that is too much to ask then.
Also TOSEC, like many later projects (no-intro,Darkwater,redump) uses full file checksums. At the time there was also this other project going - Cowering's GoodTools. Cowering's tools took file structure into consideration and calculated checksums only on relevant parts (presumably skipping headers/footers/dealing with endianness and such), so you could have files with different CRCs which would yield same result for GoodXXX set. I think he also dumped ROMs himself. Guy knew what he was doing. If ROM is marked [b] -bad in GoodXXX set it probably is a bad dump, if its [h] -hack - probably is a hack. In TOSEC you don't know. There's often nothing to base your decision upon. You just have 2 different files. Both named zelda.nes. You got one from Usenet, other from IRC. You don't know if it's hack or bad dump or overdump. So what do you do? You tag one as [a]. So [a] could be new version with bug fixes or it could be bit flips caused buy glitchy connection while downloading from China.
So I was working for TOSEC some time now while also messing with GoodTools and I decided to make plugin for one of ROM managers. There were 3 big ones I think, clrMamePro, RomCenter and I forgot the 3rd one. My plugin would ignore meta headers and just calculate CRCs on actual data. And when I fired it up on I think one of NEC PCxx sets, a huge percent of alternatives came up as dupes. I started looking into it and some differences were as trivial as write protection tag in meta. That's when I decided "There's no way. I can't un%#%^ this". There's no means in TOSEC to work with this information - nowhere to document it and nobody will rework hundreds of systems to Cowering's model.
TOSEC was good for what it was - categorizing files you could pull from internet, but to be certain of things you needed dumping+naming+documentation. So I moved to redump.org, which seemed great at the time but since then I moved on from that too, largely because of same issues - lack of documentation and files not being analyzed just CRCs calculated on whole and MAME's CHDs made everything much worse - less documentation for end user and more obstruction to core data. But I digress.