ioctl, how do I figure out request codes?

[Subsonics]

I would wish to control an usb floppy drive to see if it might be possible to read 720k DD disks, as it is, it doesn't seem to like anything other than 1.44 mb HD disks. I've been looking around and it seems like most usb floppies only support 1.44mb disks, which seems kind of dumb the way I see it since the whole idea behind such a product should be backward comparability. Anyway, I can't even reach it thru it's raw device in the /dev folder, I mean I can see it and attempt to read from it. It tries and makes pathetic noises for a few minutes, then I'm presented with a popup dialog that the disk can't be read.

Edit:
It just occurred to me that it might also be the format (not FAT12) but I don't have any FAT12 formatted DD disks to try on, so.

Perhaps I might be able to do this with fcntl, what do you think?

[Kennedy]

Nope. The hardware cannot see the disks, neither can Linux.

[MK27]

I wouldn't be surprised if you cannot do it at all. It is not really a "backward comparability" issue -- formatting different densities on a 3.5" floppy has always been possible, there is nothing new about it, so there is nothing "old" or "legacy" about formats other than 1.44mb. Any other than 1.44 has been oddball since 5.25" disks. It's just a "limited functionality issue". You should have checked that out before you bought the device (altho I probably wouldn't have predicted that either, but caveat emptor).

If you really need to do this, go to a computer repair place and ask for an old floppy drive for $5. They probably have a pile of them that have barely even been used. Even a brand new one is less than $20, you plug an IDE cable in and get:

fd0
fd0u1040
fd0u1120
fd0u1440
fd0u1600
fd0u1680
fd0u1722
fd0u1743
fd0u1760
fd0u1840
fd0u1920
fd0u360
fd0u720
fd0u800
fd0u820
fd0u830

in /dev.

[Subsonics]

Ok, but the device that the disk is from (80's drum machine) only takes double density disks ie 750kb, although I have used HD disks on it successfully. But in this scenario it should be formatted with the lower density of the DD disks then. I also know nothing about the filesystem used (or sector sizes) I don't really know. I managed to get the block size with this:

ioctl( fileDescriptor, DKIOCGETBLOCKSIZE, &blockSize );

And it returns 512, but my guess is that it could be based on the system definition of a floppy.
Also, a DD disk should atleast have the information spread out more sparsely than the HD disks, same size twice the capacity.

[MK27]

my guess is that it could be based on the system definition of a floppy.

My guess is there is no such thing as a system definition of a floppy. "fd0", for example, is not a default alias for "fd0u1440" -- it simply refers to whatever disk is actually present IF the device can successfully read it. If not, then it does not refer to anything.

as it is, it doesn't seem to like anything other than 1.44 mb HD disks
[...]
Anyway, I can't even reach it thru it's raw device in the /dev folder, I mean I can see it and attempt to read from it. It tries and makes pathetic noises for a few minutes, then I'm presented with a popup dialog that the disk can't be read.

Which sounds like the device is sending an error because it cannot deal with reading the disk. I would do some product investigation of the device, maybe even inquire to the manufacturer. If the drive only reads 1.44 HD disks, do you really believe you can somehow get around this problem?

You may want to look at "setfdparm", I notice it is not on my current system, but I seem to remember it had a config file in /etc. Again, I doubt this will help, but you never know.

http://www.bigbiz.com/cgi-bin/manpage?8+setfdprm

[Subsonics]

My guess is there is no such thing as a system definition of a floppy. "fd0", for example, is not a default alias for "fd0u1440" -- it simply refers to whatever disk is actually present IF the device can successfully read it. If not, then it does not refer to anything.

The reason for that is that there are definitions for Cd roms in a header file, and upon a failed call to ioctl, it's set manually to the system defined constant in the code example where I found the DKIOCGETBLOCKSIZE constant. But in my case, the ioctl call got 512 so it doesn't apply here after all. But it's kind of odd that it managed to get it at all I think. The disk becomes visible in the /dev folder after, say 30 seconds or so, and during this time I was able to run it. I tried to add a read of that block but it returned -1, so no luck there.

Which sounds like the device is sending an error because it cannot deal with reading the disk. I would do some product investigation of the device, maybe even inquire to the manufacturer. If the drive only reads 1.44 HD disks, do you really believe you can somehow get around this problem?

Yes that is my conclusion as well, but since some floppy drives can read DD disks and HD disks I kind of hoped that it could perhaps come down to wether the firmware of the disk controller had support for it or not. And then, maybe, thus a slim chance of success with ioctl. I don't know, the thing is that I do this in part to be able to exchange disks, and also because it could be fun.

You may want to look at "setfdparm", I notice it is not on my current system, but I seem to remember it had a config file in /etc. Again, I doubt this will help, but you never know.

UNIX Manual Page: man 8 setfdprm

Thanks, I'll look into that, I use os x here so it may not apply here either though.

[Subsonics]

I found an old atari st disk (fat12 more or less I think) that is also on a dd disk. It actually stays in the /dev folder, and I was also able to read the first 512k block after the ioctl call. So it seems like it might be the formating of the disk. I found this link with some information that indicates that the layout of the data can vary quite a lot, which makes sense since floppies are also low level formatted during the formatting process as far as I know.

[Subsonics]

So, expanding this a bit. How can I control the hardware directly from user space? Is it possible at all without a purpose made kext? I have found some info on usb mass storage devices and it seems like they use scsi control commands wrapped in usb packets. t10 have them available but for a membership fee. Are they out there any where (tried google)? How limited is the control given by usb? I should be able to set disk geometry and define gaps between sectors and so on right?

I found this which was interesting but it seems like it is not directly relevant for usb devices.

Floppy Disk Controller - OSDev Wiki
http://bos.asmhackers.net/docs/flopp...y_tutorial.txt

[MK27]

So, expanding this a bit. How can I control the hardware directly from user space? Is it possible at all without a purpose made kext?

If a kext is like a kernel module, aka device driver, the answer for linux is no. You can't communicate with a device except thru a kernel space tool like a driver. And you probably don't have a driver to do what you want here.

Not to be discouraging, but stop wasting your time and accept the fact that you bought the wrong device, and/or ye olde drum machine is what it is. I dunno about mac hardware, but surely you can attach a IDE cable to the mobo and just use a real floppy drive?

Other option: if you do have access to a linux box with a floppy, it will mount any density (AFAIK -- it seems set up to do so, I don't have any weirdo disks to test). You can do a raw copy into a disk image this way:

dd if=/dev/fd0u720 of=image.iso bs=1k count=720

You can then mount the iso as a filesystem/device. Not completely sure if .iso's are really that simple, but something like this should be possible. Maybe better to consider it a "raw" image. I have definitely done this with floppies (read and written images to them that are mountable) I can't remember the details. The image contains a filesystem of whatever type.

[Subsonics]

If a kext is like a kernel module, aka device driver, the answer for linux is no. You can't communicate with a device except thru a kernel space tool like a driver. And you probably don't have a driver to do what you want here.

Kext, aka kernel extension, drivers are kexts on the mac and either added at a reboot or with a kextload command from the command line.

Other option: if you do have access to a linux box with a floppy, it will mount any density (AFAIK -- it seems set up to do so, I don't have any weirdo disks to test). You can do a raw copy into a disk image this way:

dd if=/dev/fd0u720 of=image.iso bs=1k count=720

Yes, that was my first plan, it sure works with the atari disk. What shows up in the /dev folder is not the floppy drive but the diskette itself though. I don't really know why the drum machine disk wont show up, I don't attempt to mount it or anything like it. My guess is that it has the data laid out in some unconventional way, so that when the drive starts looking at the disk, it does not find what it expect.

I might try the Linux route if for nothing else to satisfy my curiosity.

[Subsonics]

I tried it in Linux now, with the same result. I can use data dump (dd) or xxd or cat, strings etc on the raw device as long as it is the atari disk but not on my drum machine disk. On the OS-dev link they mention three modes of operation on floppy drives PC-AT mode, PS/2 mode, and Model 30 mode. Perhaps this is the source of the problem, although apparently the latest generations of controller chips can operate in all these modes. But, as this is an USB device my only hope for changing the mode would be thru software, ie one of the scsi control commands, if there is support for it that is.