Correct size of adf..

[Big-Byte]

Can adf images be less than 880k?

I looked through my collection last night and found a few which had not downloaded properly (ie: had a filesize of 0) but other adfs I have, have a filesize in the range of 90k --> 880k.

I only had time to try one in an emulator and it didnt work

Some adf's I have are more than 880k but I reckon these are 81 track disks instead of the usual 79.

[birdy-scc]

If when making an adf the program reads only the used tracks then there's no reason why an adf shouldn't be smaller than 880k.

But I'm just speculating.

[Big-Byte]

I looked at some of the adfs that I converted personally and they are less than 880k. They also work properly so I think you are right.

[Amiga1992]

The ADF should be an exact copy of the whole disk. Even if tracks 30 to 79 are empty, it should still take 880KB!

They prolly work but perhaps soemthing is wrong with them? Check out BTTR's empty disk... it takes 880KB, ne?

[§ane]

Absolutely, all standard ADF's should be 880kb (901,120 bytes) in size, unless the user has specified to dump less than 80 tracks, which is pointless unless you're trying to save space and transfer each half of the disk separately and rejoin them afterwards.

If the ADF is not a multiple of 11264, then it is most likely incomplete, probably an error occured during the transfer of the image.

It should still work under emulation, though it could possibly cause a buffer overflow error if it tries to access tracks that aren't present in the ADF, depending on how the disk emulation handles odd sized images.

None of this applies to Extended format ADF's however.

[Big-Byte]

Was too ill to go to work on friday so decided to stay at home and sort out my adf collection.

The disk I had personally dumped that I though was less than 880k and working turned out to be an adz file. doh!

So I had a look at all my adf's and found about 100 that had a filelength of 0 and about 150 which had length <880k. None of these worked .

So I now have a new trimmed down but properly sorted TOSEC set.

[Galahad/FLT]

An ADF doesn't have to be 880K, but at the same time you need to fully know the contents of a disk before you start trimming.

1). Any ADF that has an AmigaDOS filesystem CANNOT be trimmed down under any circumstances!

AmigaDos writes file data all over a disk, a block here, a block there. Do not do it!

2). Any trackloading game CAN be done, as long as you know that the end of the disk is empty.

For instance, Stunt Car Racer is a 1 disk 880K ADF, if its a duplicate of the original (and patched cracked) then you can trim it down to 490k, because the other half of the disk is empty.

Frankly, unless you know a great deal about the Amiga and know what to look for in an ADF as data or just junk, I would leave well alone. Hardly seems worth bothering with a few K when 20 Gig drives are cheap as chips!

[Drake1009]

There were talk about extended ADF files. Is that for disks larger than 880Kb? And how would you rip larger disks? And now that I'm at the whole asking stupid questions. Do you need anything particular to read them?

[TikTok]

One of the uses of extended ADFs is for disks larger than 880K. For example, I use RawRead to create images of Diskspare disks. These disks hold 940K on a normal DD disk, still using just 80 tracks. If you try to image them with transdisk (or similar), a file of 880K is produced, which obviously doesnt work.

[andreas]

1). Any ADF that has an AmigaDOS filesystem CANNOT be trimmed down under any circumstances!
AmigaDos writes file data all over a disk, a block here, a block there. Do not do it!

Well, newer versions of X-Copy provide an OPTIMIZE option, which works like DEFRAG on a Windows-driven harddisk, but can also operate with floppy disks. A disk which is, say, 48% full, can be OPTIMIZED so that all of the disk contents are on the FIRST half of the disk, with the other half being empty.
This CAN save time when transferring, provided that you "resize" the image again afterwards so that AmigaDOS can continue writing on the disk for future sessions. Yes, it MUST have 880 kB to react correctly to any write-operations.
But I quite like that X-Copy feature: it speeds up disk access and when transferring, you can really save time that way. Consider this IS a criteria for A500 users having to do this with no more than a speed of 19200 kbps (if at all)
I'd even plead for every TOSEC AmigaDOS disk to be optimized by default: but I reckon that's an impossible thing to do.
Yeah, much too much stuff.

I have the following adfs that are enormously oversized

Super Ski 2 (1990) [cr] (Disk 2 of 2).adf 1100kb
Turrican (1990).adf 1906kb
Master Blazer (1990) [alt].adf 1978kb
B.C. Kid (1 disk) (1992).adf 2023kb
Turrican 2 (1991).adf 2116kb
Turrican 3 (1993).adf 2228kb

They are all common files that can be found on pe2000.
Now, there are these things I don't understand... Most of them are one disked versions. If they contain so much data, how can they ever fit on a single DD floppy? Even weirder, one of them is not an one disked version (super ski disk 2) it contains 220kilobytes of extra data, then how many tracks were there on the original disk???

[Worfje]

The "Extended" ADF file format is used for games you may download at the Factor 5 homepage. These files contain some tracks which are specially encoded. This includes Turrican 1, 2, 3 and B.C. Kid.

These adf files aren't ripped from a real disk, so don't bother discussing the different sizes.

The fact is that these adf files can't be written back to a real Amiga disk.

this explains it all then

[Amiga1992]

Originally posted by Worfje
These adf files aren't ripped from a real disk, so don't bother discussing the different sizes.

Where are they ripped from then? Aren't they ripped from an original, like what you do with Diskwiz?

What I understand from worfje's words is that, they have found some way to join multiple disks as a single adf file. At least this is how I understand it. Would be nice to know how it was done.

[Worfje]

Factor 5 released the games and since they have the original source, they can distribute/repack it any way they wan't.

WinFellow has some support for the extended adf format, i'm not sure it is fully compatible yet. Peschau and Carfesh coded the support, so they should know the specifics.