Re: formatting a floppy? - Fdutils

11 Oct 2004


      Mark Hounschell wrote:
...
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...
My second email I cc'd myself. The first I did not. I have just
additionally subscribed with my work email address also.
...
...
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?
Yes, I've tried to read/write all the other sectors. Only sector 1 (1
relative) works.
...
[...]
...
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).
Understood. I will investigate this. But it's a very simple for loop..
...
[...]
...
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
harley:# time fdrawcmd readid 0 repeat=26
0: 0
1: 0
2: 0
3: 0
4: 0
5: 11
6: 1
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 0
6: 12
no disk change
0: 0
1: 0
2: 0
3: 1
4: 0
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: 13
4: 1
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 14
5: 1
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 15
6: 1
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 1
6: 1
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 0
6: 2
no disk change
0: 0
1: 0
2: 0
3: 1
4: 0
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: 3
4: 1
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 4
5: 1
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 5
6: 1
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 0
6: 6
no disk change
0: 0
1: 0
2: 0
3: 1
4: 0
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 8
5: 1
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 9
6: 1
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 0
6: a
no disk change
0: 0
1: 0
2: 0
3: 1
4: 0
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: b
4: 1
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: c
5: 1
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: d
6: 1
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 0
6: e
no disk change
0: 0
1: 0
2: 0
3: f
4: 1
5: 0
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 10
5: 1
6: 0
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 11
6: 1
no disk change
0: 0
1: 0
2: 0
3: 0
4: 0
5: 0
6: 12
no disk change
real    0m0.682s
user    0m0.000s
sys     0m0.000s
Does the above indicate my track buffer contents are not right?
Regards
Mark
_______________________________________________
fdutils mailing list
fdutils@tux.org
http://www.tux.org/mailman/listinfo/fdutils