Read/Save MFM hard drive contents to modern PC

[NicolasF]

Hi,

I would like to backup the contents of the MFM hard drive to my modern PC and also I would like to create a hard drive image and then send it to the XT.
My idea would be to use either the serial or parallel port because those are the only ones avaliable that I have. I havent been able to find anything online to do this, so I'm thinking about writing a program in assembler that would read all sectors in the drive and then transmit them using serial or parallel port. I could type it using debug which is the only tool I have in the XT or... I could maybe use the option ROM for this. I know there are MFM drive and floppy emulators that could be used in my case. But they are imposible to find here or either very expensive. The same goes with floppy disks I would need to buy a lot of them. Any other alternatives?

Thanks!

 

[modem7]

I would like to backup the contents of the MFM hard drive to my modern PC and

When I read that first bit, I thought 'files', but as I read further, I realised that you are writing of a drive image.

Any other alternatives?

If file transfer is acceptable, consider:

• Serial port: FastLynx 3.3, Diagram at [here]. Use DOS' MODE.COM on vintage PC to initiate transfer of FastLynx client software from modern PC to vintage PC. More information at [here].

• An XT-CF card (or XT-IDE with IDE-to-CF adapter) in vintage PC. Move CF between vintage PC and modern PC as required.

 

[Timo W.]

MS-DOS 6 comes with InterLink (INTERLNK.EXE & INTERSVR.EXE) to connect two PCs over serial or printer port. So boot both your XT and a more modern PC with MS-DOS 6 and connect them using InterLink. You can then just dump an image of the hard disk over that connection. But it will be slow, very slow.

You can also use Lap Link, or even Norton Commander. They all support connecting two PCs over serial or parallel.

You don't need to write any tools for dumping, as they already exist. I always use "PIMAGE.EXE", but that exists in German only. Let me know if you need it anyway.

 

[NicolasF]

I didnt know that Norton Commander could connect 2 PCs over serial. It seems to be the only easy way of transfering files for me because I dont have MS-DOS 6.0, MODE.COM or Lap Link.
But I'll need to build a serial cable because I dont even have the serial port bracket. Does PIMAGE.EXE lets you transfer a hard drive image? because that would make everything so much easier. I could build the image on the newer PC and then transfer everything to the XT. Where can I download it?

 

[acgs]

You should have MODE.COM at least, it's been a part of DOS since version 1.0. If you can get Norton Commander to work for you, or PIMAGE.EXE, then the problem is solved. But @modem7's post is worth looking at more closely. It points to a site where you can still buy Fastlynx as a software download. It's an inexpensive program and has been proven to move data between DOS and Windows PC well.

 

[Timo W.]

Does PIMAGE.EXE lets you transfer a hard drive image?

No, it saves to a file. But that can be on a drive on a remote system.

 

[NicolasF]

I tried FastLynx and Norton Commander but they dont work. FastLynx shows "Waiting for connection..." on the XT and Norton Coommander wont connect. I was able to transfer the SL.EXE file from FastLynx using these two commands:
"mode com1:2400,n,8,1,p" and "ctty com1". What do those commands do? and how is it possible that the SL.EXE file was transfered but then both programs refuse to connect? The XT has MS-DOS 5 installed so InterLink is out of the question right? I had the following idea of how I could transfer some files it is a little weird but it might work. The motherboard has an option ROM installed, so maybe I could flash an eprom with a file and then use debug to read the eprom back to a file?

 

[jafir]

The mode command changes the parameters used for the serial port com1 to 2400 baud, no parity, 8 data bits, 1 stop bit, and retry until accepted.

The ctty command is changing the default console to the serial port. Tty stands for teletype, which in old computers were the primary console. So this is allowing the computer you’re trying to send the SL.EXE command to to be controlled by the computer running fastlynx.

As to why it’s not working, perhaps you’re trying to use too fast a baud rate after you send the SL.EXE A lot of XT class systems will struggle at faster speeds. Since 2400 worked, try that. Then try with 9600, and the 19,200 etc until you find the fastest reliable speed. When you run SL.EXE does it show that anything is ever received or does nothing change at all on the screen?

 

[SomeGuy]

Creating or using drive images of "MFM" and "RLL" hard drives can be tricky, as it was normal for these kinds of drives to have some bad sectors.

I've used Norton Utilities disk editor to select the sector range of an entire drive, then "write as file" to another drive. But if there are read errors, it stops.

Restoring such an image to a drive means the new drive must either be error free or have the same bad sectors.

 

[modem7]

FastLynx shows "Waiting for connection..." on the XT

Reference: The web page at [here].

The "Waiting for connection ..." tells me that step 3 was done.

Did you do step 4.2 ?

In step 4.3, did you select the COM port on the modern PC that you are using for the connection ?
When I use a USB-to-serial adapter, I find that Windows 10 normally maps it to a high COM port number, and I have to go through the procedure at [here] to get it to a low numbered COM port.

 

[NicolasF]

Reference: The web page at [here].

The "Waiting for connection ..." tells me that step 3 was done.

Did you do step 4.2 ?

Yes

In step 4.3, did you select the COM port on the modern PC that you are using for the connection ?

Yes

When I use a USB-to-serial adapter, I find that Windows 10 normally maps it to a high COM port number, and I have to go through the procedure at [here] to get it to a low numbered COM port.

In the Win10 PC mine is COM9. Then I changed it to COM2.

I also tried it using an HP Proliant ML350 G9 that has a serial port with Ubuntu 20.04 and it wont connect.

DosBox starts showing these messages:

"Serial1: Errors: Framing 0, Parity 0, Overrun RX:28 (IF0:0), TX:0, Break 0"

Norton Commander in DosBox shows "COM2 port is not avaliable" after a while

and FastLynx shows "Connecting on COM2..." all the time

 

[modem7]

Does your cable match what is shown in the diagram at [here] ?

Although you could transfer the FastLynx client across, maybe the client transfer only uses some aspects of the FastLynx compatible cable, with subsequent connection using all aspects of the FastLynx compatible cable.

 

[modem7]

Apart from the cable, the other thing that I see in common is the serial port on the XT.

Ideally, you would do a full functional check of that using a loopback connector and appropriate software, to confirm operation of the hardware handshaking lines. Again, it could be that the transfer of the FastLynx client only requires rudimentary functionality.

From your, "... using these two commands: 'mode com1:2400,n,8,1,p' ...", I see that it is COM1 in DOS. But note the information at [here]. If your XT has only only one serial port, and that port sits at I/O base address 2F8h, then DOS will refer to it COM1, but some other programs will consider it to be COM2. So just in case some sort of COM port number 'confusion' is going on, verify that the XT's serial port is at I/O base address 3F8h, and using interrupt 4.

 

[NicolasF]

I was able to get an ethernet 3com 3C509 card. But now I need to transfer the drivers to see if I can make the card work. So what I did was to connect the UART from the OrangePi to a TTL-RS232 level converter and then with the null cable to COM1 on the XT. I'm able to transfer a file with a QBasic program that I wrote but I dont think the file is being transfered correctly because it hangs when I run it. This is what I type on the Orange "cat "3c509.com > /dev/ttyS1" and this is the program I wrote.

DIM datos AS STRING * 8145

OPEN "COM1:9600,N,8,1,BIN,CD,CS,DS" FOR RANDOM AS 1 LEN = 8145
OPEN "3c509.COM" FOR RANDOM AS 2 LEN = 8145

PRINT "Receiving..."
GET 1, , datos
PUT 2, , datos

CLOSE 1
CLOSE 2

Is this the correct way of storing binary data in Basic? I'm also thinking I should write a CRC check program to see if the file was transfered correctly

 

[modem7]

I'm able to transfer a file with a QBasic program that I wrote but I dont think the file is being transferred correctly because it hangs when I run it.

Is this the correct way of storing binary data in Basic?

Are you implying that text files are transferring damage free, both short and long (long to test flow control) ?

 

[NicolasF]

Are you implying that text files are transferring damage free, both short and long (long to test flow control) ?

Text files seem to be transmitted ok, but I only sent short ones, like autoexec.bat and config.sys. I did not connect the flow control lines, only TX and RX. I found that the problem is DosBox, it does not transmit anything over the serial port. I dont even have a terminal program in the XT so that I would be able to securely sent a file using a protocol like zmodem or xmodem. If only I could send a program like Telix or Kermit I'm guessing I'm done. I cant figure out how FastLynx is able to send sl.exe because if I knew how the transmit that file I'll do the same to send a terminal program.

 

[modem7]

Text files seem to be transmitted ok, but I only sent short ones, like autoexec.bat and config.sys. I did not connect the flow control lines, only TX and RX.

And ground as well. A 'three-wire' serial cable. For short files, or for long files if a software flow control protocol, like XON/XOFF, is in place.

I found that the problem is DosBox, it does not transmit anything over the serial port.

Hang on. You wrote that short text files "seem to be transmitted ok". So you must be writing of some other attempt to send files. Adding context to sentences will help.

I cant figure out how FastLynx is able to send sl.exe because if I knew how the transmit that file I'll do the same to send a terminal program.

As I wrote earlier, one possible problem cause is that you are not using the cable specified by the makers of FastLynx. I have not seen you write, "Yes, I am using that FastLynx compatible cable."

Are you aware that you should be able to connect up a 1.44M diskette drive in your "XT" (IBM or clone), and use that to read 720K sized diskettes. See [here].

Maybe what is is [here] interests you. I doubt that a 'three-wire' serial cable was used.

 

[NicolasF]

Ok, I'll try to explain all the tests I've done more clearly. The cable I'm using has the ground connected on both ends and the 2 RX and TX signals crossed. That means the RX from one end goes to the TX on the other end and viceversa. Trying to receive a file larger than 8K with that Qbasic program I wrote is not possible because it shows an "Out of memory error". When I try to send anything from either a newer PC or the OrangePi with 'echo "1234" > /dev/ttyS1' (I did check with a scope and multimeter and there is information being transmitted from the PC or the OrangePi) and then receving on the XT with commands like "TYPE COM1" or "COPY COM1 file.bin" always shows "General failure reading device COM1". DosBox never sends anything to the USB to serial port adapter that I have, tried linux, Windows 10 and I even tried it with a HP Proliant ML350 G9 server that has a dedicated COM port. I've burned a 32kb EPROM with part of a file that contains a terminal program called TXZM (Texas Zmodem) which is about 49kb in size. The idea here was to dump the contents of the option rom to a file. I would have to do this process 2 times and then join both dumps to restore the original file. But when I install the EPROM in the option rom socket the hard drive stops booting and says there is no booteable disk. There must be some other way to send files without having to get a disk drive or diskettes. I'll keep trying to improve my basic program to receive files more eficiently.

 

[modem7]

There must be some other way to send files without having to get a disk drive or diskettes.

Yes. FastLynx, for example, but for some reason unknown to me, you do not want to use a FastLynx compatible cable.

I get the impression that you want to come up with your own serial solution (rather than use a proven serial solution) but do not have a deep enough understanding of serial communications (hardware level and software level).

The cable I'm using has the ground connected on both ends and the 2 RX and TX signals crossed. That means the RX from one end goes to the TX on the other end and viceversa.

If you insist on using a three-wire cable (i.e. no hardware flow control), note that for some situations, you need to fool software that hardware flow control exists by looping back the hardware flow control lines. For DTE-to-DTE, see the second wiring diagram in the '4 Null modem cables and adaptors' section at [here].

But that is 'pretend' flow control.

or "COPY COM1 file.bin"

For example, that is inappropriate for binary files, even with flow control in place. When used like that, COPY is expecting a text file. And COPY has no idea how many bytes it needs to wait for before it closes the file - as soon as it sees a 26 (CTRL-Z, an end-of-file marker in a text file) arrive, it considers the end of the file to have been received. As you can imagine, 26 can appear in the middle of a binary file.

 

[NicolasF]

I finally made it work! I had several things wrong. The TTL to RS232 level converter was only converting the RX and TX signals but not the CTS, DSR, RTS and DTR signals. The second thing was the BIOS, I was using GlaBIOS and for some reason the serial interrupt was crashing and also when I installed the option ROM it made the hard drive not to boot. So I had to go back to the original BIOS. Then I flashed a small 8k program called vtemu in the option ROM and then dumped it using Debug to a file. Finally I was able to transfer files using kermit from the PC back to the XT. I now have all the drivers for the 3com ethernet card.