Next Previous Contents

7. Technical Information

7.1 CHDs in a nutshell

From the newsgroup:


Subject:      CHDs in a nutshell
From:         Roman Scherzer no_r.scherzer_spam@t-online.de
Newsgroups:   alt.games.mame
Date:         Tue, 28 Oct 2003 16:17:47 +0100

Ok...looks like people are still a little bit confused about it...so here some hopefully final lines: 
To understand what's the discussion is all about you first have to know how a chd looks like.

Basically it's this:

header + sectormap + (compressed) blocks

The header contains information about the md5 of the original, not 
compressed harddiskimage, sectornumbers, heads, etc.
The sectormap holds information about offset and size of each 
(compressed) block. Like Block 42 starts at offset 1384712 and is 1231 
bytes long. The rest of the chd contains the (compressed) blocks. 
Brackets around 'compressed' because you can also use not compressed images.

In the standard chd, the sectormap looks similar to this table:

Entry 1 -> offset and size of Block 1
Entry 2 -> offset and size of Block 2
etc.

So you got different offsets for different blocks.

The "optimization" of ReCHD, SmallCHD and some versions of hdcomp is this:

If Block x and y are the same, i.e. contain the same data, store only x 
and modify the sectormap so that the offset/size entries of block y 
point to x. So you got a sectormap with entries for each block of the hd 
but you only store unique blocks.

Example:
Entry 1 -> offset and size of Block 1
Entry 2 -> offset and size of Block 2
Entry 3 -> offset and size of Block 3

that's like above...now assume Block 1 and Block 3 contain the same 
data. So the new sectormap can me modified to this:

Entry 1 -> offset and size of Block 1
Entry 2 -> offset and size of Block 2
Entry 3 -> offset and size of Block 1

...and the data for block 3 doesn't have to be stored, since it's equal 
to block 1. So Entry 1 (belonging to block 1) and Entry 3 (blick 3) 
point to the same offset in the compressed data.

For reading/storing chds that's definetly ok, since the blocks are 
equal!!!!!!!!! So it's clear that you can reconstruct the original raw 
image from it. Programs like BigCHD and hdcomp can also create a not 
modified chd from it.

Now what's the discussion all about you might ask. Well... The problem 
is WRITING to a chd.
Assume MAME writes to chd files. Look at the example above where Block 3 
and Block 1 point to the same offset within the compressed data. Writing 
something to block 3 would erase the data of block 1 and viceversa. You 
would definetly kill your image that way.

MAME writes data to socalled difffiles. Difffiles are chdfiles. The same 
structures are used.
The discussion is, is it possible that blocks get overwritten due to a 
modified sectormap.

Aaron said he didn't think about the 'optimization' in the 1st place and 
  so it's more secure to keep the standard chds...and I guess he's too 
busy with reallife/other projects to do some real verification.
Well...take harddisk.c/hdcomp.c from the MAME source, check the 
routines. You'll see that difffiles will use a not-modified version of 
the sectormap. So in my opinion, it's safe to keep the 'small' chds. It 
would be fatal for non-difffile-creation of course.

"People reported issues!" you might have heard.
Well...you heard something like some hdbased games have slowdowns.
People forget that the emulation core has changed, too. Especially 
harddisk.c. So a slowdown can be caused by this. Another thing is that 
with a modified sector map you'll change the order of contious blocks as 
long as they are equal. So your hd will have to do more seeking 
operations which may result in a small slowdown on modern HDs but may 
cause a slightly bigger one on old, slow HDs which don't cache data in 
that way.

You might heard rumors about the Beatmania 1st remix chd...
...the rumors are wrong. Correct is that the 'small' chd from it failed 
the beatmania hd checksum check. The big one failed too. The problem was 
caused by some older version of harddisk.c. It works fine in MAME 76u1 
(and higher..though it's marked 'bad' in u1).

Hope this may answer some questions.
      

7.2 Why don't my old CHD files work with MAME anymore?

For version 0.78 and above, the CHD format was changed, and any CHD files that were being used in versions 0.77 and below need to be updated.

To do this, you will need the "chdman" tool, which replaces the now defunct "hdcomp" tool. The chdman.exe file comes with the standard MAME binary zip file which you can find at http://www.mame.net/downmain.html.

Before doing any updating, make backups of the CHDs if you can, should anything go wrong when the updating takes place.

For most of the chd's you simply need to convert them with chdman. As an example, we will look at the steps to convert the chd file for "Killer Instinct" which is "kinst.chd". (This assumes you have placed the chd file to convert in the same directory as the chdman tool.

First, rename the file "kinst.chd" to "kinstold.chd"

Use chdman to update the chd by using the command "chdman -update kinstold.chd kinst.chd" This will generate a new updated "kinst.chd" file in the same directory.

Check the new file has been created in the directory, and then delete the old version, "kinstold.chd".

Finally, move the new updated file back to its correct place, the "kinst" directory, if you moved it from there to carry out the update.

7.3 What are XOR files?

From the newsgroup:


Subject:      FAQ-worthy?
From:         "Sune Mika Salminen" efternavn@doktor.dk
Reply-To:     "Sune Mika Salminen" efternavn@doktor.dk
Newsgroups:   alt.games.mame
Date:         Thu, 30 Oct 2003 15:29:01 +0100

Snagged this one off of the mame.net general board. I thought it would
be nice to have in the AGM FAQ, just for completions sake, it's a very
nice explanation i think:

Q: What are XOR files?

A: They are files that contain data that when XOR (Exclusive OR [See
Below]) produce decrypted code. These are used when the ROM gets
decrypted by MAMEdevs or a decryption team, but the algorithm is
unknown, and allows the original encrypted dumps to be used with MAME.
Capcom Play System 2 (CPS2) games [ex. Street Fighter Alpha Series,
Dungeons and Dragons Series, Puzzle Fighter II Turbo, X-Men COTA, etc]
commonly use these tables to be run in MAME, Final Burn, Nebula, and
other emus.

The XOR Gate:

A B Out
0 0 0
0 1 1
1 0 1
1 1 0

Another Unique factor of the XOR:

if A XOR B = C, the the following is true:

B XOR C = A
A XOR C = B

So in the case of encrypted ROMs, it works as follows

E = Encrypted Data
D = Decrypted Data
T = XOR Table

E XOR D = T - Creates Table

E XOR T = D - for real-time decryption at game runtime.

(contributed by StephenH)

-Sune
      

7.4 How do I compile MAME From source code?

If you do not know how to "re-compile" or what that means don't ask, alt.games.mame is NOT a computer programmig newsgroup. There are plenty of newsgroups that deal with such topics, try news://comp.programming. If you have a problem SPECIFIC to compiling MAME then, and only then, is alt.games.mame a valid place for the question.

Some links to sites about MAME compilation:


Next Previous Contents