Not that you weren't informed already, but...
I spare you what was already uploaded in that other thread (Chessmaster 2000)
http://ataristeven.t15.org/Steem_371_coming_soon.htm
"Dance with the Bits"
SCP disk images are very precise, but raw and quite large copies of floppy diskettes made with the Supercard Pro board. Data consist of delays between flux transitions, that's it. Contrary to "CAPS" (SPS) formats IPF and CTR and "Pasti" format STX, there's no plug-in to help emulation. The Atari ST emulator is in charge of everything.
Fortunately, Steem is coded in C++ and uses objects for concepts such as floppy disk, drive, controller, DMA chip, etc. The only new part is interpreting the delays as the correct bytes of data, read at the correct rate.
Dungeon Master
SWOOSH! By the way I fixed a little sound bug in 'Sampled YM-2149' option of v3.7.0...
Just like the game itself, the disk protection is interesting and much discussed.
It is precisely described here:
http://dmweb.free.fr/?q=node/1429
The game mainly uses an elaborate and patented (US patent 4849836) fuzzy bits protection. Some bits are shifted to the left or the right compared with normal, and the WD1772 will think they're in the left or the right "cell".
EDIT: now that I actually read the patent, not sure it's the right one
This is handled in Steem by introducing 1-cycle randomness on the timing of those weak bits, and making sure that shifts are balanced (if a bit is interpreted as "early" the next one must be interpreted as "late"). A bit of a hack actually.
Level 2. After a while, the game checks fuzzy bits on sector 7. The CRC check fails, as it should. Fuzzy bits randomly form byte $68 or $E8. If it's anything else, the first gate won't even open for your party.
The second protection, impossible to write sector number 247 ($F7), is very common on the ST.
This sector is checked all the time by the game.
By the way, you should use a STW disk image to format and record progress.
Making a point
The point of offering SCP disk image support in short order, beside making players happy

, is to show that our Steem development roadmap (new STW disk image format and new WD1772 emu to handle it as a timed flow of bytes) was valid. SCP support is an extension of STW support, and it appears as v3.7.1, not as a major new feature (would be 3.8.0). It was planned so.
Borrowing concepts
Having made that point, what about supporting all games? This is more complicated. The primitive flux-to-MFM decoder didn't use any "inspection window" and couldn't really correct for phase and frequency error like the real WD1772. This is why
Starglider didn't work, for instance. Besides, the WD1772 emulation as written for STW support worked with MFM words rather than bits, and was confused with overlapping $C2 and $A1 sync marks.
To win some time to solve both problems (and because I really enjoy hacking), two other WD1772 disk controller emulations have been used as "source of inspiration" of Steem, that of MESS/MAME for the DPLL (digital phase-locked loop), with proper inspection window based on the correct algorithm as described in US patent 4808884 A, and that of CAPS/SPS for the data separator (bit shifter that finds the sync marks).
Better saying so than faking my "own" solution.
Transitions (fluxes) are sent to the DPLL, which sends back timing and bits, bits are sent to the data separator, which sends back data bytes and sync marks. Both parts do their magic without us needing to understand all of it (fortunately).
So you have this situation where some SCP disk images (notably
Albedo;
Jupiter's Masterdrive) run in Steem thanks to their competitor SPS (Kryoflux)!
EDIT: forgot introduction
EDIT: remove DM test request