I have been trying now for a couple of weeks to successfully format a floppy using the raw_cmd API as is done in the superformat pgm. I am trying to write some software using the raw_cmd API that will enable me to read/write and create floppies for an older legacy computer. So far I can successfully read and write the floppies previously formatted on these leagacy machines. However, I seem to be unable to format a floppy on a PC using the software I have written that can be used on these legacy machines. In fact I cannot even format one that I can use on the PC within my application. I've even tried using a "standard" format on the PC and am still unsuccessfull. My symptoms are that, after formatting a track I can only read/write the first sector of the track. All attempts to read or write a sector other than the first fails with a cmd_reply of. I'm using the info at
http://debs.future.easyspace.com/Programming/Hardware/FDC/floppy.html#Data
as my reference and also the source code of fdutils.
reply_count = 0x00000007 40 04 10 00 00 02 02 00 00 00 00 00 00 00 00 00
Can someone possibly help? I can provide code and debug information. I didn't send any with this query as I'm not sure this is the correct place to inquire.
Thanks in advance Mark _______________________________________________ fdutils mailing list fdutils@tux.org http://www.tux.org/mailman/listinfo/fdutils
On Sunday 10 October 2004 22:44, Mark Hounschell wrote:
My symptoms are that, after formatting a track I can only read/write the first sector of the track. All attempts to read or write a sector other than the first fails with a cmd_reply of. I'm using the info at
This could be due to a bad number of bytes in your sector descriptor during formatting: you need 4 bytes (cylinder, head, sector, size).
If for whatever reason, you have more than 4, this will shift the descriptors for the following sectors, makeing those headers useless.
Example (the 5 first sectors on a normal floppy, on cylinder 1):
1 0 1 2 1 0 2 2 1 0 3 2 1 0 4 2 1 0 5 2
Now, suppose that for each sector, you have one extra byte. You'll get:
1 0 1 2 9 1 0 2 2 9 1 0 3 2 9 1 0 4 2 9 1 0 5 2 9
Which will be interpreted by the FDC as:
1 0 1 2 9 1 0 2 2 9 1 0 3 2 9 1 0 4 2 9 1 0 5 2 9 ...
===> All sectors, except the first have bad headers, and are thus unreadable! However, number 5 is again in sync, and readable (and so would be number 9, 13, ...). Could you test whether these sectors are readable in your case? If so, this is a strong indication that there are indeed too many bytes in the format descriptor.
------ Another theory might be that only one sector is getten written, for whatever reason.
One command which helps to check out what headers you have go is the following:
fdrawcmd readid 0 repeat=18
This repeats the readid command 18 times, and shows you what headers you've got on the 18 first sectors of the current cylinder (the headers are the 4 last bytes of each reply).
(If only only one sector is present, the command still repeats 18 times, but will read the same sector over and over again. Apart from the identical headers, this situation can be detected by the duration: command takes 3.6 seconds instead of 0.2)
http://debs.future.easyspace.com/Programming/Hardware/FDC/floppy.html#Data
as my reference and also the source code of fdutils.
reply_count = 0x00000007 40 04 10 00 00 02 02 00 00 00 00 00 00 00 00 00
Now, which command gave you this reply? Format? Read? It's odd also that it's so long (16 bytes); most FDC commands are only 7 bytes, which might again point to some off-by-one errors (or in this case, off-by-9...) in your program ;-)
Can someone possibly help? I can provide code and debug information. I didn't send any with this query as I'm not sure this is the correct place to inquire.
Thanks in advance Mark
Yes, the relevant parts of code would be appropriate on this list (don't send 50 KB worth of code. But code snippets of 1 or 2 pages of the important part of the program are definately ok)
Regards,
Alain
Mark Hounschell wrote:
reply_count = 0x00000007 40 04 10 00 00 02 02 00 00 00 00 00 00 00 00 00
40 -> Abnormal termination of command 04 -> "No Data", but most likely the sector couldn't be found? 10 -> Missing Data Address Mark for the sector
It does seem like only the first sector made it to the disk. Try scanning the first track for sectors using (rate assumes double-density): fdrawcmd readid 0 rate=2 need_seek track=0 repeat=10
Could you provide any more details on the data you're sending for the format? For a regular 720K DOS disk it'd be:
4D ; format track command, mfm 00 ; physical head 0, drive 0 02 ; 512 byte sectors 09 ; 9 sectors per track 50 ; gap 3 00 ; data fill
00 00 01 02 ; cyl 0, head 0, sector 1, size 512 bytes 00 00 02 02 ; cyl 0, head 0, sector 2, size 512 bytes 00 00 03 02 etc.
Admittedly, I'm doing my own formatting on Windows XP rather than through fdutils on Linux. The way it's sent might be different but the underlying data should be the same.
Best regards,
Si
_______________________________________________ fdutils mailing list fdutils@tux.org http://www.tux.org/mailman/listinfo/fdutils
Mark Hounschell wrote:
reply_count = 0x00000007 40 04 10 00 00 02 02 00 00 00 00 00 00 00 00 00
40 -> Abnormal termination of command 04 -> "No Data", but most likely the sector couldn't be found? 10 -> Missing Data Address Mark for the sector
It does seem like only the first sector made it to the disk. Try scanning the first track for sectors using (rate assumes double-density): fdrawcmd readid 0 rate=2 need_seek track=0 repeat=10
Could you provide any more details on the data you're sending for the format? For a regular 720K DOS disk it'd be:
4D ; format track command, mfm 00 ; physical head 0, drive 0 02 ; 512 byte sectors 09 ; 9 sectors per track 50 ; gap 3 00 ; data fill
00 00 01 02 ; cyl 0, head 0, sector 1, size 512 bytes 00 00 02 02 ; cyl 0, head 0, sector 2, size 512 bytes 00 00 03 02 etc.
Admittedly, I'm doing my own formatting on Windows XP rather than through fdutils on Linux. The way it's sent might be different but the underlying data should be the same.
Best regards,
Si
Hello Si. Strange that I had to actually go to the archives to find your response. I'm a list member but nothing has been sent to me??? I'm sure I'm not in digest mode?? Oh well. Here is some more info. The main format I'm using is DS DD at 77 cylinders 2 heads 26 sectors per track at 256 bytes per sector. Here is some debug printfs of the raw_cmd structure before and after execution as well as the track format buffer sent. I only include the info for the first track as every track formatted has the same results. I can read the first sector only of every track I formatted.
Fot the FDSETPRM ioctl:
medprm.size = 0x00000fa4 medprm.sect = 0x0000000d medprm.head = 0x00000002 medprm.track = 0x0000004d medprm.stretch = 0x00000000 medprm.gap = 0x0000001b medprm.rate = 0x00000038 medprm.spec1 = 0x00000000 medprm.fmt_gap = 0x0000006c medprm.name = 0x00000000
About to format cyl 0 through cyl 76 total # tracks 154
Track Format buffer for cyl 0 head 0 For Sector 00: 0x00 0x00 0x01 0x01 For Sector 01: 0x00 0x00 0x02 0x01 For Sector 02: 0x00 0x00 0x03 0x01 For Sector 03: 0x00 0x00 0x04 0x01 For Sector 04: 0x00 0x00 0x05 0x01 For Sector 05: 0x00 0x00 0x06 0x01 For Sector 06: 0x00 0x00 0x07 0x01 For Sector 07: 0x00 0x00 0x08 0x01 For Sector 08: 0x00 0x00 0x09 0x01 For Sector 09: 0x00 0x00 0x0a 0x01 For Sector 10: 0x00 0x00 0x0b 0x01 For Sector 11: 0x00 0x00 0x0c 0x01 For Sector 12: 0x00 0x00 0x0d 0x01 For Sector 13: 0x00 0x00 0x0e 0x01 For Sector 14: 0x00 0x00 0x0f 0x01 For Sector 15: 0x00 0x00 0x10 0x01 For Sector 16: 0x00 0x00 0x11 0x01 For Sector 17: 0x00 0x00 0x12 0x01 For Sector 18: 0x00 0x00 0x13 0x01 For Sector 19: 0x00 0x00 0x14 0x01 For Sector 20: 0x00 0x00 0x15 0x01 For Sector 21: 0x00 0x00 0x16 0x01 For Sector 22: 0x00 0x00 0x17 0x01 For Sector 23: 0x00 0x00 0x18 0x01 For Sector 24: 0x00 0x00 0x19 0x01 For Sector 25: 0x00 0x00 0x1a 0x01 format_floppy_disk: raw_cmd struct before: flags = 0x000000da data = 0xbe1fbf9c kernel_data = 0xbe1ffa54 next = 0x401f8160 length = 0x00000068 phys_length = 0x401f4ee0 buffer_length = 0xbe1ffaa4 rate = 0x00000000 cmd_count = 0x00000006
4d 00 01 1a 36 a5 00 00 00 00 00 00 00 00 00 00 reply_count = 0x00000004 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 track = 0x00000000 resultcode = 0x401f4ee0 reserved1 = 0x00000000 reserved2 = 0x00000000
format_floppy_disk: raw_cmd struct after:
flags = 0x000000da data = 0xbe1fbf9c kernel_data = 0xc0ef3000 next = 0x00000000 length = 0x00000000 phys_length = 0x401f4ee0 buffer_length = 0x00000068 rate = 0x00000000 cmd_count = 0x00000006
4d 00 01 1a 36 a5 00 00 00 00 00 00 00 00 00 00 reply_count = 0x00000007 00 00 00 00 02 1a 01 00 00 00 00 00 00 00 00 00 track = 0x00000000 resultcode = 0x00000000 reserved1 = 0x00000000 reserved2 = 0x00000000
The readid command suggested above: I have modified the fdrawcmd to display the raw_cmd structure BTW.
./fdrawcmd readid 0 rate=2 need_seek track=0 repeat=10 raw_cmd struct before:
flags = 0x00000088 *data = 0xbfff9240 *kernel_data = 0x00000000 *next = 0x00000000 length = 0x00006000 phys_length = 0x00000000 buffer_length = 0x00000000 rate = 0x00000002 cmd_count = 0x00000002
ea 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 reply_count = 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 track = 0x00000000 resultcode = 0x00000000 reserved1 = 0x00000000 reserved2 = 0x00000000
raw_cmd struct after:
That fails but when I use a rate = 0 I get:
markh@harley:/9.1/dnld/import/inst/fdutils-5.4/src> ./fdrawcmd readid 0 rate=0 need_seek track=0 repeat=10 raw_cmd struct before:
flags = 0x00000088 *data = 0xbfff9240 *kernel_data = 0x00000000 *next = 0x00000000 length = 0x00006000 phys_length = 0x00000000 buffer_length = 0x00000000 rate = 0x00000000 cmd_count = 0x00000002
ea 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 reply_count = 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 track = 0x00000000 resultcode = 0x00000000 reserved1 = 0x00000000 reserved2 = 0x00000000
raw_cmd struct after:
flags = 0x00000088 *data = 0xbfff9240 *kernel_data = 0x00000000 *next = 0x00000000 length = 0x00006000 phys_length = 0x00000000 buffer_length = 0x00000000 rate = 0x00000000 cmd_count = 0x00000002
ea 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 reply_count = 0x00000007 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 track = 0x00000000 resultcode = 0x00000000 reserved1 = 0x00000000 reserved2 = 0x00000000 0: 0 1: 0 2: 0 3: 1 4: 0 5: 0 6: 0 no disk change
Thanks and regards Mark _______________________________________________ fdutils mailing list fdutils@tux.org http://www.tux.org/mailman/listinfo/fdutils
On Monday 11 October 2004 12:03, Mark Hounschell wrote:
Hello Si. Strange that I had to actually go to the archives to find your response. I'm a list member but nothing has been sent to me???
Really strange, indeed. Especially since you were also Cc'ed on the mail directly...
I'm sure I'm not in digest mode?? Oh well. Here is some more info. The main format I'm using is DS DD at 77 cylinders 2 heads 26 sectors per track at 256 bytes per sector. Here is some debug printfs of the raw_cmd structure before and after execution as well as the track format buffer sent. I only include the info for the first track as every track formatted has the same results. I can read the first sector only of every track I formatted.
Did you also attempt reading the 5th, 9th etc sector? [...]
Track Format buffer for cyl 0 head 0 For Sector 00: 0x00 0x00 0x01 0x01 For Sector 01: 0x00 0x00 0x02 0x01 For Sector 02: 0x00 0x00 0x03 0x01 For Sector 03: 0x00 0x00 0x04 0x01 For Sector 04: 0x00 0x00 0x05 0x01
...
This looks ok, as long as there are no other bytes in between. Hard to tell from this output though. It might be useful to print out the raw trackbuffer to a file and do a hexdump on it. "Interpreting" the result could be misleading, as the interpreter might have the same flaw as the code that generates the buffer, and the error might cancel out in the screen output (but not in the data sent to the FDC).
[...]
length = 0x00000068
ok, buffer length does seem to be correct, so that is a good thing... ;-)
The readid command suggested above: I have modified the fdrawcmd to display the raw_cmd structure BTW.
Which is not a good idea, as it seems to have broken the "repeat" functionality on which we rely for this test. Could you please execute a your test with the stock fdrawcmd, and post the entire output of it? (without the extra debugging, it isn't that long). And maybe also inform us on how long (approx) it runs. This can be found out using the time command.
time fdrawcmd readid 0 repeat=26
./fdrawcmd readid 0 rate=2 need_seek track=0 repeat=10 raw_cmd struct before:
[...]
That fails but when I use a rate = 0 I get:
You must use the same rate as what you used for formatting. However, rate=0 does seem correct, as with the other rates there is no way of fitting 26 sectors of 256 on the disk...
markh@harley:/9.1/dnld/import/inst/fdutils-5.4/src> ./fdrawcmd readid 0 rate=0 need_seek track=0 repeat=10
[...]
0: 0 1: 0 2: 0 3: 1 4: 0 5: 0 6: 0 no disk change
Is this all replies you got? Or does it repeat 9 more times? Or is it followed by 9 other headers? IMHO, it would be really helpful if you could execute fdrawcmd as is....
Regards,
Alain
-
Alain Knaff -
Alain Knaff -
Mark Hounschell -
Simon Owen