FreeDOS or MS-DOS Low Level Disk Access (byte/block)

[Caluser2000]

Ghost was originally develpoed here in little ol Nooo Zealand before Norton aquired it....

 

[Chuck(G)]

I recall learning of it considerably before 1997.

 

[Caluser2000]

Ghost history https://softpanorama.org/Windows/Ghosting/ghost_history.shtml

 

[rlerner]

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!

 

[Caluser2000]

No problem

 

[mbbrutman]

It does indeed matter. Consider my first experience with a 160GB drive on a P1 system. Not supported by BIOS (requires the ATA-6 extensions). Yet Windows NT 4.0 had no problem with it. It was enough of a problem for Maxtor to package a Promise controller with the drive in the retail package

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)]

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.

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.

 

[Svenska]

Hi,

I'm a certified DOS batch file programmer and I used to build stuff in QBASIC. I have some C experience but most of that is on modern Linux.

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.

Is there a way using fopen or similar that I can use to access these low-level bytes of a disk for read and/or write?

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]

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.

 

[Svenska]

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.

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]

You definitely want to use a somewhat more modern system, Linux and dd_rescue (not plain dd).

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)]

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.

 

[rlerner]

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.

 

[Caluser2000]

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.

Try BasicLinux https://distro.ibiblio.org/baslinux/

 

[JohnElliott]

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.

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.

 

[Svenska]

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.

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.

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!

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.

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.

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.

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.

I might have mixed them up. It might actually have been ddrescue what I have been using, but it was a long time ago.

 

[noppa]

You can use MHDD if you want just a full dump of the drive,

HDDGURU: MHDD

MHDD is the most popular freeware program for low-level IDE, Serial ATA and SCSI HDD diagnostics.

hddguru.com

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]

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.

 

[modem7]

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.

 

[Caluser2000]

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.