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

The source you have linked to shows a 6 byte CDB, which is correct.

It’s definitely 12 for a UFI command as detailed in the UFI spec

It looks like UFI (like ATAPI) pads all commands to 12 bytes. “Naturally”, TEST UNIT READY is a 6 byte command.

I would expect the transport layer somewhere pads the command length to whatever the transport needs or expects. Plain SCSI needs the “true” command length – usually 6, 10 or 12 bytes. SCSI-over-USB (“transparent SCSI”), I don’t remember unfortunately :-(

I dimly remember problems with ATAPI devices connected via a SCSI-IDE bridge which wouldn’t accept standard SCSI commands because they always expected 12 byte command length, and the bridge did not translate this correctly. Hmmm. Wasn’t there a problem with connecting IDE drives from the Risc PC with a USB-IDE bridge to a RISC OS 5 USB system?

If you do a REQUEST_SENSE before INQUIRY does it work.

No, I tried sending various commands prior to INQUIRY, it either reports an error or never returns from SCSI_Op requiring a reboot. That was all with the stock USB stack though.

I’ve yet to try it with your stacks, which may be different as the later versions did display the device details in *devices

No, I tried sending various commands prior to INQUIRY, it either reports an error or never returns from SCSI_Op requiring a reboot. That was all with the stock USB stack though.

Did you try a SCSI_Control 4,id,0 before starting to send commands with SCSI_Op? This will result in a guaranteed no-automatic-request-sense state which is probably the best to try to narrow down problems.

It is really strange that INQUIRY leads to problems. It is one of the few commands that should work all the time, no matter which state the drive is in! Have you tried different transfer lengths? The phenomen sounds a lot like the drive not being able to provide as much data as requested and somehow hangs. I would try transfer lengths of 0, 8, 36 and 96.

I guess SCSI_Initialise 2 and 3 also fail for your device?

Does usbstack6 get you anywhere? I’ve faked the INQUIRY command

I’ve got it working with the stock USB stack. The issue was not dealing with Sense code &6,&28,0. The following code works without fail:

lun%=0     : REM UFI Floppy number
device%=0  : REM SCSI ID (dev + bus<<3 + lun <<5)

ON ERROR PRINT REPORT$;" at line ";ERL:PROCrequestsense:END
UFI_TEST_UNIT_READY=0
UFI_REQUEST_SENSE  =3
UFI_INQUIRY        =&12
UFI_SEND_DIAGNOSTIC=&1D
UFI_READ           =&A8

SCSI_READ=1<<24
SCSI_WRITE=1<<25

DIM cmd% 64, buf% 1024
cmd%!12=0
PROCinquiry
PROCread
END

DEF PROCinquiry
  PROCtestunitready
  cmd%!0=(lun%<<13)+UFI_INQUIRY
  cmd%!4=36      : REM bytes to read
  cmd%!8=0
  FOR A%=0 TO 35:buf%?A%=&FF:NEXT
  SYS "SCSI_Op", device%+SCSI_READ+(1<<27), 12, cmd%, buf%, cmd%?4
  PRINT "Inquiry:"
  OSCLI"MEMORY B "+STR$~buf%+"+24"
ENDPROC

DEF PROCtestunitready
  PROCtestunitready2
  PROCrequestsense
ENDPROC

DEF PROCtestunitready2
  cmd%!0=(lun%<<13)+UFI_TEST_UNIT_READY
  cmd%!4=0
  cmd%!8=0
  SYS "SCSI_Op", device%+(1<<27), 12, cmd%
ENDPROC

DEF PROCrequestsense
  OK%=FALSE
  WHILE NOT OK%
    cmd%!0=(lun%<<13)+UFI_REQUEST_SENSE
    cmd%!4=18      : REM bytes to read
    cmd%!8=0
    SYS "SCSI_Op", device%+SCSI_READ+(1<<27), 12, cmd%, buf%, cmd%?4
    E%=((buf%?2)<<16)+((buf%?12)<<8)+(buf%?13)
    IF E%<>0 THEN PRINT "Sense=";~buf%?2;",";~buf%?12;",";~buf%?13
    OK%=TRUE
    IF E%=&062800 THEN
      OK%=FALSE
      PROCtestunitready2
    ENDIF
  ENDWHILE
ENDPROC

DEF PROCread
  PROCtestunitready
  cmd%!0=(lun%<<13)+UFI_READ
  cmd%!4=0
  cmd%!8=1<<8      : REM blocks to read
  SYS "SCSI_Op", device%+SCSI_READ+(1<<27), 12, cmd%, buf%, (cmd%?9)*512
  OSCLI"MEMORY B "+STR$~buf%
  PROCrequestsense
ENDPROC

This doesn’t however work with usbstack5 or 6.

usbstack6 does show the filer icon for the floppy can be catalogued, although it does randomly hang my machine for no reason. That might be down to the Reporter SWI’s, from experience they cause all sorts of issues when threaded.

Put a non-debug build up and I’ll see if that hangs to see if it’s a USB stack issue.

usbstack7

This version only fakes inquiry for your specific device.

scsidevices should say fake.

That might be down to the Reporter SWI’s, from experience they cause all sorts of issues when threaded.

If you could report any problems direct to me, they will stand some chance of being fixed.

This version only fakes inquiry for your specific device.

There’s no need to fake it, INQUIRY works fine provided it waits for the device to become ready. The Sense code it returns when inserted is 6,&28,0 (NOT READY TO READY TRANSITION – MEDIA CHANGED), so as per my code above, provided that sense is handled by waiting in a loop polling TEST_UNIT_READY followed by REQUEST SENSE until it returns 0,0,0 – INQUIRY works.

That sounds perfectly reasonable to me, as the device has said its not ready.

Why my code example doesn’t work with the new stack I don’t know, does it work for you? If you want me to try and debug it? We’ll need to fix the random lock ups first and sort out the dropped key events so I can type!

If you could report any problems direct to me, they will stand some chance of being fixed.

If I could give you something concrete to go on I would. It’s completely random and I can’t reliably reproduce it, so I can’t give you anything other than calling Reporter SWI’s can cause machine locks and crashes. The best I can offer is it’s possibly a reentrancy issue somewhere in Reporter, such as calling an OS SWI that doesn’t work under IRQ, or is not reentrant, or possibly calling anything related to FileCore.

There’s no need to fake it, INQUIRY works fine

I know it does this log shows it.

Why my code example doesn’t work with the new stack I don’t know, does it work for you?

It’s not really relevant for the purpose of the exersize. usbstack was a way for me to quickly write a umass driver to determine if floppies were supported by the NETBSD umass drivers or whether the problem was with the ROOL SCSISoftUSB. The ROOL version has messed about with the NetBSD code as well as having a complex method of passing the commands on to the NETBSD code due to the constraints of the DeviceFS interface. I think I’ve established that the problem is with the ROOL port as the usbstack version works for everyone except you. It gives me an understanding for where to look for the problem when trying to fix the ROOL SCSISoftUSB. I’m waiting for a floppy to arrive to tackle that – if anyone sees a tortoise on the A1 with a floppy strapped to its back heading north can they give it a lift.

Having established that I can get a floppy working from the NetBSD code I tried to find out what is different with your device and it turns out that INQUIRY fails at startup and you’ve established that that is because the device isn’t ready. You have been able to get it to work by waiting for it to be ready. The problem isn’t that it isn’t ready it’s how it fails because it’s not ready. If it failed normally then the SCSI front end could be informed and it would deal with it.

SCSISoftUSB issues no SCSI commands it just passes them through to the device so changing what commands are used is not strictly relevent to SCSISoftUSB – and not particularly easy when dealing with state machines. The SCSI frontend sends SCSISoftUSB INQUIRY on attachment and this is failing for your device – for everyone else this isn’t a problem.

You having keyboard problems with usbstack when other people don’t is another mystery. Debugging it is a battle for another day. usbstack is not something I’d release it was just a proof of concept demonstrating a RISCOS USB stack with a NetBSD interface as well as the the DeviceFS interface for backward compatability. This makes porting easier and also brings the keyboard and mouse into their own module making them easily replacable. I’d really like to try to do a version with the latest NetBSD code but the compiler is a problem.

If you are having problems with reporter you do realise that you are running another module which outputs to reporter – looks like a joystick module.

My floppy arrived and the drive works normally with usbstack.

Out of interest this is the list of commands sent from plugging in to clicking on the icon bar icon.

The first 4 commands are sent at plugin. The first INQUIRY command is sent by SCSIFS – it looks like it’s to verify the device is there. The next 3 commands are from SCSISwitch. An ENQUIRY and READ_CAPACITY from scsi_determine_device and a REQUEST_SENSE which is sent when the READ_CAPACITY fails.

The rest of the commands are the result of clicking on the iconbar icon.

SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x25, len=8
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x03, len=8
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x25, len=8
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x25, len=8
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=4608
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x12, len=36
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x25, len=8
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=3072
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x00, len=0
 SSUMod: umass_cbi_transfer (1422):: umass_cbi_transfer cmd=0x28, len=512

Out of interest this is the list of commands sent from plugging in to clicking on the icon bar icon.

And it is a perfectly fine sequence for any standard-conforming device. The standard makes it very clear that INQUIRY is a special command that MUST ALWAYS RETURN, no matter if the device has just been switched on, is spinning up its media or is in suspend mode.

While you’re looking at SCSIFS, why not make it also try READ CAPACITY (16) to cater for larger media…the currently used READ CAPACITY (10) is limited to reporting 1 TiB if 512 byte blocks are used. Oh, and why not support different block sizes than 512 bytes…

While you’re looking at SCSIFS,

Nice try :-)

I have ROOL SCSISoftUSB working but unfortunately it fails for files bigger than 512KB – usbstack version doesn’t have this problem. It’s weird the way that ROOL SCSISoftUSB works.

I have a program I use to read and write a file and check that the file read back is identical to the file written and time the read and writes. The rool version writes and reads almost instantly and the program finishes – I doubt that floppies do 60MB/s – then a few seconds later the disc starts up and I suppose the write actually starts. It doesn’t appear to actually read from the disc. There must be a 512KB buffer somewhere.

There’s a bug in there somewhere.

It turns out that if you have FAT32FS installed ROOL SCSISoftUSB won’t transfer files greater than 512K kill FAT32FS and it works fine.

It turns out that if you have FAT32FS installed ROOL SCSISoftUSB won’t transfer files greater than 512K kill FAT32FS and it works fine.

I assume you’re using the latest version – the one bundled with RISC OS is out of date.

I now have four floppy drives to play with:

MITSUMI USB FDD 1039
TEAC FD-05PUB 3000
Y-E USB-FDU DATA 6.01 (original drive I was testing)
Y-E USB-FDU DATA 7.03

They all work under usbstack7, Windows 10 and Stretch. Under usbstack5 the MISTUMI works, the Y-E DATA’s predictably fail on INQUIRY and the TEAC locks the machine on INQUIRY.

You can try SCSISoftUSB if you like.

It won’t write files greater than 512KB with fat32fs, it will read. The new version of fat32fs made no difference. I don’t think the problem is fat32fs as usbstack7 works ok. If you kill fat32fs this version works for me. You may or maynot have problems with INQUIRY as the ROOL version is lacking returned status errors an I’m not messing about with exception code until it works.

I take it that you didn’t have problems with keypresses with usbstack7 – the version without debug code.

You can try SCSISoftUSB if you like.

Works great, all four drives worked. All we need now is a proper Filer, with Format/Verify and a floppy drive icon!

I take it that you didn’t have problems with keypresses with usbstack7 – the version without debug code.

I never got to test it, it was locking up within seconds of loading the stack, so I modified the script to ID the floppy drive as soon as it loaded. Obviously Reporter wasn’t the issue.

While clearing out some stuff a few days ago, I found a USB floppy drive. Although it’s labelled “http://www.smartdisk.com”, it’s a Teac FD-05PUB, 0644:0000.

Although this thread is about a USB floppy drive on a Pi, and I use a BBxM, I thought I’d give it a go, using SCSISoftUSB from two posts above. And it works, basically.

I found one oddity straight away. The disc was write protected and I tried to write a file to it, after successfully reading a few files. The icon of the new file appeared in the directory viewer, but I then got an error window about read-only. On aborting the operation, the icon was still there in the viewer. Deleting the file deleted the icon but then gave a read-only error.

So it’s mostly good news.

I’m amazed that the power supply powers the BBxM, a 7 port hub, a 120GB SSD, a keyboard and a mouse, a MIDI adapter, my mobile phone (on charge) and the floppy.

Would this USB floppy – work with a Iyonix?

How far can it be made to work – ie RO formats?

Sorry for the delay I’ve had the flu.

Works great, all four drives worked.

I can’t get it to work with fat32fs for files greater then 512KB can you try scsisoftusbtest

It contains the scsisoftusb module and a !LanManTest program. If after loading scsisoftusb if the device is Fat32fs::Fat32_0 then Lanmantest will work unmodified. If not you need to modify the line

PROCtest("Fat32fs::Fat32_0")

to point to your floppy. Once it points to your floppy run it and it will try and read/write a 1 MB file. This fails for me. If I rmkill fat32fs and point LanManTest to the new drive name then running the program will work fine.

Does it work properly with Fat32FS for you?