Using TransDisk to read Amiga DD floppies to save as ADF only takes about 20 seconds per disk on my Amiga 1200. It seems so fast. :-)

Maybe it's faster because I'm running a 68040 at 1Ghz with 800 mips & 800 mflops. The HDMI output screen is amazing also!

My Amiga 1200 has never been happier! This is the Amiga I wish I had 15 years ago.

Next I will hook up my external high density drive for my Amiga 1200 to see if I can read Amiga DD & HD floppies to ADF & PC floppies to IMG file.

I will compile the disk reader for AROS x86 so I can use a floppy to USB converter I have to see whether it is detected as usbscsi or trackdisk.

Yes. It can also read Amiga formatted high density floppies on Amiga OS 3.9+

Luckily my XL Series Install Disk is still readable. So I quickly made an ADF of that. With the -h switch it indicates high density.

Although it is such a pleasure to use a program like TransDisk on my Amiga to read & write ADF images I will leave that discussion for another day. But for now we will focus on AROS x86.

In the modern world it is increasingly difficult to find computers with built-in floppy drives. All of my three mini PC's that I use to test the various AROS distro are missing the old floppy drives. Even online it is getter more difficult to find the hardware & cabling to setup external floppy readers such as greaseweazle which uses old floppy drives. I noticed one PC drive for sale for only $100 which prompted me to look at one of my floppy drives that sits on a shelf waiting to be used. I have dozens of these drives from many years ago that I saved for some unknown use.

Now about AROS. Since I have no internal drives I needed to use a readily available cheap USB floppy drive to read disks on AROS. Rather than trackdisk. device it instead uses usbscsi.device. I noticed that reading disks with TransDisk on my Amiga 1200 only takes 20 seconds for a DD disk. But just mounting a USB floppy disk on AROS takes 30 to 45 seconds which seems like a long time! Trident log reports that the DOS method to load fat.handker fails. Then it attempts a "hack" to load fat.handler which does work. Finally, after a long wait, the disk icon appears on workbench. After removing the disk & re-inserting it though it mounts in about 10 seconds which seems more "normal". But then there is another issue.

For some reason when using TransDisk to read a PC floppy disk using usbscsi.device it takes about 2 minutes 30 seconds which seems really slow. I would expect it to read a disk in 40 to 60 seconds depending on the speed of the drive. Maybe the usbscsi.device is not very efficient.

But please note it is only possible to read PC floppies to save as a disk image on AROS at the moment. We can't read & save real Amiga disks.

However, if we can mount a disk on the workbench on AROS we can probably read it to save a disk image. Even DiskImage GUI uses the common AROS/Amiga device structure to mount disk images. At the core of DiskImage is a simple sequence:

OpenDevice(DiskImage.device, unit 0, ...

Which makes me wonder about TransDisk.

transdisk >Ram:test.adf -d diskimage 0 -s 0 -e 79

Maybe someday AROS can read Amiga disks. :-)

Very interesting!

When I first connect my USB Floppy Drive a small Poseidon window appears saying it recognized the device as a TEAC drive but no class has been assigned. When I open Trident the log reports that I tried several ways then finally mounts the usbscsi.device unit 0 as mass storage device. (USB Floppy Drive).

So I used the "Save" button to save the config. After unhooking the USB drive then attaching it again the message no longer appears & the disk mounts in about 10 seconds. Awesome!

Reading the PC formatted high density floppies still takes about 3 minutes. And writing a disk image to a blank disk takes about the same. Maybe we need a dedicated or improved USB floppy device driver that reads efficiently?

It could be that usbscsi.device is normally used to read USB hard disks which spin at higher speed (7600 rpm vs 300 rpm) and the latency time for hard disks is much less. The spin-up time and seek time for a floppy drive is really slow. Using usbscsi.device there are several rotations and lots of disk activity per track which wastes a lot of time. On the Amiga, for example, the disk rotates very little (maybe once) and the drive light blinks once per track as it reads 22 sectors of data in perhaps 200 micro seconds.

Anyhow writing the disk image back to disk took about 3 minutes. But I hooked the USB drive to my PC and the resulting floppy disk reads ok.

Maybe we need a new device driver specifically for USB floppy disks such as a usbtrackdisk.device that would use very few seek operations in between tracks to save time.

In order to continue testing I will write a new disk reader to read several different disk types to disk images. It will use the AROS device subsystem OpenDevice, CloseDevice, etc. But instead of reading or writing a certain number of sectors per track and 80 tracks per side and 2 sides which only pertains to floppy disks it will be flexible enough to use total sectors to read or write.

With the new disk reader we can specify the device driver and unit number and total sectors to read or write. Instead of reporting tracks that we read or write it would need to report a step such as Step: 1% all the way to Step: 100% as a type of progress indicator.

I'd like to use the disk reader to read a 250MB Zip Disk and then a 1GB Flash Drive then an 8GB flash drive. My USB Zip Drive uses scsi.device so I wonder what a flash drive uses.

The diskreader program is complete.

It works fine for floppy disk images but for reading zip100 disks to save as a disk image it completes the task in about 2 minutes compared to 4 minutes for a floppy disk. The zip disk (Bernoulli disk) spins faster than a floppy. It saves a disk image of the correct size of 100,646,912 bytes. But for some reason it adds 32 sectors (16384 bytes) to the beginning of the image. I've seen this offset error before though.

I suspect it is an error in my calculations for the initial offset for ioreq->io_offset = 512 * (ptr * step + sec) where ptr is step pointer & step is 1965 sectors & sec is a value from 0 to 99.

Other than that it's a perfectly good disk image.

thanks miker

The DiskReader program is coming along nicely. It can read mounted disks <2GB to image files.

I'm planning another small program to interact with DrawBridge aka Arduino FDC (floppy disk controller). When I connect my USB floppy drive equipped with DrawBridge Poseidon recognizes it as a UART (serial) device but there is no driver for it. But a small SerialDiskReader may be able to use DrawBridge to read & write Amiga disks .

This is all theoretical & experimental at the moment. As with the DiskReader we use OpenDevice(... for usbscsi.device unit 0. If there's 1 device it's unit 0. In this case Arduino (for short) is using serial.device unit 0. So the SerialDiskReader must first open the device then use SerIO to send commands & receive data using DoIO. There are many unknowns at this time.

If I can write a small SerialTest to try maybe it will be like "Arduino, are you there?" If I can open the serial port & send a command to list its version & I get a correct reply then I've made contact with the Arduino Device. Many things could go wrong or right. We'll see. :-)

It seems that usbscsi.device is one of the device drivers in Poseidon. It isn't specialized for any particular device such as USB floppy drives. But my test results for usbscsi are interesting.

To read a USB floppy disk it takes about 4 minutes. It's really slow! To read a 100MB zip disk it takes about 3 minutes. That's a little faster. But reading a zip disk to image causes a problem. It seems that when using usbscsi.device when total sectors > 2880 (larger than a 1440kb floppy) and when sectors per track are 32 and during the CMD_READ operation it adds 32 sectors at the beginning of the output disk image file. It reads floppy disks to disk image without issue.

This happens with zip100 disks or zip250 disks, using a USB zip drive or even an ide zip drive connected with a USB caddy tray (for IDE hard disks). The same 32 junk sectors appear each time. It's like it first reads Track -1 followed by Track 0, 1, 2, etc. But Track -1 doesn't exist so it's just random data. So I've decided a work around for using usbscsi.device with larger disk drives.

I tried to use IOreq->io_offset to skip reading the first 32 sectors but that causes a problem. It just won't read at all. So my solution is to let the device driver read from Track -1 all the way to the end. But I used a conditional If (sectors > 2880) && (! write) then we add 32 sectors to the end of the disk image. It makes sense that if it adds 32 junk sectors at the beginning then it's 32 sectors short at the end. So we read an additional 32 sectors to add them back at the end of the file.

So now the disk image is 32 sectors too big! The file size is 16384 bytes more than it should be. So now we must remove the first 32 sectors to restore the correct disk image. We make a temp file and read from the original disk image but before reading we set the file pointer to 16384 to skip 32 sectors. We read sector by sector till the EOF and write each sector to the temp file. After re-reading the entire disk image we close both files and delete the original and copy and rename the temp file . Operation Complete! The file operations at the end happen very quickly!

The result is a perfectly good disk image file. We can process Zip100, Zip250, Zip750, LS-120, LS-240, Jazz1GB, 1GB or 2GB SD card or CF card. We should store them on the local hard disk. The files are too large for Ram Disk to handle them.

I still have to experiment with reading LS-120 and I ordered an old motherboard with a 34 pin floppy connector so I can use an internal FDD to test the AROS trackdisk.device to see if it reads floppy disks better than usbscsi.device does. I also plan to setup my 4x buffered IDE on my Amiga 1200 to attach an IDE Zip750 drive. The same DiskReader code can be compiled for Amiga OS 3.x to read using scsi.device unit 0.

I'd like to mount a disk image on the Amiga (double-click in Caffeine OS) then use DiskReader to read the mounted disk into a disk image. Being able to read from a mounted disk and write to a real disk in DF0: or DF1: would be DiskCopier. That may be the next small app for AROS and Amiga. I'm thinking GoTek drive & diskimage.device unit 0 or unit 1 to copy disks. MOUNTINFO is a useful utility for these apps.

After a week of trying I succeeded in getting PC formatted floppy disks to mount properly on my Amiga 1200 running Caffeine OS. But you would say "that's so easy". It wasn't so easy for me! ;-)

The problem with my PC0: MountList was that I was using the wrong device driver. I thought all floppy disks use trackdisk.device but it's not so. I stumbled on the solution while reading a guide by PJ Hutchinson about MountLists. His sample PC0: used mfm.device. Hmmm...I thought "why not try it?". I edited my PC0: and boom! The PC formatted Double-Density disk in DF0: mounted.

The icon appeared on workbench and the Magellan window popped open to show the contents of the PC disk! So I then verified that I could read PC disks to save IMG disk images. I even double-clicked an ADF to mount it then I used diskimage.device unit 0 ( IDF0: ) to save it to another ADF. We can do the same with GoTek.

The DiskReader can be thought of as a "User Specified Device Driver" that communicates directly with a device driver ( *.device ) that also communicates with a specific device ( unit # ). We tell the device driver to read or write a stream of binary data one sector at a time for a device.

The SerialDiskReader would do the same thing using serial.device as the device driver to talk to a serial device like a DrawBridge floppy drive. Hopefully that will work. If so DrawBridge can be accessed on AROS like any other device which would allow us to read and write Amiga disks.

Strange that you were not aware, already from Workbench 2.1 mfm.device is present in both DEVS folder and Mountlist PC0

If for example you have to mount a FAT formatted CF then you will have to use in the MountList "FileSystem = L:fat95"

On the Amiga there is also a Handler called "BabelCDWriteFS" which allows you to erase or add the data on a CD "Virtually", basically the data erased "Virtually" will be stored in a folder, which if erased the CD will be seen in full again.

What was the purpose of this "BabelCDWriteFS" ? one to hide some contents from prying eyes, other reason it allowed to delete folders that included Viruses, I attach an old video of mine showing how the Virtual CDWR works

AMIGASYSTEM

That's interesting. I hadn't heard of BabelWriteFS. So it works with CDFS to read an ISO?

The next experiment on AROS will be to start writing a SerialDiskReader that uses serial.device to communicate with a serial device. The first test will be "SerialTest" which will setup a serial connection by using OpenDevice( serial.device, unit 0... ). If successful I think OpenDevice will return a 0 or 1. Not sure which to indicate success or failure. If we can open the device we send a buffer of 4 bytes of data to the serial port to ask for the version number of the firmware installed. Then we check for a 4 byte reply that can be deciphered. If it's a valid version number then SerialTest was successful. That's the theory.

The next experiment on Amiga will be to attach my buffered 4x IDE adapter I bought from AmigaKit some time ago. With the PiStorm 32 attached which uses a micro SD card as HDD the internal IDE is now free. I'd like to attach a zip750 drive with an IDE cable and an external power cord. The Amiga should recognize it as scsi.device to read from the various zip disks. Then the Amiga version of DiskReader can read the disks to save IMG files. Hopefully it works.

BabelWriteFS to work you must first mount the CD0, the files or folders deleted or added are dummy, in practice they are not really deleted or added, but are simply scripts that BabelWriteFS creates in its appropriate folder.

BabelWriteFS was not known because it was commercial software, the demo version appeared only in the Amiga magazine "Pearls"

I've written a small program called SerialDiskReader based on the same concept as the DiskReader for AROS & Amiga.

The SerialDiskReader only works with AROS. It is a User Specified Device Driver that communicates with a device driver (serial.device) which communicates directly with a device.

Here is the status so far. The program using serial.device unit 0 has successfully opened a serial port connection. Next step is to send 1-byte (single character) commands across the serial connection & wait for a response from the UART (serial) device on the other side.

The command sequence being sent is the request for the device's firmware version number which consists of 4 bytes. The response should be "1" indicating "success" followed by "V1.9'" It's just simple AROS (& Amiga) Serial Port Reading & Writing of data so it should work.

It's time for a new topic. 😋