I have many .adf files of PD software that I write to floppy. When I want to use them. As there are far more .adf files than I have floppies I have to write and re-write over disks regularly. Is it possible to browse the contents of the .adf file from within workbench itself? Examples of .adf files I’m using are
- Back to Skool (PD Compilation)
- Deluxe Pacman (Shareware)
- James Pond 2 – Codename Robocod
- There are a lot of good answers here and I’m having trouble choosing one as they all have their strengths. TenLeftFingers is comprehensive, Daedalus is simpler and more flexible for single disk-drive requirement. Dan pointed out where I might meet memory constraints and Lizard’s recommendation may save me RAM by using disk space instead. I wish I could choose them all!
- You must login to post comments
I always used fmsdisk.device, but this creates a virtual drive file on your harddisk.
So this might not be applicable to you if you don’t have an harddisk.
Also keep in mind some adf files will have a custom disk structure, which cannot be browsed.
Some relevant links:
The only way I could get this to work is using the program distributed as ADF_Device.lha available here: http://bfugl.dk/Download.asp
After you have extracted and installed it, you need to run three commands to get your adf to show up as a usable disk in workbench.
Lets assume you have an adf called back2skool.adf which you want to mount. Open a shell and cd to the directory that has your adf file.
1.Create the virtual drive that the adf will be inserted into:
mount ad0: from devs:adf.ml
2.Then ‘insert’ the adf:
InsertDisk UNIT 0 back2skool.adf
3.Then to make it appear on the desktop, type:
Just use these as you would an ordinary inserted disk. You can increment the device number (ad1-n:) to create new drives and insert more adf files. But for disks that aren’t readable by workbench (most games for example) mounting them in this way won’t give you any advantage – they will still be unreadable.
An alternative option to mounting the ADF image would be to write it to a virtual floppy. OS 3.x comes with the RAD: device which appears as a virtual floppy disk on Workbench. This can be used just like a floppy disk – you can even boot from it for games that use the standard system methods for accessing floppies, though it won’t work for games with custom loaders.
In a standard Workbench installation the RAD: device can be mounted by double-clicking its icon in the Storage/DOSDrivers drawer. Dragging the icon into DEVS:DOSDrivers will cause it to be mounted on bootup, however be aware that the device takes up 880KB of RAM when it’s mounted. Once mounted it can be formatted and accessed like any other floppy, including writing ADFs to it with tools such as TransADF. RAD: also survives a warm reboot, which means it is listed as a bootable device in the early startup menu and thus can be booted from.
To remove the RAD device and free up the memory, you can either cold boot the machine, or use the REMRAD Shell command:
This will delete all files on the RAD: “floppy” and free the resources, though the icon will remain on Workbench until the next reboot.
As pointed out in TenLeftFingers comprehensive answer, ADF_Device.lha is a good solution. He also pointed out that a floppy will take 880KB of ram to mount. There is also the overhead of Workbench itself.
So this won’t work on an A500 with 1/2 meg of ram. Will it work on an Amiga with 1MB of ram? Perhaps but it depends on is workbench can load in 120KB of ram (880KB – 1024KB).
Unadf is another alternative, writing the contents of an ADF to the hard drive as if it was just an LhA archive.
Of course, all these solutions only work if your ADF uses an AmigaDOS filesystem. Most (commercial) games don’t.
Please login first to submit.