RISC OS Open
A fast and easily customised operating system for ARM devices
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → General →

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

Subscribe to Can you use a USB floppy drive with RISC OS on a Pi? 120 posts, 16 voices

Posts per page:

Pages: 1 2 3 4 5

 
Jan 28, 2019 6:16am
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 28, 2019 9:15am
Avatar Rick Murray (539) 10813 posts

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

USB ServiceCalls.

 
Jan 28, 2019 1:17pm
Avatar Colin (478) 2309 posts

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

 
Jan 28, 2019 9:32pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 28, 2019 10:37pm
Avatar Steve Pampling (1551) 6783 posts

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…

 
Jan 29, 2019 8:47am
Avatar David Feugey (2125) 2604 posts

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).

 
Jan 29, 2019 9:01am
Avatar Raik (463) 1868 posts

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.

 
Jan 29, 2019 9:12am
Avatar Jon Abbott (1421) 2180 posts

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

LOL, you’re making it sound like a bigger thing that 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.

 
Jan 29, 2019 9:42am
Avatar Rick Murray (539) 10813 posts

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

 
Jan 29, 2019 12:17pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 29, 2019 4:01pm
Avatar Steffen Huber (91) 1687 posts

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?

 
Jan 29, 2019 7:47pm
Avatar Steve Pampling (1551) 6783 posts

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.

 
Jan 29, 2019 9:17pm
Avatar Jeffrey Lee (213) 5870 posts

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.

 
Jan 29, 2019 10:27pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 29, 2019 10:49pm
Avatar Jeffrey Lee (213) 5870 posts
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.

 
Jan 29, 2019 11:02pm
Avatar Steffen Huber (91) 1687 posts

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.

 
Jan 29, 2019 11:04pm
Avatar Andrew Conroy (370) 626 posts

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?

 
Jan 29, 2019 11:06pm
Avatar Steffen Huber (91) 1687 posts

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.

 
Jan 29, 2019 11:13pm
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 29, 2019 11:53pm
Avatar Jeffrey Lee (213) 5870 posts

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)

 
Jan 30, 2019 7:05am
Avatar Jon Abbott (1421) 2180 posts

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.

 
Jan 30, 2019 9:23am
Avatar Colin Ferris (399) 1125 posts

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?

 
Jan 30, 2019 9:44am
Avatar Colin (478) 2309 posts

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.

 
Jan 30, 2019 11:45am
Avatar Jon Abbott (1421) 2180 posts

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
 
Jan 30, 2019 1:04pm
Avatar Colin (478) 2309 posts

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.

Next page

Pages: 1 2 3 4 5

Reply

To post replies, please first log in.

Forums → General →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

General discussions.

Voices

  • Jon Abbott (1421)
  • Rick Murray (539)
  • Colin (478)
  • Steve Pampling (1551)
  • David Feugey (2125)
  • Raik (463)
  • Steffen Huber (91)
  • Jeffrey Lee (213)
  • Andrew Conroy (370)
  • Colin Ferris (399)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys