I don't know if it concerns KF or Steem, but I wanted to open a thread about CTR support into Steem.I've recently imaged a lot of original games into KF/CTR format. Almost all of them work fine, and adding CTR support into Steem SSE was a great idea (thanks KF team for the .dll and Steven Seagal for the support). It's very useful!

But a few of CTR images doesn't seem to work. That's the case of Out Run, for instance. It refuses to boot properly.So I've also converted the RAW stream files (made with KF) into .STX format (with Aufit) = the game works fine.I've imaged the game with two different drives and used another source, since I have both copies of the game = same result. CTR doesn't work, while .STX runs perfectly.

I've also included the SuperCard Pro file into the archive. This one seems to work. Please note I had to image the disk in 'Splice' mode (3 revolutions). The 'index' mode didn't image the disk correctly (at least it didn't start with Steem when it was converted with Aufit into .STX format).

Known problem.It uses a weak bit protection that uses a very specific sequence of FDC commands resulting in reading the same revolutions (and this sector data) twice where it should have read weak bits instead.It wouldn't work from a real disk either, if it read the same data every 5 revolutions The reason it works with other formats (like it would from e.g. IPF) is the weak bit area found after analysis.With CTR you get what you read in 5 revolutions, "played back" like a record as if it were coming from the disk, so no data gets modified - but in this case it should be.I am considering adding support for this case to the CTR decoder, but it must work 100% and very fast (almost real time), otherwise it would mess up perfectly good data randomizing it... which is not something you want to happen This won't be an issue from using stream files.

By the way, Outrun uses TOS function to read sectors and check for the protection, so it's likely that if the game had accessed the FDC directly then it would have used a different sequence of FDC commands and it would have worked with CTR

I develop a free Word (for Windows) add-in that's available for Word 2007 upwards. It's a fix-it toolbox that will allow power Word users to fix document errors. You can find it at: http://www.mikestoolbox.co.uk

Thanks, I already have a full trace of exactly what happens - they sure knew how to confuse emulation 30 years later on There are several versions of this protection compiled from C originally, then at least one later title used assembly code, probably to avoid the need for the C startup code.The FDC command sequence is identical in all of them, only the code differs slightly depending on the compiler used - so it was more than likely added by the duplicator as a generic protection and part of the duplication service offered (many of them offered free copy-protection added to masters). Many original, first releases of Gremlin, US Gold, Atari, Hewson games are affected, so as I said I am looking at whether this can be reliably supported or not - without breaking the legitimate data for other games.

Last edited by IFW on Mon May 12, 2014 10:16 am, edited 1 time in total.

One word could describe this: there is no magic involved at all, it could be described simply as "unlucky" It's simply weak bits, but the order and timing of commands ensures that the exact same revolution is being read twice during the check and that of course always fails for weak bits, since the data is the same from the same revolution sampled...

So if I understand correctly this is purely a simulation problem due to an unusual sequence of FDC command.

I have looked at the track 79 and apparently sector 9 is only 128 bytes long (although it take the room of a 512 bytes sector) and has the data segment mostly unformatted resulting in fuzzy bytes and therefore CRC error.So nothing realy special "from a flux transition point of vue".

npomarede wrote:I confirm that with this new version Hatari devel version can now also run the OutRun CTR dump posted by Brume, as well as RoadRunner for example (which uses a similar protection scheme)

That's great Nicolas, can't wait to test the final version of Hatari!

I've tested the .CTR file of Outrun + Steem SSE + new dll provided by IFW: the game still doesn't work.

About the game, I don't understand what the emulator is supposed to do."Lock track" happens when capsimg calls the callback function, here it locks track 79 only once.Capsimg doesn't call anything when it gets on a new rev.Wouldn't it be simpler if the lib knew how many revs were sampled, or at least did a callback at each IP so the emulator knows what to do?

During track decoding, the library makes note whether a track is constantly changing at each revolution or not and relays this information back to the host.If you are using the WD177x emulator in the library as the host, it would recognize this, and for any affected track would call the track change call back at each index signal passed.So what you describes is exactly what should happen

If that does NOT happen, that means that you did not enable this behavior in the first place - this is useful for analysis tools or writing, not for emulation.

So I think the flags you pass to the load or lock functions say, that you want pure data without change.Could you post the flags you are using?

Hi, I use DI_LOCK_DENALT|DI_LOCK_DENVAR|DI_LOCK_UPDATEFD|DI_LOCK_TYPE on CAPSLockTrack().The image isn't loaded in memory at once in Steem.Each time a track is locked, the previous track (or the same in case) is unlocked just before.

The problem is unlocking a track; when you do that, state information gets invalidated and recreated the next time you lock the track again. The only state a host program would be interested in is the current random seed associated with the track, since you don't want to read the same data twice from weak bits normally

Locking a track can be expensive btw., which is mostly only noticeable if your PC is not very fast, and you try a game that stream audio/video from disk; then you'll notice. The only games I can think of on ST are the ReadySoft games, such as Dragon's Lair.

However, if you still want to lock/unlock a track, then there is a solution: you should query the current random seed used and restore it.Here is how:Each track has an individual random seed.Each time you lock a track use CapsTrackInfoT2. Save the wseed variable returned. Do not change it (as it may weaken the simple random generator).Next time you lock the same track specify DI_LOCK_SETWSEED and set wseed in the structure to the previously obtained value. The first time you ever lock a track wseed is always reset; you can observe this by checking the value returned.

Therefore, you should lock the track twice instead of once with your approach.The first lock will decode and initialize the track with normal flags, the second time you should specify DI_LOCK_SETWSEED to continue the track randomization from the state where it was before you unlocked it. You should save the returned wseed after this call as well, since that is the updated state.If you do this correctly wseed values before your call and after the call are different for any track that has weak bits.

It is much simpler with a preloaded image; all of the track are already locked, so you'd lock the track only once.