Make your own free website on Tripod.com

Save RAM to File in DOS DEBUG

Materials:
Working complete PC
Blank Diskette
Student Diskette, "New Boot A Ver 2.0+"
Student CD-ROM, "Room 6359"
Objectives:
The student will become familiar with how to use DOS DEBUG to:
load a raw sector into RAM,
display RAM contents on screen,
save the contents of RAM to a file,
restore the sector saved as a file to the disk.
Competency:
The student will how to use DEBUG's basic commands for the purposes of data recovery including how to load a raw sector into RAM, display its contents on screen, how to save the sector to a file and how to restore the sector from the file.

    Preparation

  1. In the first exercise, Basic DEBUG commands, the student learned how to clear the DEBUG RAM workspace by filling it with zeros, how to load a physical sector, specifically the floppy diskette's boot sector, into that RAM workspace, and how to display it on screen. Perform these operations first so that the workspace is cleared, the sector has been loaded into it and displayed on screen, then proceed with the following procedures to save the sector to a file and restore it to a damaged diskette.

  2. Procedures

  3. With the diskette's boot sector still in RAM from the preceding exercise, the following commands will instruct DEBUG to save the contents of the RAM workspace to a file. First, the number of bytes that DEBUG will save to the file are set by the value that SPANS the BX and CX registers of the CPU. These must always be checked and SET to the correct value to avoid potential disasters in which DEBUG would save the wrong number of bytes to the file. The command to VIEW and SET the value in a CPU register is the R command. The number of bytes that should be saved into the file is 512, the size of one sector. Since the value SPANS the two registers they must read:

    BX CX
    0000 0200

  4. Enter the command "r bx" to check the BX register's current contents and SET it to zero:

    -r bx
    BX 0000
    :0
    -_
    
  5. Even though DEBUG normally clears the registers as it starts up, it is a good practice to eliminate problems by checking and setting this register anyway. In future operations, we will modify its contents mandating the need to check it and set it anyway, so this is a good habit to get into from the start. Now set the CX register to 200 (remember that DEBUG ONLY USES HEXADECIMAL and NEVER uses decimal):

    -r cx
    CX 0000
    :200
    -_
    
  6. Now that the file size is correct, it can be named. DEBUG always defaults to saving the file in the current directory (a bit of a pain) meaning that DEBUG must be started while in the directory where the file needs to be saved. This is why the exercise was started while in the root of the K: RAM drive. Let's name the file "FLOPPY.DBR" using the N command:

    -n FLOPPY.DBR
    -_
          
    
  7. DEBUG now knows the name and the size of the file to be created. DEBUG will always default to saving RAM workspace data starting at offset 100 where the sector has been loaded into already. There the WRITE command can be executed with no further parameters and it will save the 512 bytes of RAM starting at offset 100 into a file named FLOPPY.DBR in the current directory. This is where the DOS Boot Record of the floppy currently resides:

    -w
    Writing 00200 bytes
    -_
    
  8. Now that the DBR has been saved to a file, let's damage the floppy by zeroing its DBR and then see if it can be restored from this file. First zero the RAM workspace from 100 to 2FF again:

    -f 100 2ff 0
    -_
    
  9. Now write this area of zeros to the first logical sector of the floppy drive B: using the WRITE command with the same parameters that the LOAD command uses: "W(rite from offset) 100 (to the drive numbered) 1 (at logical sector numbered) 0 (a total of) 1 (sectors)":

    -w 100 1 0 1
    -_
    
  10. This has completely destroyed the floppy's DBR by overwriting it with zeros. The DOS operating system kernel needs ths Drive Parameter Block within this sector to be able to find the File Allocation Tables, Root Directory, and the actual Data Clusters that hold each file's information. Without the DPB within the DBR, DOS will refuse to read the floppy. However, for the sake of efficiency DOS always caches this information into RAM so that it does not have to read it every single time the floppy is accessed. Even removing the floppy and then reinserting it will not be sufficient to force DOS to clear this cached information because the industry did not standardize the function fo the disk drive "changeline" signal on pin #34 of the floppy data ribbon cable. Because some drives supported it and some did not, DOS could never rely on this information which is one reason why it DOES depend on the DPB to determine if a floppy has been changed instead of the hardware signal. Therefore, remove the floppy, quit DEBUG and attempt to read the floppy with several retries, thereby convincing DOS to clear the floppy data cache:

    -q
    K:\>dir b:
    Not ready reading drive B
    Abort, Retry, Fail?r
    Not ready reading drive B
    Abort, Retry, Fail?r
    Not ready reading drive B
    Abort, Retry, Fail?r
    Not ready reading drive B
    Abort, Retry, Fail?_
    
  11. Now that the floppy data cache is clear, reinsert the damaged floppy and press "r" for retry again. This time the error is different. DOS knows that there is a diskette in the drive, but without the DPB within the DBR, is indicates that it cannot NAVIGATE the file system structures of the floppy:

    (Reinserted the floppy at this point)
    Not ready reading drive B
    Abort, Retry, Fail?r
    General failure reading drive B
    Abort, Retry, Fail?a
    K:\>_
    
  12. So the "General failure..." message means that the DBR has been damaged. But the rest of the floppy is completely intact. If it could be replaced, then perhaps the data on the floppy could be recovered? Yes, and as it turns out, ALL 1.44MB 3 1/2" floppies have identical Drive Parameter Block layouts, the only things that might be different are the file system driver signature (DOS doesn't care), the volume label (non critical) and the volume serial number (noncritical, although WINNT family will scream if it changes WHILE it is being accessed.) This means that the DBR saved earlier as a file can be used to attempt this repair on ANY and ALL 1.44MB 3 1/2" floppy diskettes. First, run DEBUG and tell it at the command line to bring the file containing the floppy DBR with it:

    K:\>debug floppy.dbr
    -_
    
  13. The file is already loaded into the DEBUG RAM workspace at offset 100 by specifying it at the commandline. This is by FAR the easiest way to accomplish this. Now attempt the "raw WRITE" command to write the contents to logical sector number zero on the floppy:

    -w 100 1 0 1
    General failure reading drive B
    Abort, Retry, Fail?a
    -_
    
  14. Plainly the DEBUG WRITE and LOAD commands depend on the operating system drivers being able to read and write to the drive, which with the DBR destroyed is not possible. So then how can the sector be restored? By asking BIOS to write the information to the raw physical sector of the drive. This will require a small machine language program. It is far easier to remember the commands in assembly language than in hexadeciaml, so start the assembly language processor at offset 300h (above the physical sector data so it won't overwritten) with the "a 300" command":

    -a 300
    242C:0300 _
    
  15. At this point the assembly language processor is awaiting assembly language program lines to be entered, it will convert them automatically into raw hexadecimal machine language. Follow the entries EXACTLY as shown below:

    242C:0300 mov ax, 301
    242C:0303 mov bx, 100
    242C:0306 mov cx, 1
    242C:0309 mov dx, 1
    242C:030C int 13
    242C:030E int 3
    242C:030F _
    
  16. That has the complete program needed to write the 512 bytes at offset 100 (the DBR loaded up from the file) into the first physical sector of the B: drive. Now press [Enter] on a blank line of the assembly language processor to exit it back to the dash prompt:

    242C:0300 int 3
    242C:0300 (press the [Enter] key here)
    -_
    
  17. Now the program can be executed with the GO command. The GO command defaults to starting at offset 100 which holds the floppy DBR, if this is done the machine will lock up (not good) forcing you to reboot and lose all of this work. override the default like this: "g=300" meaning GO starting at offset 300. The last instruction in the program "int 3" is the instruction that will return control of the CPU to DEBUG itself. Also very important or the machine will lock up again forcing a reboot and loss of all this work:

    -g=300
    AX=0001  BX=0100  CX=0001  DX=0001  SP=FFEE  BP=0000  SI=0000  DI=0000  
    DS=242C  ES=242C  SS=242C  CS=242C  IP=030E   NV UP EI PL ZR NA PE CY 
    242C:030E CC            INT	3                                  
    -_
    
  18. Note that the BIOS call is very low level. If the diskette has not been clamped by the drive mechanics, then the write will fail. This happened in this case and is indicated by the CARRY flag highlighted here:

    -g=300
    AX=0001  BX=0100  CX=0001  DX=0001  SP=FFEE  BP=0000  SI=0000  DI=0000  
    DS=242C  ES=242C  SS=242C  CS=242C  IP=030E   NV UP EI PL ZR NA PE CY
    242C:030E CC            INT	3                                  
    -_
    
  19. Because the raw sector write failed it must be attempted again. So run the program with the "g=300" command again. This time it succeeds and the ONLY WAY you will know this is because the CARRY FLAG now indicates "NC" for "No Carry":

    -g=300
    AX=0001  BX=0100  CX=0001  DX=0001  SP=FFEE  BP=0000  SI=0000  DI=0000  
    DS=242C  ES=242C  SS=242C  CS=242C  IP=030E   NV UP EI PL ZR NA PE NC
    242C:030E CC            INT	3                                  
    -_
    
  20. Now quit DEBUG and try to read the floppy from the command prompt:

    -q
    K:\>dir b:
     Volume in drive B has no label
     Volume Serial Number is 1758-18E4
     Directory of B:\
    COMMAND  COM        93,890  04-23-99 10:22p
             1 file(s)         93,890 bytes
             0 dir(s)       1,140,224 bytes free
    K:\>_
    
  21. The diskette and all information on it are now fully accessible once again because a good DBR has been written to the first physical sector address. Now this is a tedious task to perform any time a "general failure reading drive X" occurs. And most of the time it will occur to drive A and not B which is only happening because of the boot up from the bootable CD-ROM in the class room. Let's build a reusable batch file that can perform this operation for any floppy at any time whether it is drive A or B. First open EDIT naming the new file RESTOREFL.BAT:

    K:\>edit restorefl.bat
    
  22. With the full DOS text editor open, type in the following instructions (they can be cut and pasted into notepad and then saved as RESTOREFL.BAT also):

    @echo off
    if %1z==z goto synterr
    echo a 300 >> tmp.dbg
    echo mov ax, 301 >> tmp.dbg
    echo mov bx, 100 >> tmp.dbg
    echo mov cx, 1 >> tmp.dbg
    echo mov dx, %1 >> tmp.dbg
    echo int 13 >> tmp.dbg
    echo int 3 >> tmp.dbg
    echo. >> tmp.dbg
    echo g=300 >> tmp.dbg
    echo q >> tmp.dbg
    debug floppy.dbr < tmp.dbg
    del tmp.dbg
    echo Done.
    goto end
    :synterr
    echo SYNTAX:
    echo.
    echo RESTOREFL number
    echo where number is 0 for the A: drive and 1 for the B: drive.
    :end
    
  23. Now save this to the file by pressing [Alt]+[F] then [S], then exit EDIT by pressing [Alt]+[F], then [X]. Now run RESTOREFL and it should indicate how to use it:

    K:\>restorefl
    SYNTAX:
    RESTOREFL number
    where number is 0 for the A: drive and 1 for the B: drive.
    K:\>_
    
  24. Now open DEBUG and insert a diskette in the B: drive and run the following commands to destroy the DBR and quit back to the prompt:

    K:\>debug
    -f 100 2ff 0
    -w 100 1 0 1
    -q
    K:\>_
    
  25. Remove the diskette and atteempt a "dir b:" and retry a few times, then reinsert the floppy and retry again so that the "general failure" error is displayed. Now abort and run "restorefl 1":

    K:\>restorefl 1
    -a 300
    242C:0300 mov ax, 301
    242C:0303 mov bx, 100
    242C:0306 mov cx, 1
    242C:0309 mov dx, 1
    242C:030C int 13
    242C:030E int 3
    242C:030F 
    -g=300
    AX=0001  BX=0100  CX=0001  DX=0001  SP=FFEE  BP=0000  SI=0000  DI=0000  
    DS=242C  ES=242C  SS=242C  CS=242C  IP=030E   NV UP EI PL ZR NA PE NC 
    242C:030E CC            INT	3                                  
    -q
    K:\>_
    
  26. Manually observe that the CARRY flag indicates "NC" If so then the restore was successful, if not simply run the batch file again. In this case it indicates that it succeeded. Running "dir b:" it will display the root of the floppy, so the batch file worked at restoring the DBR to it. Save the files FLOPPY.DBR, and RESTOREFL.BAT to a floppy and copy them to a RAM drive or hard drive and run the batch file whenever this repair needs to be made to a floppy.

  27. In the next exercise, the root directory of the floppy will be located using the DEBUG SEARCH command and a formula for converting DEBUG RAM offsets to logical sector offsets on the diskette itself will be developed.

Back to Page Top

Copyrightę2000-2006 Brian Robinson ALL RIGHTS RESERVED