File loading order (exe2adf)

[remz]

Hello Amiga coders,

In order to minimize load time from a floppy, I was listening to the drive seek sound, which indicates that consecutive files were not stored back-to-back.
I tried several approaches (reorg, manual copy of files one by one, etc.) which made we wonder if someone knew of a better process to essential "Master" a floppy. My goals would be:
- Upon starting from an empty, formatted, OFS bootable floppy:
- Copy the files in a specific order which will be related to how the game will access them
- For example, s/startup-sequence should be first, followed by all the C: commands it uses;
- Then the main game executable;
- Then all the game assets, in the order the game loads them;
- (this can be for example: loadingscreen.iff, then intromusic.mod, etc.)

The current tool I use during development for creating my ADF is exe2adf. It allows adding a directory structure to the ADF, but it doesn't appear to allow specifying anything related to in which order are they copied on the "physical" disk layout.

I looked around at various tools like DiskX, ADFOpus, DirectoryOpus for manual copy, workbench even. But nothing appeared to me to be exactly suited for this task.

In parallel with this question, is there a way in WinUAE to monitor exactly what the floppy disk has been tasked of doing, somewhat like a 'snoopDOS' of some sort, where the developer could see in a trace log all the seek, open, read commands being requested by DOS?

[a/b]

If you aren't happy with what the disk optimizers produce and want to minmax it further... I would manually (programatically) create a raw disk image (or ADF, pretty much the same thing) with the exact layout I want. This implies knowledge of the OFS disk layout (e.g. Babel's Amiga Guru Book, chapter 15 covers that nicely) and willingness to deal with all the intricacies.

If you have enough leftover memory, did you consider AddBuffers? That would probably help to minimize jumping around.

EDIT: Back in the day I was using DiskMonTools v3 for floppy optmimization (and manually fixing stuff and just messing around in general). Maybe try that and see if you are happy with the outcome.

[phx]

Originally Posted by remz

In order to minimize load time from a floppy, I was listening to the drive seek sound, which indicates that consecutive files were not stored back-to-back.

OFS (and FFS) have their root block in the middle of a disk or partition, which means block 880 for floppy disks. I think AmigaOS prefers to allocate new files around it, alternately in the positive and in the negative direction.

Also note that a file header can only store 72(?) pointers to blocks, which means when a file gets larger the filesystem certainly has to move the head to fetch an extension block with more pointers. Even when all the file's data blocks are stored consecutively.

Do you need OFS for easy hard disk installation? Otherwise you can also write a trackloader, and store each file's start and end block in the game code. Then you can arrange everything as you like and the loading times are much faster.

[remz]

Thank you!

a/b: DiskMonTools is interesting. It does not appear to allow specifiying the desired file order however, but it does allow inspecting and understanding how files and directory are stored.

phx: Thanks for the info. I need OFS because I want to target my game for KS1.2+ and designed to be usable/quick when booted directly from a floppy.
Since the game is also intended to be hard drive installable, there is no need to load faster once it is installed: it will be very fast. So indeed, this is not a concern for the probable hypothetical of the vast majority of Amiga userbase.

[paraj]

You can enable disk debug stuff in WinUAE with "diXXXX" e.g. "did 2". Fewer lines = probably faster.

I think phx's suggestion was to store game assets in "raw" sectors. Of course then you couldn't simply copy the game from floppy to HD, but would make loading much faster. (Probably easiest done with separate versions, whdload or some magic).

For mastering your ADF like a/b suggested, there's e.g. https://github.com/lclevy/ADFlib which I don't have experience with, but seems to have a lot of features.
I also have some code I use myself (attached). Haven't tried optimizing block allocation (and I don't know what's best for 1.2/1.3 where it has the largest impact), but you may want to play around with it.

One thing that comes to mind is that I think you want to avoid hash table collisions for file/directory names, though it's probably not a huge issue unless you have lots of files (which you shouldn't).

[Wepl]

Using http://aminet.net/package/disk/optim/ReOrg3_1 and an optionfile you should be able to give files a priority in the directory scanning (I doubt it's worth the effort).

[daxb]

Back in the days I used XCopy to optimise the floppy disk content what gave faster loading/access speed. I guess it is similar to ReOrg and other tools.

[redblade]

I know that flashtro.com used to have non os-friendly AmigaDOS file loader code on their website which you could call direct from game.

I guess you could put all the C: and s:/startup-sequence code on the inside of the disk as it's only read once, and the game files towards the outside of the disk. Maybe the boot block has custom code that launches the program directly, and when you insert the disk via workbench it runs the normal way?

I'm guessing your program is system friendly because you are loading files? Or is that only during the load screen.

** I've never used a track loader, so go with the experts

[Galahad/FLT]

Write the disk on A1200 or A4000, Kickstart 3.0/3.1 seem to write the files to AmigaDOS in a far nicer way, massively reducing seeking across the disk unlike Kickstart 1.2/1.3