Vamiga: Turrican I,II, and III backup adfs not working

[bnice]

Hi,

Factor 5 provide backups of Turrican I, II, and III backups in ADF format. However, they are not showing as unrecognised format in vAmiga.

URL: http://www.factor5.com/downloads_backups.shtml

[dirkwhoffmann]

These ADFs contain magic bytes at the beginning (UAE--ADF) and are considerably bigger than standard ADFs.

I guess those files are in "Extended ADF" format. As far as I know, this format encodes the raw MFM data of a disk. Unfortunately, I wasn't able to find decent documentation about it. If somebody knows about a spec for this format, please give me a hint.

[bnice]

Hi,
I guess you have seen this http://lclevy.free.fr/adflib/adf_info.html ?

[dirkwhoffmann]

I guess you have seen this http://lclevy.free.fr/adflib/adf_info.html

Yes, it's one of the best sites describing the standard ADF format and the block structure of the Amiga File System. But it doesn't cover the format of extended ADFs which is completely different.

[bnice]

This isn't urgent as these 3 ADFs are the only extended ADF format titles I had and suspect the cracked version of these titles don't even require the extended ADF format. You could try writing to Factor 5 and see if they can help with docs on ADF extended format :-)

Ben.

[dirkwhoffmann]

ADF files with a UAE--ADF header are extended ADFs in EXT1 format. I haven't found any detailed information about the format, so I looked at the UAE source code. Here is the relevant part which tells us how the header is structured:

From disk.cpp:

    } else if (strncmp ((char*)buffer, "UAE--ADF", 8) == 0) {
        int offs = 160 * 4 + 8;
        int i;

        drv->wrprot = true;
        drv->filetype = ADF_EXT1;
        drv->num_tracks = 160;
        drv->num_secs = 11;

        zfile_fseek (drv->diskfile, 8, SEEK_SET);
        for (i = 0; i < 160; i++) {
            tid = &drv->trackdata[i];
            zfile_fread (buffer, 4, 1, drv->diskfile);
            tid->sync = buffer[0] * 256 + buffer[1];
            tid->len = buffer[2] * 256 + buffer[3];
            tid->offs = offs;
            tid->revolutions = 1;
            if (tid->sync == 0) {
                tid->type = TRACK_AMIGADOS;
                tid->bitlen = 0;
            } else {
                tid->type = TRACK_RAW1;
                tid->bitlen = tid->len * 8;
            }
            offs += tid->len;
        }

[dirkwhoffmann]

Here is the header information from T3.adf:

Track   0: Sync:     0 Length:  5632
Track   1: Sync: 17545 Length: 14000
...
Track  48: Sync: 17545 Length: 14000
Track  49: Sync: 17545 Length: 15000
...
Track 159: Sync: 17545 Length: 15000

Open questions:

• What's the Sync value supposed to tell us? 🤔

[emoon]

Related to this code

        drv->bigmfmbuf[0] = ti->sync;
        read_floppy_data (drv->diskfile, drv->filetype, ti, 0, (uae_u8*)(drv->bigmfmbuf + base_offset), (ti->bitlen + 7) / 8);
        for (i = base_offset; i < (drv->tracklen + 15) / 16; i++) {
            uae_u16 *mfm = drv->bigmfmbuf + i;

in drive_fill_big_buf I guess. That being said, I actually don't know what it does :)

[dirkwhoffmann]

That being said, I actually don't know what it does :)

Same here 😉. It sets the first element of bigmfmbuf to this value which doesn't explain itself. Even more interesting, this seems to be the only place in the entire code where the sync value is being used.

Before being able to support the EXT1 format, I need to do some general changes in the Disk class. Up to now, vAmiga assumes that all tracks have the same length. I need to generalize that since the header shown above exhibits that different tracks may store a different amount of bits on copy protected disks.

[emoon]

Maybe @tonioni knows how it works

[tonioni]

It is very pointless format. Also at least one of those Turrican files probably are still broken and hangs in some later level..

Also note "/* Ugh. A nasty hack. Assume ADF_EXT1 tracks are always read from the start. */" = when disk dma is started, it MUST start from beginning of track. Start from last motor position will not work..

[dirkwhoffmann]

It is very pointless format. Also at least one of those Turrican files probably are still broken and hangs in some later level..

Thanks, Toni. I think it's best to skip supporting the EXT1 format then.

[tonioni]

Background info I forgot to mention: this was made long, long, long time ago (before I even knew UAE existed) when emulation was very basic, disk emulation for example was (if I remember correctly) simple mfm word based (no bit stream raw mfm support or disk rotation etc existed) and afaik this format was simple hack which easily fit to this kind of emulation.

These factor 5 images (afaik) are the only ones that use this format.

[dirkwhoffmann]

OK, let's close this. The next version will display a warning message when the user tries to load an extended ADF.

[tonioni]

Just to make sure there is no misunderstanding:

"UAE-1ADF" is called extended adf (basically simple raw bitstream per track, full read/write support). Originally meant for save disks for games that don't use AmigaDOS format (most "popular" probably being Cannon Fodder). Can also support some copy protections (mainly long tracks).

"UAE--ADF" is the mostly useless format used by Factor 5 Turrican images. Read-only, strange structure. I don't think this format have any "official" name.

[dirkwhoffmann]

"UAE-1ADF"

I've spotted this in the code, too. Maybe I should support that 😎.

Would you recommend to look into the source code to get an understanding about how the file format is organized? Or is there even a document or web page describing the format? I guess there is some kind of header describing track lengths etc.

[tonioni]

It is very simple.

"UAE-1ADF"
W reserved
W number of tracks (default 2*80=160)
Followed by track headers:
W reserved
W type, 0=normal AmigaDOS track, 1 = raw MFM (upper byte = disk revolutions - 1)
L available space for track in bytes (must be even)
L track length in bits
Followed by track data:
Total track size equals "available space for track in bytes" track header. "track length in bits" is used data.

Multirevolution support is not really needed.

[dirkwhoffmann]

Thanks, Toni. This helps a lot. I'll copy this information over to a new thread, so it won't be forgotten.