-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turrican I,II, and III backup adfs not working #432
Comments
These ADFs contain magic bytes at the beginning ( 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. |
Hi, |
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. |
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. |
ADF files with a From
|
Here is the header information from T3.adf:
Open questions:
|
Related to this code
in |
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. |
Maybe @tonioni knows how it works |
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.. |
Thanks, Toni. I think it's best to skip supporting the EXT1 format then. |
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. |
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. |
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. |
It is very simple. "UAE-1ADF" Multirevolution support is not really needed. |
Thanks, Toni. This helps a lot. I'll copy this information over to a new thread, so it won't be forgotten. |
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
The text was updated successfully, but these errors were encountered: