★ APPLICATIONS ★ DISQUE ★ DU-V87.COM|8000PLUS) ★ |
| DU-v87.COM | Applications Disque |
I decided to write about DU-V87.COM when in the throes of retrieving 350k of ASCII text files from a disc. I had wiped the directory off by running DISCKIT over the first two tracks before I realised I had the wrong disc! Flicking open the drive door I managed to save the actual files. But where were they on the disc? Without the directory the CP/M cannot work out where it has saved them. If you begin with a blank formatted disc CP/M will save the first file on the first available space in blocks of data one after another. The disc operating system sticks a second file on after the first. So it would seem a doddle to retrieve the files. But life is not that kind. When you erase a file you don't actually erase the file (confused?) All you do is change one character in front of the filename in the directory. This character states which user area (or Locoscript group ) the file is stored in. If it is a hexadecimal byte from 0 to 0F it means the user area. 20 means a disc label, and 'E5' means the file's erased. Group names are filenames with blank files. An erased file stays there until you save other files. If there is no room at the end of the last file it looks for holes1 left when you erased a file. The disc operating system re-uses this space to store bits of the new one. As each block is saved CP/M goes to the directory and fills in the location after the filename. When it closes the file it drops a byte into the directory to say how big the file is. Next time you save a file to disc and the disc is nearly full listen to the head inside the disc drive going back and forth from the outside of the disc where the directory is to the inside where the last spaces are. Once you have used a disc for a while, saving and erasing files, it will be in a right mess and without a look up table along with each filename CP/M would also be confused. Having wiped off the directory, you can understand why a grown man was almost driven to tears. DU want help? With DU I set to work. First of all CP/M discs formatted by DISCKIT follow closely the standard laid down by IBM. One of these standards is that the first 16 characters (or bytes) of the first track and sector have details of what kind of disc it is - 40 or 80 track per side? Single or double sided? How many sectors per track? This had been removed so if I tried to use the disc it would result in some nasty noises as the head motor tried to access the disc with an incorrect format. Disckit fills up the whole disc with the Hexadecimal byte value of *E5 thus the poor old operating system would have looked at the disc information and deduced that it must be a disc with 229 tracks, 229 tracks per side, with 229 sectors per track! There is a user's manual with the program and online help. If you want to investigate how discs are laid out format a disc that you don't mind messing up and play with that. When you know how to drive around the program you can start to attack those damaged discs. The first thing was to write in the data that used to be there. I inserted a disc with the same format into the B-drive and ran up DU-V87, logged on to the B-drive and asked the program to go to track 0 sector 1. Swapping discs I wrote that first sector on the damaged disc so it wouldn't throw a fit if I tried to look at the disc with any CP/M programs. Where did I put them? Now to find what the operating system had done with my files. Using the view command I could speed through the erased system tracks until I reached the first undamaged sector, I recognised the first few words of a file I had recently typed so I could 'yank' the block into memory. Looking at the last few words of that first block I was able to deduce easily enough what came next as the start of the next, second, block. Now was the time for DU to do the hard work and find what CP/M had done with it. This I did using a command to search for an ASCII string. Having found the next block, I 'yanked' that into the memory buffer This was repeated for each block until I came across the end of the file - the view command always stops at the end of a file. Inspecting the final sector more closely you can usually see the dozens of marker bytes 'IA'. Quite often you get a file intact , or at least a sizeable chunk of it, so it is a lot easier than it sounds. That was one file done. All I had to do now was find the other dozen or so. On and off it took me a couple of days - but it's got to be better than starting all over again.
|
