From the newsgroup:
Subject: CHDs in a nutshell From: Roman Scherzer email@example.com 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.
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.
From the newsgroup:
Subject: FAQ-worthy? From: "Sune Mika Salminen" firstname.lastname@example.org Reply-To: "Sune Mika Salminen" email@example.com 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
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: