USB FDD access

Paladin (686)

06-03-2018, 10:22

I am trying to use a USB FDD (Teac) with openMSX 0.14.0 on Linux.

As it is a USB disk drive, it is not seen as /dev/fd0, but is instead handled by usbstorage, as such it gets a /dev/sd* and /dev/sg* device IDs.
This also means that the traditional ways of accessing a specific size of disk no longer works, such as /dev/fd0D720, instead you can do a low-level format using ufiformat, after which you can format the device.

As I don't have any 2DD disks, I covered up the HD hole, and was able to use ufiformat to lowlevel format it as 720kB.
I changed permissions on /dev/sdb and /dev/sg2 such that 'other' has RW access.

$ sudo chmod o+rw /dev/sg2

$ sudo chmod o+rw /dev/sdb

$ ufiformat -i /dev/sdb
vendor:  TEAC
product: FD-05PUB
write protect: off
media type: 2DD
status      block size   kb
formatted    1440  512  720
formattable  1440  512  720

$ ufiformat -f 720 -v /dev/sdb
format on device=/dev/sdb, size=720
geometry: track=80, head=2, sector=9, block=512

$ dd if=MSX-DOS\ v1.8\ \(1986\)\(Microsoft\)\(US\).dsk of=/dev/sdb bs=512
1440+0 records in
1440+0 records out
737280 bytes (737 kB, 720 KiB) copied, 132.707 s, 5.6 kB/s

$ openmsx -machine msx2 -diska /dev/sdb

openmsx starts and the drive spins up for a moment, then stops and it boots to BASIC. 'files' gives Disk offline. Doing a call format and asking it to format as 2DD causes openMSX to core dump.

terminate called after throwing an instance of 'openmsx::NoSuchSectorException'
Aborted (core dumped)

Obviously I know I can just point openMSX directly to the dsk file, I am using the above as an example of what happens if I try to access a USB FDD.

ログイン/登録して投稿

By gdx

Enlighted (6429)

06-03-2018, 13:27

2DD floppy disk in USB drive do not seem to be supported on Windows 10 64bits and it's probably same on newer Mac OS.

By rderooy

Paladin (686)

06-03-2018, 14:48

gdx wrote:

2DD floppy disk in USB drive do not seem to be supported on Windows 10 64bits and it's probably same on newer Mac OS.

No idea, but as I indicated, this is neither Windows or MacOS. It is Linux.

By mtn

Champion (269)

06-03-2018, 19:10

Hmm. Are you sure that sdb1 isnt created during the formatting process? What does syslog say?

By rderooy

Paladin (686)

06-03-2018, 19:17

mtn wrote:

Hmm. Are you sure that sdb1 isnt created during the formatting process? What does syslog say?

I don't have the FDD connected right now. But sdb1 would imply partitioned media, and normally floppy disks are not partitioned.

By mtn

Champion (269)

06-03-2018, 19:43

Its possible to mount the formatted floppy directly under linux?

By rderooy

Paladin (686)

06-03-2018, 20:22

If you mean can I have openMSX directly use the dsk file, yes as indicated, that works fine and it will boot MSX-DOS. As I said, it was an example. The same thing happens regardless of which dsk file I use.

By Manuel

Ascended (19677)

07-03-2018, 00:00

This used to work on my PC about 15 years ago, and I'd expect it to work still. But apparently it doesn't. No idea why yet though... openMSX just accesses the device as if it's a file. It doesn't even know that there's a real floppy behind it.

By rderooy

Paladin (686)

07-03-2018, 07:55

Manuel, when you tried it, I assume this was using a legacy FDD using /dev/fd0?

Just as an additional comment, for those interested in trying this... To find which Linux DEV devices are associated with the USB FDD, you can simply do the following:

$ sudo ufiformat -i
disk         generic     
/dev/sdb     /dev/sg2

By wouter_

Hero (535)

07-03-2018, 09:08

OpenMSX expects the following from a disk image (either a real file or a device file like /dev/fd0).

1) It must allow random access in chunks of 512 bytes.
2) The layout (=order of the sectors) must be compatible with the layout of .dsk files.
3) It must be possible to query the filesize (to figure out how many sectors are present).

This used to work for /dev/fd0 in the past, but I haven't been able to test this myself for many years. I never tried it with a USB FDD.

One thing that _might_ have changed is point 3). In the past this was implemented as:
- seek to the end of the file, get the current file offset, seek back to the start
Now filesize is queried in a single step via fstat(). But I have no idea if this makes any difference. (Obviously it works fine for regular files).

Could you check if the USB FDD /dev/sdb file meets requirements 1-3?

By Manuel

Ascended (19677)

07-03-2018, 09:32

Indeed, as also wouter_ said, I used it with /dev/fd0. My current PC still has a built in disk drive, so I can still use it... But I never do, as it doesn't have any advantage to me.