Reading dodgy old HD 5.25" disks
Will fdrawcmd let me ignore CRCs and just got whatever is there?
Hmmm, some sniffing around suggests that these disks have a proprietary format. The first cylinder is normal, but after that, the next 21 cylinders don't even have a sector 0. I suspect there are 14 sectors of non-standard sizes, so this is all going to be great fun. Regards Ian
On 12/01/11 12:03, Ian Oliver wrote:
Will fdrawcmd let me ignore CRCs and just got whatever is there?
Hmmm, some sniffing around suggests that these disks have a proprietary format. The first cylinder is normal, but after that, the next 21 cylinders don't even have a sector 0. I suspect there are 14 sectors of non-standard sizes, so this is all going to be great fun.
Regards
Ian
There normally isn't a sector 0, it usually starts at 1. Regards, Alain
In article <4D2D9C57.2070408@knaff.lu>, Alain Knaff wrote:
There normally isn't a sector 0, it usually starts at 1.
Sorry, my mistake, it's sector 1 they lack. I'm seeing numbers from 2 to F but no 1. ddrescue was seeing a single sector it couldn't read at the start of cylinders 1 to 21. I've read/written mixed sector disks in the past, but they normally have a few huge sectors, a few smaller, and then some packing ones. Dropping from 15 to 14 seems odd, but I need to get poking around again and make note of the sizes that are reported for the sectors. I then have no idea what happens after sector 21. ddrescue claimes to have read all the data without problems, but I'm dubious. I also expect more than 80 tracks on these disks. I guess I'm going to have to write some fancy bash/python scripts to drive fdrawcmd to pull this stuff off (and the disks are old so I'll need lots of retries) and then some more to format and write some new disks. Ian
Ian Oliver wrote:
In article <4D2D9C57.2070408@knaff.lu>, Alain Knaff wrote:
There normally isn't a sector 0, it usually starts at 1.
Sorry, my mistake, it's sector 1 they lack. I'm seeing numbers from 2 to F but no 1. ddrescue was seeing a single sector it couldn't read at the start of cylinders 1 to 21.
Are you sure the drive is good? I just wonder if the heads are seriously misaligned, which might explain the strange format that it's seeing (or they were on the drive that wrote the disks, which might make life interesting!) cheers Jules
In article <4D2DAB97.9070206@yahoo.co.uk>, Jules Richardson wrote:
Are you sure the drive is good? I just wonder if the heads are seriously misaligned, which might explain the strange format that it's seeing (or they were on the drive that wrote the disks, which might make life interesting!)
I've tried two different drives and I get the same results. A bit more digging suggests that I'm only seeing the first sector of each cylinder as absent due to some artifact of the read process; the first sector on the second head is also MIA but ddrescue seemed to think it had read it OK. I've read (and restored) loads of other floppies on the same hardware, so I am tending towards thinking it's a proprietary/odd format. As for why this is only the case for the first 20-30 cylinders (after the first one) is also a mystery - I tried and I can happily load sector one from higher tracks. Of course, it could be that the normal 15 sectors should be there, but YOY would there be no sign of them? I can't read them with fdrawcmd rear and issuing multiple readid commands shows all the other sectors but not sector one. I'll do more playing this evening, mainly using readid, and see how big the 14 sectors are. Ian
In article <VA.00002914.014f3b9f@foxhill.co.uk>, Ian Oliver wrote:
I've tried two different drives and I get the same results.
Hmmmm. The first cylinder reads fine and contains a much-compressed DOS file system holding just one file of 1213440 bytes. As this is 79*30*512, I'm guessing the other tracks should all have 15 sectors on each side and something deeply odd is going on that is making sector one on each track hard/impossible to read. I guess it's time to try a new motherboard and/or cable. Regards Ian
OK, here are the commands I'm using and the output. ------------------------------------- floppycontrol --resetnow 2 fdrawcmd drive=/dev/fd0 rate=0 readid 0 need_seek track=0 i=1 fdrawcmd drive=/dev/fd0 seek 0 $i # drvsel cyl head sect szcod spt rw-gap szcod2 fdrawcmd drive=/dev/fd0 rate=0 read 0 $i 0 1 2 15 0x1b 0xff length=512 >> $1 Reset Recal 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change Seek 0: 20 1: 1 no disk change remaining= 512 0: 40 1: 4 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change ------------------------ So, ST0= 0x28, which is Seek End and Not Ready, and ST1= 4, so No Data. Using readid to "scan" the whole track shows that sectors 1 to 15 are all there and are all 512 bytes long (szcod = 2) Any ideas? Ian
Back in the day 5.25" disks were sometimes (or usually) laid out with sectors out of order, because CPUs were really slow and couldn't read the sectors as they came by and fdcs did not have a buffer to hold the sectors until the host requested them. So they would take 2 or 3 revolutions to read each side of the disk. Could it be you just start at 2 but there is a 1 later on? DCN On Wed, 12 Jan 2011, Ian Oliver wrote:
In article <4D2D9C57.2070408@knaff.lu>, Alain Knaff wrote:
There normally isn't a sector 0, it usually starts at 1.
Sorry, my mistake, it's sector 1 they lack. I'm seeing numbers from 2 to F but no 1. ddrescue was seeing a single sector it couldn't read at the start of cylinders 1 to 21.
I've read/written mixed sector disks in the past, but they normally have a few huge sectors, a few smaller, and then some packing ones. Dropping from 15 to 14 seems odd, but I need to get poking around again and make note of the sizes that are reported for the sectors.
I then have no idea what happens after sector 21. ddrescue claimes to have read all the data without problems, but I'm dubious. I also expect more than 80 tracks on these disks.
I guess I'm going to have to write some fancy bash/python scripts to drive fdrawcmd to pull this stuff off (and the disks are old so I'll need lots of retries) and then some more to format and write some new disks.
Ian
+-----------------------------------------------------------+ | David C Niemi (Reston, VA, USA) niemi at tuxers dot net | +-----------------------------------------------------------+
In article <Pine.LNX.4.64.1101131227510.29295@dholavira.tuxers.net>, David C Niemi wrote:
Back in the day 5.25" disks were sometimes (or usually) laid out with sectors out of order, because CPUs were really slow and couldn't read the sectors as they came by and fdcs did not have a buffer to hold the sectors until the host requested them.
Yes, I remember the days of interleaving and slewing.
So they would take 2 or 3 revolutions to read each side of the disk. Could it be you just start at 2 but there is a 1 later on?
No, sector 1 is deffo toast. A card called a "Catweasel" arrived at my house this AM and I can see the damage up close. Sector 1 is wreckage early on, and the IDAM headers suffer heavy damage, and even when they are there, the header CRC is often bad. Fortunately, the DAMs are mostly good, and I'm hoping the data CRCs are also good, so I should be able to pull the data from the raw track dump. Ian
Ian Oliver wrote:
Will fdrawcmd let me ignore CRCs and just got whatever is there?
Hmmm, some sniffing around suggests that these disks have a proprietary format.
What system were they from? That might be helpful to list readers (or yield someone with a working system that can read them "natively")
The first cylinder is normal, but after that, the next 21 cylinders don't even have a sector 0.
I seem to recall CP/M systems where the first cylinder was in a generic format (and contained driver code for a more complex floppy controller) with the remaining cylinders being in a 'better' format that the controller could still read) - I suspect that 'trick' was used by various systems outside of the CP/M world, too. Perhaps you're seeing something like that? Does looking at the physical data fetched from the first cylinder give any clues? Often (but by no means always!) the first cylinder data will contain useful data about the disk's layout and what's on it...
I suspect there are 14 sectors of non-standard sizes, so this is all going to be great fun.
Is there a chance that the disks are encrypted? I've seen that, too, with tweaks applied to sector headers - it can make reading on a 'alien' system rather interesting. (Sadly, I've also seen significantly-damaged disks throw up the kind of results you're seeing, with varying disk geometry, simply because the poor FDC's doing the best it can with mangled data) cheers Jules
In article <4D2F4E13.5050205@yahoo.co.uk>, Jules Richardson wrote:
What system were they from? That might be helpful to list readers (or yield someone with a working system that can read them "natively")
They were written on a PC, but people (including myself!) used larger than normal sectors (and mixed sector sizes) to get more data on a disk. However, I've now established that my disks are vanilla but in a sorry state. Ian
In article <VA.0000291d.0b45b9a8@foxhill.co.uk>, Ian Oliver wrote:
However, I've now established that my disks are vanilla but in a sorry state.
Yes, you beauty! I know it's no longer anything to do with this list, but I have my data. I used a card called a "Catweasel" to pull off the raw data and parsed the sectors out of the dumps with a few hundred lines of Python. Lots of sector headers were missing/bad, sector 1 of tracks 1 to 34 claimed to be one track further along than it actually was (and was hence rejected), and data crc errors abounded. After multiple passes with different mfm thresholds and postcompensation settings, and using some more Python to merge good sectors from multiple files, I got enough of the disk images 100% to get what I needed. I'll keep working on the other disks of the set, but this other stuff isn't as important to me. Thanks all for being a sounding board. Regards Ian
participants (4)
-
Alain Knaff -
David C Niemi -
Ian Oliver -
Jules Richardson