Can you use a USB floppy drive with RISC OS on a Pi?

Thanks for the UFI detection code Colin. Any idea how to capture hot plugging/removal of devices?

I modified my ADFS shim to cover MiscOp 0 (Mount) and DiscOp 1 (read) so *. does at least attempt to catalogue the floppy, of course I then noticed that none of my DOS floppies have a FAT12 signature, so I need to improve my format detection so it fills in the disc structure correctly and gives it the correct image filetype.

Any idea how to capture hot plugging/removal of devices?

USB ServiceCalls.

If you are in a module the service handler would be like this.

see USBDevFs.h for constant values.
usb_devicefs_driver_object_name = the the usb name eg USB8

void module_service(int service_number, _kernel_swi_regs *r, void *pw)
{
    pw = pw;
    switch (service_number)
    {
        case Service_USB:
            switch (r->r[0])
            {
                case Service_USB_Attach:
                    dprintf("Service_USB_Attach %s\n", ((USBServiceCall*) r->r[2])->devname);
                    backend_add_device((USBServiceCall*) r->r[2]);
                    break;

                case Service_USB_USBDriverStarting:
                    dprintf("Service_USB_USBDriverStarting\n");
                    /* devices already attached when this is received */
                   break;
            }
            break;
        case Service_DeviceDead:
            if (r->r[3] != 0)
            {
                dprintf("Service_DeviceDead: %s\n", (char*) r->r[3]);
                /* Usb object deregistered */
                device_t* device;
                device_t* next;
                
                for (device = STAILQ_FIRST(&device_list);
                     device != NULL && (next = STAILQ_NEXT(device, next), next == next);
                     device = next)
                {
                    dprintf("next=%p\n", (void*)next);
                    if (strcmp((char*) r->r[3], device->usb_devicefs_driver_object_name) == 0) device_delete(device);
                }
            }
            break;
        case Service_DeviceFSStarting:
            dprintf("Service_DeviceFSStarting\n");
            /* devicefs may have crashed so remove any registered devices first*/
            backend_devices_delete();
            backend_devices_new();
            break;
        case Service_DeviceFSDying:
            dprintf("Service_DeviceFSDying\n");
            /* Should be an empty device list as devices are deleted when usb deregisters its devices */
            backend_devices_delete();
            break;
    }
}

backend_add_device – adds the device described by the USBServiceCall to my device list if I’m interested in it.

backend_devices_delete – removes all devices from my device list.

backend_devices_new – enumerates all usb devices creating a device list of the ones I’m interested in.

device_delete – removes the specific device from my device list.

If you are not in a module things are not so good.

I’d expect an error if you try to access a detached device.

To detect an attachment you can try – for example

set Alias$@USBDevice_08_04_______ set arg$0 %%*0|Mfiler_run RAM::RamDisc0.$.test

(that’s 7 _ chars at the end)

where test is a taskobey file which for test purposes I’ve put

echo hello usb<arg$0>

Seems to work. arg$0 contains 3 numbers – usb number, interface, alternate eg 8 0 0

Note the double %% is for when running the set command from an obey file.

I suppose you could have the taskobey file run a program which sends a wimp_message to inform your program of an attachment but this is all theoretical

As a proof of concept, it works. I’ve successfully got ADFS mounting and reading 720K and 1.44MB floppies on a Pi3.

Before it’s going to be usable though, I’ll need to add scatterlist support for background transfers, bolt on Colin’s bits for the device detection, add disc error handling, writing and formatting.

Someone will also need to fix SCSISoftUSB so its not handling UFI devices, or at least create a bug report for what needs changing, so a RISCOS dev can pick it up.

As a proof of concept, it works. I’ve successfully got ADFS mounting and reading 720K and 1.44MB floppies on a Pi3.

That’s quite an achievement – 3 days from enquiry to working proof of concept.
You’re after Jeffreys crown :)

Of course 80% of the remaining test and refinement should take at least 4 times as long (80/20) with the 80% of the remaining 20% taking…

I’ve successfully got ADFS mounting and reading 720K and 1.44MB floppies on a Pi3.

Fantastic. It will be very useful for me. Just for information, which device do you use?
(I know that the driver is not yet available, but I could complete my next Amazon invoice with a floppy reader).

I’ve successfully got ADFS mounting and reading 720K and 1.44MB floppies on a Pi3.

That sounds very promising.

At this time, if I need, I use my floppy with Titanium Linux, create a discimage with DD and mount this in the RISC OS DOSBox.

That’s quite an achievement – 3 days from enquiry to working proof of concept.
You’re after Jeffreys crown :)

You’re making it sound like a bigger thing than it actually was. It was literally around 10 lines of BASIC to check the floppy could be read and as I already have the ADFS shim Module with ADFFS, it was simply a case of adding a few instructions to DiscOp 1 and copy/paste of the format detection code from ADFFS into ADFS for MiscOp 0.

It does seem incredibly slow though, ~256 bytes/sec. I’m not sure why that is, as the floppy itself does the density detection, so should set the data rate to match meaning I don’t need to do any configuration. It’s as if it’s stalling waiting for the Pi to drain it’s endpoint, but I’m reading it as fast as it comes in.

Via this, I managed to figure out why accessing DOS/Atari floppy images in ADFFS fails, so I’ll get that fixed for the next release.

And to reiterate, it’s never going to be a workable solution until SCSISoftUSB stops opening UFI endpoints so don’t rush out any buy floppy drives!

We also need ADFSFiler put back into the Pi build.

I have a USB floppy as well, could be an interesting addition to RISC OS…

Just for information, which device do you use?

Its in the USB descriptor above: “Y-E DATA”

It does seem incredibly slow though, ~256 bytes/sec. I’m not sure why that is

It’s the way RISCOS is reading from the floppy in lots of small DiscOp 1’s. Every time a read command is sent to the floppy, it does a seek, so initial setup it slow. Doing one large DiscOp 1 it reads at the speed one would expect.

I’m not sure how to resolve that, if I implement scatterlists it will resolve some situations, but I have my doubts it will speed up copying via filer windows as its probably doing small chunks to update the progress bar.

We also need ADFSFiler put back into the Pi build.

I don’t suppose someone with an up to date DDE could compile a softload of ADFSFiler for me for ARMv7, so I can see if it works with my driver.

Is ADFS/ADFSFiler really necessary? I would be entirely happy with a small tool that produces an image of the floppy which can then be used with DOSFS. No need for direct floppy access via ADFS at all, especially with such dire performance characteristics.

If true Filecore format floppy access would be possible, things would be a lot different. But for typical usage scenarios of DOS floppies?

Is ADFS/ADFSFiler really necessary? I would be entirely happy with a small tool that produces an image of the floppy which can then be used with DOSFS. No need for direct floppy access via ADFS at all, especially with such dire performance characteristics.

And how many bits of code are languishing on an old floppy in ADFS format and the user only has a Pi or Beagle?

1. Slow performance for a one off retrieval is bearable
2. Jon already identified his use as something that involves legacy devices which will only have ADFS. I’d put money on him being totally alone.

I think a soft loadable ADFS would suffice if people dont want to cramp the Pi ROM space. Drop that into the HardDisc build for everyone to use if required.

Doing a quick comparison of SCSISoftUSB against the NetBSD code it’s built around, I can’t spot any glaring omissions which would explain why UFI devices don’t work with SCSISoftUSB.

With SCSISoftUSB loaded, what happens if you use the SCSI SWIs to talk to the drive? It could be SCSIFS which isn’t dealing with floppies (or UFI devices) properly.

Is ADFS/ADFSFiler really necessary? I would be entirely happy with a small tool that produces an image of the floppy which can then be used with DOSFS

You need ADFS for ADFFS to work so all I’ve done is put some UFI code into the otherwise blank ADFS shim Module. To image the floppy, just select Image floppy\Image as ADF from the ADFFS filer.

With SCSISoftUSB loaded, what happens if you use the SCSI SWIs to talk to the drive?

Are they documented? Whatever registers itself with FileCore as SCSI doesn’t support SCSI_DiscOp, so I don’t see how it could support floppies.

With SCSISoftUSB loaded, what happens if you use the SCSI SWIs to talk to the drive?

Are they documented? Whatever registers itself with FileCore as SCSI doesn’t support SCSI_DiscOp, so I don’t see how it could support floppies.

There are two modules involved – SCSIDriver provides the SWIs for sending SCSI commands (e.g. SCSI_Op). On older systems SCSIDriver was the actual hardware driver, but with SCSIDriver 2.00+ it’s just a frontend to any number of backend hardware driver modules (SCSISoftUSB, podule drivers, etc.)

Meanwhile, the SCSIFS module provides the filesystem aspect, bridging the gap between FileCore and SCSIDriver, so has SWIs like SCSIFS_DiscOp.

The SCSI SWIs don’t seem to be documented on the wiki, but they are in the StrongHelp manuals.

And how many bits of code are languishing on an old floppy in ADFS format and the user only has a Pi or Beagle?

Probably many bits, but you won’t read them with a USB floppy drive. Technically impossible. This is the real problem with the USB floppy standard, it is very DOS centric. Ask the Amiga guys.

Jon already identified his use as something that involves legacy devices which will only have ADFS. I’d put money on him being totally alone.

You can use an empty floppy image, fill it with DOSFS and put this image onto the USB floppy. Problem solved.

And how many bits of code are languishing on an old floppy in ADFS format and the user only has a Pi or Beagle?

Maybe I’ve missed something, but I thought the whole point of this thread (and Jon’s code) was to be able to read DOS formatted floppy discs. I thought the standard off-the-shelf USB floppy drive was physically incapable of reading ADFS formatted discs?

With SCSISoftUSB loaded, what happens if you use the SCSI SWIs to talk to the drive? It could be SCSIFS which isn’t dealing with floppies (or UFI devices) properly.

I guess SCSIFS scans only for the device types it knows (0 and 1 probably). Which device type is reported for UFI floppies? The output for *devices seems to suggest type 0, but Inquiry does not seem to work, or else more information would be returned by *devices.

SCSIFS_DiscOp

SCSIFS_DiscOp,,1,0,&10000,512 which should read the first sector returns “The disc drive is empty”.

I thought the whole point of this thread (and Jon’s code) was to be able to read DOS formatted floppy discs.

Correct, you can’t read FileCore/Amiga/Atari based formats on a USB floppy – unless it specifically supports those formats. They could in theory as the addressing is LBA based, but I believe only 512 byte sectors are supported.

SCSIFS_DiscOp,,1,0,&10000,512 which should read the first sector returns “The disc drive is empty”.

And the underlying SCSI commands? (The UFI commands are basically SCSI commands)

Correct, you can’t read FileCore/Amiga/Atari based formats on a USB floppy – unless it specifically supports those formats. They could in theory as the addressing is LBA based, but I believe only 512 byte sectors are supported.

Page 35 of the UFI spec lists the formats that are supported. There is one 1024 byte sector format, but I don’t think the other parameters match any FileCore floppy format.

(Also note SCSIFS currently only supports 512 byte sectors)

And the underlying SCSI commands? (The UFI commands are basically SCSI commands)

I’m not sure what you’re asking. If you want my to try specific SCSI commands, you’ll have to spell it out for me!

Going by the previous thread on this subject, reading DOS floppies via SCSI works for some floppy drives, other report “The disc drive is empty”. I guess mine falls into the later category.

Page 35 of the UFI spec lists the formats that are supported. There is one 1024 byte sector format, but I don’t think the other parameters match any FileCore floppy format.

From the random selection of USB floppy specs I’ve looked at on the web, it’s hit and miss as to what’s supported. They don’t necessarily follow the UFI spec and could in theory support any format disc if they translated the LBA address to the correct track/sector.

The 1.25MB format you’re referring is 8 sectors per track, HD density so is of no use to access native RISCOS formats.

There is a prog – !InitDisc by Herbert zur Nedden – that seems to Init (not a reformat) a DOS 1.4 Disc to RO Filecore ADFS 1.4.

I wonder if that format could be read with a USB Floppy drive?

I’ve compiled a version of SCSISoftUSB here which outputs debug data to a Reporter window if you would like to try it. It may shed some light on what is happening. Just put it in ramfs and double click on it to run it.

I’ve sorted out the speed issue, I’d forgotten to clear the Changed bit in MiscOp 1 so RISCOS was constantly checking if the floppy had changed.

I’ve compiled a version of SCSISoftUSB here which outputs debug data to a Reporter

Inserting the floppy results in the following:

Checking device name 'USB7' (sum_length 91, descriptors_offset 32, class 00, subclass 00, protocol 00)
Device descriptor: Length=18, Type=1, Configurations=1, csDeviceClass=0x0
Device descriptor: iManufacturer=1, iProduct=2, iSerialNumber=0
Device descriptor: Vendor=0x057b, Product=0x0000, Device=0x0601
Configuration descriptor: NumInterfaces=1 
Interface descriptor: InterfaceNumber=0, InterfaceClass=8 (3 is HID), iInterface=4, csInterfaceClass=0x80400
Endpoint descriptor: EndpointAddress=129, (on TnterfaceNumber=0)
Endpoint descriptor: We think this isn't a joystick - ignore this endpoint
Endpoint descriptor: EndpointAddress=2, (on TnterfaceNumber=0)
Endpoint descriptor: We think this isn't a joystick - ignore this endpoint
Endpoint descriptor: EndpointAddress=131, (on TnterfaceNumber=0)
Endpoint descriptor: We think this isn't a joystick - ignore this endpoint
SCSISoftUSB: AttachDevice
SCSISoftUSB: using protocol 0
SCSISoftUSB: ,
SCSISoftUSB:  usbd_open_pipe USB7#endpoint2;interface0;alternate0;bulk;size3276
:
SCSISoftUSB: 
SCSISoftUSB:  usbd_open_pipe USB7#endpoint1;interface0;alternate0;bulk;size3276
:
SCSISoftUSB: USBMassStorage0.25: Attach finished
SCSISoftUSB: AttachDevice done. MaxLun was 0
SCSISoftUSB: Registering scsi device for 2005d790 
SCSISoftUSB: Got scsi device handle 0 maxlun 0
SCSISoftUSB: 
SCSISoftUSB: DoCommand device 2005d790 lun 0
SCSISoftUSB: CDB: 12 00 00 00 24 00 
SCSISoftUSB: scat 201e4d20, tl 24
SCSISoftUSB:  fa207ee4:24 204313ec:1 
SCSISoftUSB:  Using fill of 0
SCSISoftUSB: using length 24 in wire_xfer
SCSISoftUSB: USBMassStorage0.25: umass_cbi_transfer cmd=0x12, len=36
SCSISoftUSB: do_request(21 60000)
SCSISoftUSB: do_request() returned Bad request
SCSISoftUSB: USBMassStorage0.25: CBI Reset
SCSISoftUSB: do_request(21 c0000)
SCSISoftUSB: do_request() returned no error
SCSISoftUSB: going into wire_state, state, status = f 0
SCSISoftUSB: USBMassStorage0.25: Handling CBI state 15 (CBI Reset), xfer=2005db
4, NORMAL_COMPLETION
SCSISoftUSB: umass_clear_endpoint_stall New device call returned no error
SCSISoftUSB: state, state => 10 0
SCSISoftUSB: USBMassStorage0.25: Handling CBI state 16 (CBI bulk-in clear stall
, xfer=2005dbd4, NORMAL_COMPLETION
SCSISoftUSB: umass_clear_endpoint_stall New device call returned no error
SCSISoftUSB: state, state => 11 0
SCSISoftUSB: USBMassStorage0.25: Handling CBI state 17 (CBI bulk-out clear stal
), xfer=2005dbd4, NORMAL_COMPLETION
SCSISoftUSB: Callback, status 3
SCSISoftUSB: state, state => 0 0
SCSISoftUSB: Calling SCSIDriver from DoCommand

Try scsisoftusbd2. It looks like the length of the enquiry command was wrong – it may be the reason it failed. I’ve forced the length to 12 – it was 6 – for the test download.