Flakey-bit Generator Enhanced

03 May 2004

The Amiga game Dragonflight preserved as id 58 worked as the original does on most machines. However, it has now been replaced with one which works as it was intended to. The original disk images had a diskchange problem after entering the disk backup menu. Basically, it did not accept the “A” disk on exiting the backup program. The fact that the game is confirmed to work on a real system this way, was probably why nobody noticed, and why we initially decided it was okay.

We decided to make it more reliable when we saw something similar on the recently preserved game Magic Lines, more on that later. The new disk images require an updated IPF library and UAE.

Just recently the Amiga game Magic Lines got dumped but did not work at all due to its flakey bit protection. It tries to read the track 64 times (!) of which 50 (!) reads must be different. Since it could be any track on the disk, generating 50 revolutions in advance by the IPF library is not a good idea, so this weekend the flakey bit support got substantially enhanced.

There is now a new method provided for generating track data that contains flakey bits. The old method (which is still available) generates multiple revolutions at decode (lock) time. The new one generates only one revolution the first time a track is locked (loaded and decoded) as a non-flakey track would normally produced, then each subsequent lock call modifies the parts of the track that contains the weak bits. In other words, it “remembers” the position and length of the flakey areas on that particular track. This is very fast since it holds delta information on the affected parts of the track, and only those parts are modified. Each track has its own state that remembers the associated random seed, etc., so no matter how hard a program tries it will get different data for a very long time on each successive read. For example, of the 64 tries on Magic Lines, all 64 tries pass.

This also solves a problem with some games that use flakey bit protection and occasionally not pass it due to timing issues. We must stress here that the “natural” behaviour is that only a few reads are really different (not each one of them), as the data is not that random. However the Magic Lines protection really provoked this solution.

We had the feeling that since Dragonflight has a very similar disk format, maybe when it fails the diskchange a similar protection is used instead of its usual diskchange routine... this was then found to be correct.

The latest UAE build uses the new API functionality which is basically activated by setting one bit in the lock request flags. Unfortunately, it was a quite a bit more work on the library side! All of this still includes legacy support, therefore as long as what is written in the developer guide has not been abused (such as setting unused flags, etc), any old executable is still binary compatible with the new library. This is useful to test something, e.g. with an old UAE version.