Fdutils October 2004

fdutils@fdutils.linux.lu

5 participants
6 discussions

Autodetection of mode-0 or mode-1 floppies
by Mark Hounschell 13 Feb '05

13 Feb '05

I now have 99% compatability in my emulation of the legacy FDC controller mentioned in previous posts. It seems I have one small piece left. This legacy controller would automatically determine, at floppy insertion time, whether the floppy was formatted in mode-0 (zerobased) or mode-1 (non-zerobased). It would then set a bit in one of it's status registers so software would be aware of the format. It also determined the format type such as density, sectors per track, and sector size. Also made available to software. I understand how to use the readid rawcmd to determine all this information myself within my application. My only problem seems to be a good method of detecting a disk change in the floppy thread of my emulation. For this particular application, being able to set up a signal handler with the floppy driver for a disk change would have been ideal. I guess instead, I need to use the same method as done in the diskd program? However I cannot seem to get the diskd program to work as advertised. When I issue the following command, with no floppy inserted in the drive, in 10 seconds the ls command is executed. If I insert a floppy imediatly after issuing the command, it still waits 10 seconds then executes the ls command. #diskd -d /dev/fd0 -i 100 -e ls It appears that on my machine the FD_VERIFY bit is never being set and the FD_DISK_NEWCHANGE and FD_DISK_CHANGED bits are always set. I'm not sure what the FD_VERIFY bit has to do with a disk change. I'm also at a loss as to why the other 2 bits are always set. ??? Any suggestions welcome. Thanks in advance Mark _______________________________________________ fdutils mailing list fdutils(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

2 1

Re: [fdutils] zerobased floppy format ?
by Mark Hounschell 14 Oct '04

14 Oct '04

John Elliott wrote: > > : Do you use a 0 or 1 in the raw_cmd structure (raw_cmd.cmd[4]) to read or > : write the first sector of a track when the floppy is formatted in mode-0 > : (zerobased)? I realize I need the zerobase kernel patch for this. > > I don't think you do need the zerobase kernel patch if you're going to > be doing all your accesses with FDRAWCMD. I can read Acorn 640k ADFS discs > (16 sectors numbered 0 - 15) without a patched kernel, by using FDRAWCMD. > > -- > John Elliott Interesting. It's already been applied but I'll back it out once I have everything working like I want in Mode-0 and see for sure. Thanks Mark _______________________________________________ fdutils mailing list fdutils(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

1 0

zerobased floppy format ?
by Mark Hounschell 13 Oct '04

13 Oct '04

Do you use a 0 or 1 in the raw_cmd structure (raw_cmd.cmd[4]) to read or write the first sector of a track when the floppy is formatted in mode-0 (zerobased)? I realize I need the zerobase kernel patch for this. Thanks and regards Mark _______________________________________________ fdutils mailing list fdutils(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

3 2

Re: [fdutils] Re: formatting a floppy?
by Mark Hounschell 11 Oct '04

11 Oct '04

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(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

2 1

Re: formatting a floppy?
by Mark Hounschell 11 Oct '04

11 Oct '04

1 0

formatting a floppy?
by Mark Hounschell 11 Oct '04

11 Oct '04

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(a)tux.org http://www.tux.org/mailman/listinfo/fdutils

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Fdutils October 2004