Automatically-created disk images

[mark_k]

Here are some comments/suggestions for the "load executable as floppy disk" feature. That's where, if you choose an Amiga executable instead of a disk image, WinUAE creates a dummy disk image with startup-sequence which runs the program.

Possible off-by-one date bug. Boot a Workbench disk then select an Amiga excutable for DF1:. Type List DF1:. Notice that the file datestamps are for one day in the future. The disk creation date is probably like that too.

The disk creation dates can be identical, which combined with the fact that the volume names are always "empty" can cause AmigaDOS to become confused, thinking there are identical disks in two drives. Enable at least two floppy drives. Boot from (emulated) hard disk. Open settings window, select two (different) Amiga executables for DF0: and DF1:. Click OK to continue emulation. There is only one disk icon on Workbench. If you type List DF0: and List DF1: in a CLI you should see the problem.

Related to that, you could make auto-generated disk volume names correspond to the executable filename or archive name. That would make it easy to distinguish between disks on Workbench.


From looking at the track indicator while booting, the program is always written to the dummy disk at tracks 0 and up. While WinUAE seems to automatically switch to turbo mode when booting from the auto-generated floppy, load speed could be marginally improved by writing the program data starting at track 40 and up. That would avoid the track 40 to 0 step on booting. (For programs larger than ~415KB you'd shift the start track earlier to allow enough space.)

Some demos which kill the system do so before trackdisk.device stops the drive motor, so you get a constant motor sound throughout the demo when floppy drive sounds are enabled. A couple of examples:
http://ftp.amigascne.org/pub/amiga/G...s/ATMOSFEA.EXE
http://ftp.amigascne.org/pub/amiga/G...-Soundmachine1

An option to stop the motor before running the program would be useful there. But I can't think of a system-friendly way to achieve that without increasing boot time. Perhaps just have an option to automatically disable floppy drive sounds when booting auto-generated disks?

[Toni Wilen]

All done

(I don't do options = exe mounted as a disk is now silent, I don't think anyone wanted to hear that too fast sound anyway)

[mark_k]

Thanks, the latest winuae.zip seems to have fixed most of the issues and programs boot faster. There are some issues remaining, though nothing that prevents booting.

The filesystem structure of dummy disks is broken. The amount of free space shown by the DOS Info command is approximately the same as the size of the executable on the disk. And a strange thing happens if you attempt to write to a dummy disk. Boot Workbench, insert an executable/dummy disk in DF0: then create an ADF file from that. Eject disk in DF0: and load the ADF file into DF0:. (We're doing that to allow writing to the disk.) Try to copy a file to the disk. It doesn't work and after doing that you can't get a directory listing or open its icon from Workbench.

It would be good if in addition to the volume name, the executable name on the dummy disk could match the original filename. I guess it would also be possible to set the executable file datestamp to match the host file datestamp (or the datestamp of the executable inside the .zip archive, if the user loaded a .zip file into a floppy drive).

If the user didn't boot from a dummy disk but inserted it at Workbench, don't force floppy drive speed to turbo or disable drive sounds. Or you could grey out the drive sounds and floppy turbo controls in the settings window until the dummy disk is removed from the sounds-enabled drive.

In the floppy drives settings page the write protection checkboxes for auto-generated disks should be checked and greyed-out because dummy disks are always write-protected. Or default the write-protection boxes to checked, but allow the user to write-enable dummy disks.

[Toni Wilen]

The filesystem structure of dummy disks is broken.

Totally broken bitmap should be fixed now.

WB usage

You are still doing it wrong. Just drag'n'drop the file as a harddrive if you want to mount single file executables, no need to use slow floppy disks.

Executable as a disk mounting is only meant for booting single-file programs.

[mark_k]

I thought of one final small optimisation which could be done to the disk layout. Instead of writing the executable to track 40 and up, you could write it from track 40 downwards. (If larger than ~415KB start at a higher track so the file ends at track 0.)

The benefit of that would be, when the user resets and trackdisk.device moves the heads to track 0, that won't take as long.