Steven Seagal's Atari ST Web Site



"Dance with the Bits"

  Screen of brags for v3.7.1 (with one of my worst jokes)  
  SCP disk images are very precise, but raw and quite large copies of floppy diskettes made with the Supercard Pro board. Data consist of time between flux transitions (in 25 * nanoseconds), 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.



This is a familiar message by now, when adding support for a new disk image format, and it doesn't work at all because the controller (WD1772) can't find sectors.

  It seemed very complicated because I couldn't find correct sync marks ($4489 MFM code) when looking by myself, and I wondered if there was some low-level magic implied.  

  The computer is smarter than me fortunately, and it found some marks without any bit transformation of any kind. This "ASSERT" showed that it was possible to make sense of the data.  

  So off we go trying to write a flux decoder.

A word of explanation. Times between transitions are expressed in some precise unit (25 nanoseconds) in the disk image. Those translate into microseconds. A normal data sequence on a floppy disk can be seen as a chain of 4, 6, 8 microsecond intervals between bits (ones). The rest is zero. Bits (0 or1) are spaced every 2 microseconds.

So, 4 microseconds means bit sequence 01, 6: 001, 8: 0001.

You add those bit sequences until you have 16 bits, and that's a MFM word, built from right to left, with highest bit coming last.

For example:

4 4 4 4 4 4 4 4   -> 0101 0101 0101 0101 -> $AAAA -> clock = $FF, data = $00.

The MFM rule is that there are '1' clock bits only between two consecutive '0' data bits. It doubles the data rate compared with simpler FM (one '1' clock, one data).


  Now the drive responds. Let's launch the game then...  

  Yes it loads. Of course this is a simple case, the game has a basic protection (one track with 10 sectors instead of 9).

That's why the game was picked, of course. And yet, the same disk proved very useful later in showing that some of my poor "sync" hacks weren't valid. And frankly, once you have one disk loading, the hardest part is done.


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:  
  The game mainly uses an elaborate 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".  

  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.

  Starglider, another game using sector 247.  

  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). It was planned so. Tada!  

Borrowing concepts

  Having made that point, what about supporting all games? This is more complicated. The primitive flux-to-MFM decoder I quickly coded 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 "vague sources of inspiration" of Steem, that of MESS/MAME for the DPLL (digital phase-locked loop), with proper inspection window hopefully 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, that both use sync mark $C2, probably others) run in Steem thanks to their competitor SPS (Kryoflux)!  


Nostalgia for a simpler format...

  As noted by Petari, you get this screen when using a bad copy of Chessmaster 2000 (ST, MSA):  

  How generous! Gives me an idea...  

  Using ProCopy... (not "AmateurCopy", I was being unfair, the sillier versions weren't official, you can see here that command $A0 is used, as it should). SCP disk in A:, STW disk in B:, single sided (which is why images are so big by the way).  

  One of the rare original games that will work as a STW disk image, but it's a nice one (if you like chess, that is).
Guess there will be no more complaints about size of STW files anyway, if you compare with SCP images.

Weak bit of emulation

  Gotta admit it, the "weak bits" protections aren't handled very well yet. For this reason, SSE option 'Hacks' needs to be checked for it to be enabled.  

  Yes, Power Drift loads, but you may need to bash space bar once or twice before it passes the test...

And wait a minute... Bits are drifting because they are weak, aren't they supposed to be powerful in Power Drift?




  Turrican is well protected, the real difficulty here is sector data across the index pulse. Regular drives aren't precise enough, and this is one of the rare cases demanding 2 revs to load in Steem. You would need professional mastering hardware to reliably read/write such an image.  

More screenshots

  Check this thread at AF:

Support in Steem - teaser


Other notes

  - Because some image files are huge, they are loaded in memory track by track, and only if some reading is involved, like in commands seek with verify or read sector.  
  - There's a noticeable delay when the image must be unrarred/unzipped, maybe it would be worse with 7z.
7z isn't supported for the moment.
  - Many (many!) protections are handled without us needing to know zilch about them, the exception being weak bits because of the random aspect to somehow emulate (due to variation in motor speed?)  
  - Contrary to usual, no game downloads available to illustrate the new feature. My web host is most generous, but those files are just too big. Check atari-forum to find some images.  


Previous screen

Next screen

Games (1) (2)

Demos (1) (2) (3) (4)



Other downloads