Caluser2000
Banned
Ghost was originally develpoed here in little ol Nooo Zealand before Norton aquired it....
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
FreeDOS or MS-DOS Low Level Disk Access (byte/block)
- Thread starter rlerner
- Start date
Chuck(G)
25k Member
I recall learning of it considerably before 1997.
Caluser2000
Banned
rlerner
Member
Well, Caluser2000, there's no way that's correct because everybody knows Wikipedia is always current and correct!
Lol... Alright, going to find a copy of the DOS based one, I wanted to make my own but it may just be easier to do it this way. Thanks!
Lol... Alright, going to find a copy of the DOS based one, I wanted to make my own but it may just be easier to do it this way. Thanks!
Caluser2000
Banned
No problem 
If that drive supported ATA-6, then it supported all of the previous versions of ATA as well. So I suspect the drive came with a controller card because the controller was needed to support accessing all of the drive via 48 bit LBA support, which was something an existing BIOS might not support. ATA-6 also had a faster UDMA speed, but it was something like UDMA 100 vs UDMA 133.
I think it's more technically correct to say the BIOS didn't support seeing the whole drive, not that the drive was not supported by the BIOS.
Chuck(G)
25k Member
Perhaps, but the effect is the same--you don't get everything.
I've been playing with using an MCU to suck data off of PATA drives and stash it on a SD card. No fooling with operating systems, etc. Just plug the drive in and go.
Hi,
Unfortunately, this call only works for small drives (32 MB). Beyond that, the BIOS interrupt 0x13 it is.
Since I prefer working in Linux, I had used bcc (Bruce's C compiler), which is available in both Debian and Ubuntu and very easy to get started with. It because it behaves like a UNIX compiler ("bcc -ansi -Md -o main.com main.c"), but is very traditional and only does small-mode. See the attached file for how to do inline assembly; I never used the int86() and int86x() functions.
Otherwise... find existing software to do what you want.
I have written a small program which writes floppy disk images exclusively using DOS interrupt 0x26.
Unfortunately, this call only works for small drives (32 MB). Beyond that, the BIOS interrupt 0x13 it is.
Since I prefer working in Linux, I had used bcc (Bruce's C compiler), which is available in both Debian and Ubuntu and very easy to get started with. It because it behaves like a UNIX compiler ("bcc -ansi -Md -o main.com main.c"), but is very traditional and only does small-mode. See the attached file for how to do inline assembly; I never used the int86() and int86x() functions.
No. You cannot access the whole drive like a virtual file as you can on NT or UNIX, and the interfaces available are quite limited and inconsistent (depending on when they were designed and which constraints were relevant).
Otherwise... find existing software to do what you want.
rlerner
Member
That seems pretty straight forward, but I think my dreams of throwing something together to have "full control" of what I'm pulling off are fading. I know these disks are full of bad sectors and problems so I was hoping to write it where it'll retry a few times, create a separate file denoting what sectors are bad (or simply not creating anything in my file) and keep chugging along. Then allow me to try and re-image later and fill in anything that passes the CRC.
At this rate it might be down to just getting a DOS copy of Ghost and seeing if that supports it. 386 should be here super early -- tomorrow even.
At this rate it might be down to just getting a DOS copy of Ghost and seeing if that supports it. 386 should be here super early -- tomorrow even.
You definitely want to use a somewhat more modern system, Linux and dd_rescue (not plain dd).
That program has been designed to extract the absolute maximum possible off a failing hard drive. It will outperform whatever you can cobble together yourself, and it will likely do a lot better than any contemporary / DOS software you can find.
rlerner
Member
I don't doubt that at all, but the problem I'm having is lack of support for older disks. I have a machine that has IDE but it won't see all the disks. I suspect it's due to the type of disk (CHS vs LBA), but who knows, it could be that they're toast.
I'm not sure of a reasonable Linux distro that might have dd or dd_rescue that will run on a 80386/20, but if you are I'd be happy to locate a copy of it and try it out!
Chuck(G)
25k Member
Since dd has been part of Unix and its derivatives, I suspect that an old Linux/BSD version that runs on that 386/20 would be pretty simple to find. I'd start with the old Slackware distros, or perhaps old 386BSD ones.
And there is an alternate way (from Int 25h) to read a volume. It's generic IOCTL call 440dh. Older drivers may not implement it, but it's been around since DOS 3.2. For the call details, see Ralf Brown's description here.
SCSI drives (particularly removable ones) that use an after-boot (e.g. ASPIDisk) driver aren't usually accessible via BIOS calls. However, the generic IOCTL block request should handle them.
And there is an alternate way (from Int 25h) to read a volume. It's generic IOCTL call 440dh. Older drivers may not implement it, but it's been around since DOS 3.2. For the call details, see Ralf Brown's description here.
SCSI drives (particularly removable ones) that use an after-boot (e.g. ASPIDisk) driver aren't usually accessible via BIOS calls. However, the generic IOCTL block request should handle them.
rlerner
Member
I'll look around through this and see what I can make, I'll also look into these Linux distros. I started Linux more or less late to the game with like Ubuntu 7.04 iirc, but I'm comfortable enough in the command line and if I bork a disk it'll suck but won't be devastating.
I assume these sorts of calls are how MS-DOS would allow a program like defrag and scandisk to operate? Sadly the leaked v6 source I have found doesn't contain either of those programs to know for sure.
I assume these sorts of calls are how MS-DOS would allow a program like defrag and scandisk to operate? Sadly the leaked v6 source I have found doesn't contain either of those programs to know for sure.
Caluser2000
Banned
Try BasicLinux https://distro.ibiblio.org/baslinux/
JohnElliott
Veteran Member
Note that ddrescue and dd_rescue both exist. Of the two, I've only used ddrescue so can't say how they compare, but it seemed to do a good job with the failing hard drives I unleashed it on.
Native IDE interfaces generally support CHS without issues (Linux definitely does), but even if it is not supported (e.g. through USB interfaces), you should be able to at least detect the drive and show name and serial number.
ddrescue is open source: https://www.gnu.org/software/ddrescue/
I definitely do not recommend using the 386/20 for any data recovery operations, but if that's the way you want to roll, then you can try compiling it on that machine. The Linux kernel dropped support for 386-class CPUs in version 3.8 (2012), but many distributions stopped supporting it far earlier. Slackware 8.x and earlier should have support, but it is likely untested.
Oh, and you definitely want as much RAM and (fast) disk space on your 386 for Linux to do anything useful.
My target system (the Philips :YES) only runs MS-DOS 3.10 or DOS Plus.
But thanks for the information, I was not aware of this.
I might have mixed them up. It might actually have been ddrescue what I have been using, but it was a long time ago.
You can use MHDD if you want just a full dump of the drive,
hddguru.com
there's a command that copy a range of sectors (or the whole
drive to a file)
Even DMDE can make a dump of a drive, and there's a DOS version.
For older drive I would use an old version of MHDD or DMDE.
I used MHDD 2.9 to make backup image of lot of small drives.
I don't think it works with MFM though.
Must have GHOST 2.0 somewhere ...
HDDGURU: MHDD
MHDD is the most popular freeware program for low-level IDE, Serial ATA and SCSI HDD diagnostics.
there's a command that copy a range of sectors (or the whole
drive to a file)
Hddguru.com - your source of information about Hard Drives
Hddguru.com - your source of information about Hard Drives
hddguru.com
Even DMDE can make a dump of a drive, and there's a DOS version.
About DMDE (DM Disk Editor and Data Recovery Software)
DMDE, Data Recovery Software, About DMDE, DM Disk Editor and Data recovery
dmde.com
For older drive I would use an old version of MHDD or DMDE.
I used MHDD 2.9 to make backup image of lot of small drives.
I don't think it works with MFM though.
Must have GHOST 2.0 somewhere ...
rlerner
Member
I really appreciate all the links everybody is sharing! SD to IDE thing just got delayed so I hope it's here on time for the 386.
For GHOST 2.0, I only found 6.0 in German on Archive.org -- and I don't speak German so I'd wreck something with that.
I'm betting y'all are right about the 386 not being ideal for this activity. I might just clean it up and fix it and resell it, most of what I'd really like to do retro would be a 486 anyways for the most part. At least it'll give me a chance to throw the suspect drives that my current machine refuses to see into something else to verify.
For GHOST 2.0, I only found 6.0 in German on Archive.org -- and I don't speak German so I'd wreck something with that.
I'm betting y'all are right about the 386 not being ideal for this activity. I might just clean it up and fix it and resell it, most of what I'd really like to do retro would be a 486 anyways for the most part. At least it'll give me a chance to throw the suspect drives that my current machine refuses to see into something else to verify.
modem7
10k Member
I would be cautious about using Ghost on a 'suspect' drive. For example, in 2007, I copied from http://www.bug-killer.com/comp_basics1.html
"USING GHOST FOR FORENSICS IS A BAD IDEA
Often system administrators will suggest using Symantec's Ghost program to copy a critical hard disk. Don't do it!
Unless configured exactly, Ghost will write onto the drive being copied. This seriously corrupts evidence on the original hard drive. It can be a big setback in any criminal or civil proceeding.
When we testified in the murder trial of Robert Durall it was necessary to explain to the jury why 9000 files on a critical hard drive were altered by a well meaning technician using Ghost."
That sounds to me like the version of Ghost used discovered something amiss with the directory/file structure, and then attempted to do a fix.
I used Ghost (DOS versions) for many years, but only on drives that had no integrity issues (at hardware level nor at file system level).
Fingerprint
Ghost (what versions?) is known to write a 'fingerprint' onto the drive. I remember that years ago, I went looking for it, and I recall that (in the version I used) it was put somewhere in the first few sectors. There's some discussion about the fingerprint at [here], and in the -FINGER switch at [here].
'Forensic'
By default, Ghost works at the file system level.
Getting Ghost to instead do a sector-by-sector copy is discussed at [here], which applies to certain versions. -ID and -IR switches.
"USING GHOST FOR FORENSICS IS A BAD IDEA
Often system administrators will suggest using Symantec's Ghost program to copy a critical hard disk. Don't do it!
Unless configured exactly, Ghost will write onto the drive being copied. This seriously corrupts evidence on the original hard drive. It can be a big setback in any criminal or civil proceeding.
When we testified in the murder trial of Robert Durall it was necessary to explain to the jury why 9000 files on a critical hard drive were altered by a well meaning technician using Ghost."
That sounds to me like the version of Ghost used discovered something amiss with the directory/file structure, and then attempted to do a fix.
I used Ghost (DOS versions) for many years, but only on drives that had no integrity issues (at hardware level nor at file system level).
Fingerprint
Ghost (what versions?) is known to write a 'fingerprint' onto the drive. I remember that years ago, I went looking for it, and I recall that (in the version I used) it was put somewhere in the first few sectors. There's some discussion about the fingerprint at [here], and in the -FINGER switch at [here].
'Forensic'
By default, Ghost works at the file system level.
Getting Ghost to instead do a sector-by-sector copy is discussed at [here], which applies to certain versions. -ID and -IR switches.
Caluser2000
Banned
iirc correctly DR Dos 6s xcopy command will image hdds to a file....
OS/2s xcopy /h/o/t/s/e/r/v command may as well.
OS/2s xcopy /h/o/t/s/e/r/v command may as well.
Last edited: