ioctl, how do I figure out request codes?

This is a discussion on ioctl, how do I figure out request codes? within the Linux Programming forums, part of the Platform Specific Boards category; I would wish to control an usb floppy drive to see if it might be possible to read 720k DD ...

  1. #1
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485

    ioctl, how do I figure out request codes?

    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?
    Last edited by Subsonics; 04-07-2010 at 08:54 AM.

  2. #2
    {Jaxom,Imriel,Liam}'s Dad Kennedy's Avatar
    Join Date
    Aug 2006
    Location
    Alabama
    Posts
    1,065
    Nope. The hardware cannot see the disks, neither can Linux.

  3. #3
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    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.
    Last edited by MK27; 04-07-2010 at 09:36 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #4
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    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:

    Code:
    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.

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Subsonics View Post
    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
    Last edited by MK27; 04-07-2010 at 10:16 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by MK27 View Post
    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.

    Quote Originally Posted by MK27 View Post
    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.

    Quote Originally Posted by MK27 View Post
    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.

  7. #7
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    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.

  8. #8
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    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

  9. #9
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Subsonics View Post
    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.
    Last edited by MK27; 04-10-2010 at 06:04 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  10. #10
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by MK27 View Post
    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.

    Quote Originally Posted by MK27 View Post
    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.

  11. #11
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. ioctl request to get the HW address
    By threahdead in forum Linux Programming
    Replies: 7
    Last Post: 01-03-2008, 01:34 AM
  2. sending https request
    By sreenu_daram in forum Networking/Device Communication
    Replies: 1
    Last Post: 08-05-2006, 10:08 AM
  3. request for students
    By djp in forum C Programming
    Replies: 5
    Last Post: 06-23-2003, 03:01 PM
  4. denied request
    By Unregistered in forum C++ Programming
    Replies: 1
    Last Post: 09-21-2001, 12:35 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21