stamasd wrote:

Or else, again, consider SCSI.

Yes, that's an option, but even though I have the necessary hardware laying around, I don't have any SCSI disk with an OS on it that I can use to boot.

Pre-1990 PCs are difficult... 🤣

I don't think the floppy disks are an issue. All of the code that you would need would fit on a 160KB diskette. You just need to be able to boot DOS, load a packet driver, possibly run DHCP, and then run the file transfer program.

The Xircom PE3-10BT connects to almost any parallel port and to modern switches using RJ-45 connectors. It's not going to be a speed demon, but at 30KB a second on the slowest machine possible you would still be able to transfer the contents of a 20MB hard drive in just over 11 minutes.

Details on the Xircom can be found here: http://www.brutman.com/Dos_Networking/xircom_pe3.html

devius wrote:

stamasd wrote:

Or else, again, consider SCSI.

Yes, that's an option, but even though I have the necessary hardware laying around, I don't have any SCSI disk with an OS on it that I can use to boot.

Pre-1990 PCs are difficult... 🤣

Boot from a floppy with SCSI driver. Could even be a Linux floppy, Slackware 8.0-8.1 has sets of disks with pretty much any old storage drivers you want including SCSI, IDE, MFM etc. Then it's a matter of using dd judiciously.

Bootdisks: http://ftp.slackware.com/pub/slackware/slackw … -8.1/bootdisks/
Rootdisks: http://ftp.slackware.com/pub/slackware/slackw … -8.1/rootdisks/
(the only Portugal mirror doesn't have files for the old 8.1)

devius wrote:

Thanks everybody for the suggestions, but I really want to make a disk image, not copy the files. Maybe I can make this run in some kind of emulator or VM in the future.

Ah ok, I see. You can also use a remote drive to store your backup file.
It's one of the most reliable methods without worrying about a hardware damage, I think.
If you have two old PCs with parallel ports, then just use a Laplink cable.
But make sure both are using the same mode! old XT style PCs don't support ECP, EPP or EPT mode (aka PS/2 or Byte-Mode).
They are more likely to use the classic SPP "Nibble"-Mode (4bit; uses the status lines for reading data).
Anyway, I'm not sure whether Laplink from DOS 6.x will run on DOS 3.30. Maybe it requires a newer version of DOS.
(-You could use a bootable DOS 6.22 floppy if the program is small enough.)

In this doesn't work, you could also try to use a serial connection. You can even use an USB-Serial dapter for this purpose.
These old UARTs are smart enough to understand 3.3v signals transmitted by those cheap converters.
And last, but not least, the serial connection is much less sensitive against short circuits.
The serial port has built-in diodes which protects it against surge, short circuits and over voltage.
According to the old V.24/V.28 specs, voltage for a data line without any load can be as high as 25 volts.
Of course, this isn't really important here. I just mentioned it to give an idea, how durable that port is.
On a PC we normally never exceed ±12V DC (max. ± 15V DC).

If you're looking for software, try one of those. They may not be the best, but they are from about the right time frame.
So they are likely to run properly on DOS 3.x.

..

Another idea is to clone the drive to a small 32MB compact flash card using the aforementioned CF card readers.
Then you could do a backup of the card using Win32DiskImager, for example. AFAIK, it creates VM compatible image files.

Edit: I totally forgot that you still need a backup program for that Olivetti. 😅
Maybe I can help you with this - I've seen an image software for DOS a while ago. It's called Partition-Saving.
You can find it on http://damien.guibouret.free.fr/en/index.html .

Here 's what the developer says :

What Partition-Saving is?

Partition-Saving is a DOS, Windows and Linux program that is used to save, restore and copy hard-drive, partitions,
floppy disk and DOS, Windows or Linux devices.

With this program you could save all data on a partition to a file (such as you could save this file on a CD for example).
Then if something goes wrong, you can completely restore the partition from the backup file. You no longer have to reinstall every piece of software from scratch.
All you have to do is restore the partition from the backup file and then update any software that was modified since the backup was created.

A parallel port Zip100 drive using the Palmzip driver from http://leute.server.de/peichl/palmzipe.htm would work on your computer, no?

lolo799 wrote:

A parallel port Zip100 drive using the Palmzip driver from http://leute.server.de/peichl/palmzipe.htm would work on your computer, no?

Seems about right! With that out of the way I would only need an imaging program for DOS 3.3, or alternatively one that fits in a 720K floppy that I can make bootable. Not sure if the floppy controller on the Olivetti would accept a 1.44MB drive, but if it would then that's one limitation less. I would prefer a program that creates a raw image that doesn't require any proprietary programs to read back.

BTW, here's the latest progress I made in the mean time:

1) Tried the 8-bit controller + HDD in a Socket 7 motherboard (SiS 5598 chipset) but it wouldn't work. This motherboard allowed me to select the disk type in the BIOS setup program, unlike the Compaq, but even after selecting the right drive type (either 2 or 6, I tried both, and also User with the correct drive parameters) the disk was not recognized or accessible.

2) I then disabled the motherboard's secondary IDE channel, and set the 8-bit controller to secondary controller. Still no luck.

3) Finally I completely disabled the motherboard's IDE controller, while trying the 8-bit controller configured as either primary or secondary controller, but even with the correct drive type correctly set in the BIOS the disk still wasn't recognized.

4) I also tried the 8-bit controller set to PC/AT mode instead of the default PC/XT, but it also didn't make any difference.

So, it seems to me that these newer BIOSes only understand IDE, and not these older ST-506 interfaces. No idea why they bothered to include the ability to set the drive type to these older drives when the boards don't actually support them.

At this point, I think the only option for making it work on a non-XT compatible motherboard is to use a board that doesn't have any built-in IDE controller, which means a 486 era board at most, and only ISA or VLB at that, since PCI ones already have built-in IDE controllers.

The problem is that modenr BIOSes don't know about MFM HDDs. If your HDD controller has its own BIOS (does it have any ROM chip onboard?), it may be possible make it work on a modern PC. In that case, the safe way would be treat it like a SCSI card (make your motherboard boot from SCSI) so your MFM disk is the first to boot.

If you're unable to make that disk work on a newer PC, put everything back on the Olivetti and check if it runs OK.

Next problem would be making an image. If a newer PC can boot from your MFM disk (and detect IDE disks), I guess you could use any DOS imaging software (i.e.: older versions of ghost) and convert it later to another format. In the worst case, if should be easy to make a "dump" program that read every sector on the disk and then write it on another disk.

And the last problem (if you're working on your Olivetti) is how to extract that file from the XT. I guess you could use zip drives, XT-IDE, XT-CF or SCSI cards.

As I said before, I'd try to make a backup of the files using serial link (and a boot disk). It is cheap and slow, but you can later "restore" that files directly onto a virtual machine.

Zup wrote:

The problem is that modenr BIOSes don't know about MFM HDDs.

If you can enter the drive geometry (CHS) manually, then any BIOS that works with IDE will work with MFM/RLL, as long as the controller card is at 1F0h/3F0h where the BIOS expects to find it.

SquallStrife wrote:

If you can enter the drive geometry (CHS) manually, then any BIOS that works with IDE will work with MFM/RLL, as long as the controller card is at 1F0h/3F0h where the BIOS expects to find it.

Is that the I/O address? Because the only options on this controller card are 320h and 324h. It's currently set to 320h which is the default, and even with the drive geometry manually entered it still wouldn't work.

devius wrote:

So, it seems to me that these newer BIOSes only understand IDE, and not these older ST-506 interfaces. No idea why they bothered to include the ability to set the drive type to these older drives when the boards don't actually support them.

At this point, I think the only option for making it work on a non-XT compatible motherboard is to use a board that doesn't have any built-in IDE controller, which means a 486 era board at most, and only ISA or VLB at that, since PCI ones already have built-in IDE controllers.

MFM/RLL, ST506, ESDI, IDE or SCSI.. All this shouldn't really matter.
Afaik, AT sytle BIOSes do use any interface with an WD1003 compatible command set. These interfaces just have to be located at the right spot.
Just try yourself and put in an ISA Multi-I/O card, an AT-BUS HDD controller card or an WD1002 controller.
The system will accept them, aslong as there's no resource problem (make sure the corresponding on-board devices are disabled).

And in your case, it could also help to make sure the BIOS is configured to allow INT $19 for Option ROMs.
Not sure if this will solve all of your issues, but it's a start. You will still have to find out how to transfer your data.

I succeeded doing this many years ago. I took the Seagate MFM controller and hard drive from the old IBM PC/XT and put them in the new Pentium (it was new back then.) The controller was not recognized be the BIOS on the Pentium and the drive did not show up in DOS. So I installed Slackware Linux on the new computer and compiled a kernel with the mfm/xt disk drivers.

I found this guide that might help you if you want to try imaging the drive using Linux. And there are three different drivers you can use depending on what kernel version you are using and what type of controller you have. You may need to know your controller's type, IO base, IRQ, DMA channel, and the hard drive's geometry.

http://www.tldp.org/HOWTO/BootPrompt-HOWTO-7.html

Boot it up using a kernel the proper command line option. Or if you are using kernel modules, insmod/modprobe the driver with the options. If you succeed, use the "dd" command to make the image.

FuzzyLogic wrote:

I succeeded doing this many years ago. I took the Seagate MFM controller and hard drive from the old IBM PC/XT and put them in the new Pentium (it was new back then.) The controller was not recognized be the BIOS on the Pentium and the drive did not show up in DOS.

That is exactly what I'm getting, but I'm encouraged to find out that you succeeded in the end 😀

FuzzyLogic wrote:

So I installed Slackware Linux on the new computer and compiled a kernel with the mfm/xt disk drivers.

It's possible that the kernel that comes with Fedora 8 doesn't have those drivers enabled then. Or it does, but I haven't figured out how to load them yet, since apparently it's not automatic.

FuzzyLogic wrote:

I found this guide that might help you if you want to try imaging the drive using Linux.

Tried that, but it also didn't work. Nothing different happened after I added this to the kernel boot parameters:

1hd=615,4,17

FuzzyLogic wrote:

Or if you are using kernel modules, insmod/modprobe the driver with the options. If you succeed, use the "dd" command to make the image.

That was my original plan, but I couldn't figure out which driver is the correct one. Do you have any idea? Maybe I should try the other boot options, since I only tried the one I mentioned above, because at the time I didn't know what brand the controller card was. Maybe I can use the XT Disk Driver options. I'll give it a try when I have the time and report back.

devius wrote:

It's possible that the kernel that comes with Fedora 8 doesn't have those drivers enabled then. Or it does, but I haven't figure […]
Show full quote

It's possible that the kernel that comes with Fedora 8 doesn't have those drivers enabled then. Or it does, but I haven't figured out how to load them yet, since apparently it's not automatic.

FuzzyLogic wrote:

I found this guide that might help you if you want to try imaging the drive using Linux.

Tried that, but it also didn't work. Nothing different happened after I added this to the kernel boot parameters:

Copy code to clipboard

1hd=615,4,17

FuzzyLogic wrote:

Or if you are using kernel modules, insmod/modprobe the driver with the options. If you succeed, use the "dd" command to make the image.

That was my original plan, but I couldn't figure out which driver is the correct one. Do you have any idea? Maybe I should try the other boot options, since I only tried the one I mentioned above, because at the time I didn't know what brand the controller card was. Maybe I can use the XT Disk Driver options. I'll give it a try when I have the time and report back.

I'm guessing that the kernel in Fedora 8 does not have the drivers for MFM controllers built in. I haven't used Redhat or Fedora in ages, but back then their kernels were bare and all drivers were stuffed in the initrd.gz as modules. So using kernel command line options is useless.

I would first figure out exactly what type of controller you have, then decide which module to load. Type "modinfo xd" in Fedora 8 to see if you even have the old xd.o driver. The "hd" driver cannot be built as module (but I could be wrong.) Try "modinfo hd" to find out. The "hd" driver is the one you use if you have an ST-506 controller. Check your /proc/config.gz or /boot/config to see what is available in your fedora kernel.

There is some valuable info in the kernel source as well:

1                 * We don't know anything about the drive.  This means
2                 * that you *MUST* specify the drive parameters to the
3                 * kernel yourself.
4                 *
5                 * If we were on an i386, we used to read this info from
6                 * the BIOS or CMOS.  This doesn't work all that well,
7                 * since this assumes that this is a primary or secondary
8                 * drive, and if we're using this legacy driver, it's
9                 * probably an auxiliary controller added to recover
10                 * legacy data off an ST-506 drive.  Either way, it's
11                 * definitely safest to have the user explicitly specify
12                 * the information.
13                 */
14                printk("hd: no drives specified - use hd=cyl,head,sectors"
15                        " on kernel command line\n");

If I were doing this again, I would probably download Slackware 3.3, which is still available, and install that into an SCSI drive (not ide.) Also, I would compile my own kernel and modules so I know the drivers I need are available.

I wish I had some MFM drives and controllers to try this out.

FuzzyLogic wrote:

I succeeded doing this many years ago. I took the Seagate MFM controller and hard drive from the old IBM PC/XT and put them in the new Pentium (it was new back then.) The controller was not recognized be the BIOS on the Pentium and the drive did not show up in DOS. So I installed Slackware Linux on the new computer and compiled a kernel with the mfm/xt disk drivers.

Cool. 😎 May I ask if your MFM controller had its own BIOS ? I once had a FileCard in my 586 and it immediately booted from it.
There was no chance in booting from anything else. Not even from floppy.

FuzzyLogic wrote:

I'm guessing that the kernel in Fedora 8 does not have the drivers for MFM controllers built in. I haven't used Redhat or Fedora in ages, but back then their kernels were bare and all drivers were stuffed in the initrd.gz as modules. So using kernel command line options is useless.

Oh, didn't know that. Thanks for the tip. It saves me wasting time on something that would never work.

FuzzyLogic wrote:

I would first figure out exactly what type of controller you have, then decide which module to load.

Western Digital WD1002A-WX1. I still don't know which module to load, but...

FuzzyLogic wrote:

Type "modinfo xd" in Fedora 8 to see if you even have the old xd.o driver. The "hd" driver cannot be built as module (but I could be wrong.) Try "modinfo hd" to find out. The "hd" driver is the one you use if you have an ST-506 controller. Check your /proc/config.gz or /boot/config to see what is available in your fedora kernel.

Cool! I'll try these options when I can. That's precisely the type of info that I wanted, because I had no idea what the driver was even called 😁 I looked at the available modules but all I could see that seemed remotely like what I wanted was the "pata" driver.

FuzzyLogic wrote:

If I were doing this again, I would probably download Slackware 3.3, which is still available, and install that into an SCSI drive (not ide.) Also, I would compile my own kernel and modules so I know the drivers I need are available.

That's an option sure, but a very time consuming option (not that so far I haven't wasted a lot of time already with no positive results...).

FuzzyLogic wrote:

I wish I had some MFM drives and controllers to try this out.

Don't worry, I'll try it for you so you won't have to 😉

If you're going for Slackware 3.3 you could also try Zipslack (should be available in the same place as the rest of the distribution) which you can unpack onto a Zip drive and boot from that. It even works with parallel port zip drives, but you have to boot first from a bootdisk with the ppa.o module which you find in the same place.

http://mirror.lug.udel.edu/pub/slackware/slac … e-3.4/zipslack/

I recommend using the kernel xt.i which has the xd device built-in (the classic kernel bare.i which is most likely the one used in zipslack doesn't)

http://mirror.lug.udel.edu/pub/slackware/slac … 4/kernels/xt.i/

(edit) the default kernel in zipslack is indeed bare.i, but the xd.o driver is available as a module so you could go ahead and use it without replacing the kernel.

To boot from a parallel port zip drive use the bootdisk iomega.s http://mirror.lug.udel.edu/pub/slackware/slac … ks.144/iomega.s

devius wrote:

SquallStrife wrote:

If you can enter the drive geometry (CHS) manually, then any BIOS that works with IDE will work with MFM/RLL, as long as the controller card is at 1F0h/3F0h where the BIOS expects to find it.

Is that the I/O address? Because the only options on this controller card are 320h and 324h. It's currently set to 320h which is the default, and even with the drive geometry manually entered it still wouldn't work.

That's right, and in that case it would appear that the interface card is designed for use in a specific system.

Even if it has its own BIOS, it could be mapped to a memory address either outside the standard option ROM area, or somewhere where it conflicts with, like, VGA or something.

Edit: https://www.dcllabs.net/docs/1002awx1.txt

So it appears that particular controller does sport its own BIOS, but doesn't have the facility to specify the memory address, just on or off.

There's a good chance it's fixed at something that conflicts with another device in a modern system, most likely VGA BIOS.

Edit2: There is some good general info here, including instructions on using debug to find the controller's BIOS base address: http://home.icequake.net/~nemesis/blog/index.php/archives/81

SquallStrife wrote:

Edit2: There is some good general info here, including instructions on using debug to find the controller's BIOS base address: http://home.icequake.net/~nemesis/blog/index.php/archives/81

Thank you very much! This link contains a lot of valuable information.

FuzzyLogic wrote:

I'm guessing that the kernel in Fedora 8 does not have the drivers for MFM controllers built in. I haven't used Redhat or Fedora in ages, but back then their kernels were bare and all drivers were stuffed in the initrd.gz as modules. So using kernel command line options is useless.

I've made some progress on this, although I still haven't had success. The default Fedora 8 kernel indeed doesn't support any of the old HDD drivers (hd and xd) so I had to build the kernel from source by following these instructions and configuring it to support the necessary hd and xd drivers.

However, I don't know how to load the hd driver. I tried the recommended approach of adding the following to the kernel boot line:

1hd=615,4,17

but it didn't work. I was still left without access to the old drive. I also found out that you were right:

FuzzyLogic wrote:

The "hd" driver cannot be built as module

So if adding the option to the kernel boot line doesn't activate it I don't know how to load it either.

Then I tried to load the xd driver which can be loaded dynamically, and here's where there was some progress. I used the following command at first to load it:

1modprobe xd xd=0,5,0x320,3

and I could hear the old HDD working!!! 😳 But it then complained that the module couldn't be loaded because the resource was busy 😢 so I tried a few more options, namely changing the first value from 0 to 11 and 12, since that value specifies the controller type and 11 and 12 are both WD controllers as well, although different models than the one I have. No luck. I also tried the following option which should allow me to override the default auto-detection of connected disks and set them manually:

1modprobe xd xd=0,5,0x320,3 xd_geo=615,4,17

But the same error about resource busy was the result unfortunately.

For reference that xd= option specifies the controller resources in the form: xd=type,IRQ,IO,DMA. and the xd_geo= specifies the disk geometry in the form C,H,S. And here is the list of controllers that are explicitly supported by the xd driver, taken directly from the source code of that driver:

• "Override geometry handler"
• " DTC 5150CX"
• " DTC 5150X"
• " DTC 5150X"
• " Western Dig. 1002-27X"
• " Western Dig. WDXT-GEN2"
• " Seagate ST11M/R"
• " Seagate ST11M/R"
• " Seagate ST11R"
• "n OMTI 5520"
• " XEBEC"
• " Western Dig. 1002s-wx2"
• " 1986 Western Digital"

Note that this list represents the types you can use in the xd=type command mentioned above. The first item in the list is 0, the second 1, etc.

That's all I had time to try so far, but as soon as possible I'll try some more option combinations to see if I have any luck.

I finally did it! 😁

The xd driver finally worked but not without one more snag. The previous "resource busy" error message was due to an IRQ conflict, but I only figured that out after looking at the output from dmesg where I could see that the driver was correctly detecting the controller card and auto-detecting the attached disk drive. However, it also mentioned that it couldn't access IRQ 5 since it was being used by another device, in this case the parallel port.

I can't just disable the parallel port in the BIOS setup (which I had already done) because the linux kernel will ignore the BIOS anyway, so I had to remove the parport driver and all other drivers using it. I used the following command which did it:

1modprobe -r parport parport_pc

Afterwards the xd driver was correctly loaded and the drive became available as a block device at /dev/xda with the following command:

1modprobe xd xd=4,5,0x320,3

Type 4 is also a WD1002 controller, although a different type, but it made no difference apparently and it worked nonetheless. The code comments on the driver source mention this possibility and it checks out.

BTW, if you want to check for conflicts on Fedora 8 this command will list all the IRQs and which drivers are using them:

1cat /proc/interrupts

The first columns are the IRQ numbers and the second one appears to be the number of devices using them. If you read a 0 here there are no devices using them even if there is a device name in the third column.

Now, after all this trouble there was one final problem. The disk has bad sectors unfortunately, so using the standard dd command to create a disk image wouldn't work since dd would just quit on the first read error. The solution was to add an option to ignore errors, making the final command:

1dd conv=noerror if=/dev/xda of=/home/me/backup.img

Finally, in case it helps anyone I attached the xd.ko kernel module built from the source of Fedora 8 kernel 2.6.26.8-57.i686. I can provide a rpm package with the kernel with support for MFM/RLL disk drives to anyone that's interested. The reason I don't attach it directly here is because it's about 18MB.