wiki.fryktoria.com

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== A Guide to Salvage content from 5 1/4" 360K floppy disks ======

===== Introduction =====

This projects describes the retrieval of files which are stored in 5 1/4" 360KBytes floppy disks.

The article is a bit lengthy, but it is like archaeology: You need to have a rich background in order to analyse a pottery fragment... 

I am sorry for the terrible pictures. Time was pressing to finish as soon as possible and free the precious room space, so documenting was not a priority. Family guys shall understand.

===== Preface =====

The year is currently 2020. While working on a project, I remembered that I have implemented a similar algorithm some time in the previous century, back in 1987. The code was part of my personally designed and implemented  6502 development system, which included a micro-controller card equipped with an 6502 microprocessor, along with several peripherals. I used to develop code in Assembly on an IBM-PC compatible computer, a **Lingo PC-88 XT** with an 8088 processor, 640K of RAM, two 5 1/4" 360K floppy disk drives, no hard disk and a CRT composite monochrome monitor, which I have purchased second-handed from a friend, at a price of 200.000 GRD, sometime around 1983. I have expanded the system with some custom-made expansion boards of my design and later I was happy to add a mouse which occupied the serial port. 

Several other computers have found their position on my desk over the years and the Lingo was exiled in the attic, accompanied by several old laptops. Not all laptops - I still have an IBM 2645 Thinkpad which used to run Windows 95 in my lab. But its purpose now, in its beautiful leather-like bag with the IBM logo on it, is to be a door stopper!!!! I still have a Compaq Armada laptop, which I used to run the **Sniffer Network Anallyzer** which I had purchased at the enormous price of 2.000.000 GRD. Wireshark is now free!!! None of those computers had support for 360K drives. In the evolution process of computers, the floppy drive was one of the first components to become obsolete.

Fortunately, I have kept my stock of 360K floppy disks safely in a drawer, away from humidity and temperature extremes. It was not long before I located the floppy that I wanted. 

I had to sustain a lot of laughs from my same-aged friends when I asked them if they happened to have a disk drive that could read 360K Double-Sided Double-Density floppy disks and transfer the files to a USB stick or over the network!

After realizing that I had been left on my own, I started to explore some not so obvious options. The most promising was to exploit another 386 PC which is in the pre-exile attic phase and has an IDE bus, one 3" 1.44M floppy drive and several hard disks. It used to run Windows 2000, as well as a version of SuSe Linux and is still operational. The plan was to extract the 360K disk drive from the Lingo, connect it to the IDE bus of the 386, read my floppy and transfer its contents to a small capacity USB stick. At least, USB  was supported by the motherboard of this 386 after its last and final BIOS upgrade. Unfortunately, in spite of the fact that the BIOS was set-up to recognize 360K drives, both Windows 2000 and SuSe Linux 7.1 were not equipped with the proper drivers, resulting in total failure. Really disappointed by Linux!

Another option was to start the 386 via a Linux-on-a-disk recovery disk, such as [[http://http://www.toms.net/rb/|tomsrtbt]]. This minimal Linux included the basic drivers for several devices and has put me through several difficult situations in the past. Then, I could hopefully read the 360K drive, store the data on the hard disk. Reboot to Windows or SuSe which recognized the hard disk and move my files to USB. Unfortunately, it was very difficult to remove the drive from the Lingo, because it was packed very tightly in a pre-ATX format case. On the other hand, the IDE cable could not reach due to its limited length both the 3" drive and the 360K drive outside its box. Another disappointment! 

Along with the rest of the software of the time that I have kept, a big box cought my eye. The box was an original packet of Procomm Plus, a program that I used with my //high-speed// **1200bps modem** to communicate with private Bulletin Board Services (BBS) run my friends in hobby communities. The box even contained a thick instruction book! **Once again, RS-232 to the rescue!!!!**

**Procomm Plus packet**
{{ :retro:floppy-pcplus-box.jpg?200 | Procomm Plus packet}}

So, in order to retrieve the valuable content from a floppy the plan is:

  - Re-instate and set up the old 8088 Lingo PC, with its huge green-screen monitor - involved lots of conflict and painful negotiation with the spouse
  - Physical connection with my current PC which runs Linux Mint over a serial interface
  - Install minicom, along with a xmodem/ymodem/zmodem software on my Linux PC
  - Transfer the files

===== Step 1. Set up the old PC =====

This one was a journey to the past. I had to bring back to memory the function of each of the connectors on the back side. A few words for each is in order:

==== Keyboard ====

The keyboard uses a [[https://en.wikipedia.org/wiki/IBM_PC_keyboard#Connection | 5-pin DIN 41524]] XT type round connector. PS/2 is not suitable. Fortunately, I have kept the original keyboard of the Lingo PC in the attic. Some keys did not respond immediately but after a few keystrokes, worked like a charm.

==== Graphics Card ====

Two types of graphics card were common at the time. The **[[https://en.wikipedia.org/wiki/Color_Graphics_Adapter |Color Graphics (CGA)]]** (640x200 in 2 colors, 320x200 in 4 colors) and the **[[https://en.wikipedia.org/wiki/Hercules_Graphics_Card | Hercules Graphics card (HGC)]]**. Athough I used to work mostly with the Color Graphics card, I had salvaged at some point in time a Hercules and I had both installed in the computer. The Color Graphics card was recognized by the system as the default in a double-card installation like mine. Thankfully, my memory is good and I remember that I had to type **''MODE MONO''** in the blind, if I wanted to work with Hercules.

The Color Graphics card had an RCA composite video output. The card has internally a set of header pins, which implement the serial port. With a flat ribbon cable, the port is made available outside the case. There is also a D-type 25 pin connector, which may be a parallel port. I remember that there was also a game port which connected to analog joysticks, but I did not have the time to locate it.

The Hercules card had the D-type 15-pin connector for the monitor and a D-type 25-pin printer connector.

==== Monitors ====

I had two CRT Monitors. The one working with the Color Graphics card had a composite video input, with an RCA connector. In spite of the fact that the card supported colors, the screen was monochrome. (//I have managed to design several double-sided PCBs, even with the two sides appearing as different shades of grey!!!//). The other screen had a 15 pin D-type connector. 

==== Serial port ====

The serial port was a D-type 25-pin male connector, made available from the CGA. 


==== ... and now, work time ====

After dusting-off the parts and connecting the keyboard and the screen to the CGA, the process was easy. Power up and insert the MS-DOS floppy in drive A. 

No bad smelling, so it seems that the electrolytic capacitors have somehow kept their juices. 

A lot of noise from the fans, the drive groaning, but nothing on screen. 

Several moments of embarrassment and disappointment, but memories slowly started to emerge: Although the CGA was the system default card, during my final days operating the system I did lots of paperwork with **Volkswriter** word processor and I mostly used the Hercules Monochrome card with the associate monitor, because of their better resolution. So the **AUTOEXEC.BAT** in my working MS-DOS disk had the **''MODE MONO''** command which activated the Hercules. In the blind, I typed **''MODE COLOR''** to switch to the CGA and the result was real life on the monitor!!! Several horizontal lines, more like noise. This is a CRT monitor, remember? 

Again, some tweaking on the Horizontal and Vertical sync regulator potentiometers on the back, some brightness from the potentiometer at the front and finally, the **A>** prompt appeared on screen.

At that moment, besides the monitor, I had also synchronised myself: **''DIR''** to see the contents of a disk, **''DIR /p''** to have the screen output stop at a full screen, **''TYPE''** to print the contents of a text file. Filenames are only upper-case, no matter what you type on the keyboard. 

//And the keyboard feeling was magic. Nothing like the membrane pads of today. A beautiful click-sound to make brain-fingers-eyes-ears operating in conjunction at the proper speed.// 

After several nostalgic moments and fighting the urge to start playing one of those virus infected games that came as free disks in magazines, I came back to reality, with the mandate to complete the job that I started with: the transfer of content from a floppy.

On the old PC side of the communication link, I will be using **Procomm Plus**. If both computers ran MS-DOS, we could use some beautiful programs such as **LapLink** or **Brooklyn Bridge** which I used back then. I remember that you could operate the disks of one computer through the other, like the two windows of a **Norton Commander** screen and transfer files from one side to the other. But there are no such programs running both for Linux and at the same time maintain compatibility with those programs of 35 years ago. Or perhaps I did not search too much. 


**Procomm Plus** is a terminal emulation program that allows to set the communication parameters (such as baud rate, parity etc) and several other parameters to mimic various types of TTY terminals. At those times, different manufactures provided various types of terminals with variations in the encoding, character sets, escape codes, keyboard layout etc. **[[https://en.wikipedia.org/wiki/VT100|VT-100]]** was a very common terminal. ANSI and VT-100 were the standards. Terminal emulation programs such as Procomm Plus were designed to be configured and mimic the behaviour of such terminals.  

The version of Procomm Plus that I had, supported Xmodem, Ymodem and Kermit. It did not support the most sophisticated Zmodem protocol. As far as I can recall, Zmodem was developed by some other company and had to be licensed separately. But, at least, Procomm Plus supported a batch transfer mode (**YMODEM-BATCH**) that would allow me to transfer all files in a floppy disk in one go.

**Procomm Plus splash screen**
{{ :retro:floppy-pcplus-splashscreen.jpg | Procomm Plus splash screen}}

A few notes here:

Procomm Plus, at least in my ''1.1b'' version, comes with two floppies. I inserted the //"Program Diskette"// in drive A: and the //"Supplemental Diskette"// in drive B:. After some system complaining about not finding files, I remembered how to work with the two floppies. Set B: as the active drive and run the program from A:, keeping B: drive as active.

<code>
A> B:
B> A:\pcplus.exe
</code>

So I started Procommm Plus. Use **Alt-P** from the main Menu to set the communication parameters. 

**Procomm Plus menu**
{{ :retro:floppy-pcplus-menu.jpg | Procomm Plus menu}}

Just for testing, set the parameters to **9600bps, no parity, 8 data bits, 1 stop bit**. In my case, the serial port is identified as device **COM1:** Save and exit with **Alt-S**.

Now I can remove the Supplemental Diskette from drive B:. I will use this drive to load the floppy that contains the files that we wish to transfer.


===== Step 2. Create the serial link =====

This is probably the most difficult part for the non-initiated to serial communications. **[[https://en.wikipedia.org/wiki/RS-232 | RS-232]]** was a very common interface through which a computer (in RS-232 parlance operating as **Data Terminal Equipment DTE)** communicated with peripherals (**Data Circuit-terminating Equipment DCE**) sending one bit at a time, such as modems. Printers used the faster, 8-bit at a time, **Centronics** parallel interface. Wiring a DTE to a DCE is a simple on-to-one connection, pin 1 of DTE to pin 1 of DCE, pin 2 to pin2 etc. But to make two computers (two DTEs) talk to each other, the wiring needs to be manipulated. A [[https://en.wikipedia.org/wiki/Null_modem | Null-Modem]] is a device to make the necessary cross-connection between signals. Unfortunately, the function of each pin and signal was not fully standardized and serial card manufacturers and modem manufacturers had a lot of variations in their designs. What was somehow obvious is the following:

  * The DTE transmits from the TX pin and receives from the RX pin.
  * The DTE will raise the DTR (Data Terminal Ready) signal when it wishes to communicate with the modem for transmission or reception.
  * The DCE will raise the DSR (Data Set Ready) when it is ready for communication with the DTE. Some modems raised the DSR only after receiving a DTR. Other modems had DSR ready all or most of the time. 
  * The DTE will raise the RTS (Request To Send) when it wishes to transmit (not to receive) data.
  * The DCE will respond to an RTS with a CTS, when it is ready to transmit data to the other DCE, on the far end of the phone line.
  * The DCE modem will raise the DCD or CD (Data Carrier Detected) when it receives a carrier signal from the other modem.
  * The DCE modem will raise the RI (Ring Indicator signal) when it receives a telephone call and the phone line is ringing.

This big number of control pins was necessary at a time when modems were implemented with a large amount of discrete equipment, had no intelligence and required manual actions to switch from transmission to reception as they were not originally operating in full duplex mode and therefore all this pins actually did something useful. The D-type 25 pin connector also has pins to support a second channel, although I have never seen such an implementation myself. 

There are several null modem configurations and you can find several online. Several issues and considerations are mentioned [[https://www.lammertbies.nl/comm/info/rs-232-null-modem | in this article]]. //No null-modem configuration can be considered as 100% perfect because of the fundamental issue that RS-232 was designed so that a DTE communicates with a DCE//. And even then, there were several compatibility issues because of different interpretations of the standards. Handshaking is an issue but software solutions such as **XON/XOFF** may help in a much better way.

If you want to build a null-modem yourself, the most easy configuration and one that will most probably work, assumes that both sides are ready to communicate. Each side can even transmit without caring if the other side is active, such as needed in testing. For this configuration, cross the TX and RX pins between the two DTEs, connect the DTR to DSR and DCD, as well as the RTS with the CTS on the same side of each DTE itself. No control signals go to the other computer. Therefore, only TX, RX and Ground travel from one side to the other.

In summary, the wiring is as follows:

If you want to construct a **25-pin null modem**: 
    2 to other side 3, 
    3 to other side 2, 
    7 to other side 7, 
    4 to same side 5 (on both sides), 
    20 to same side 6 and 8 (on both sides)

If you want to construct a **9-pin null modem**: 
    2 to other side 3, 
    3 to other side 2, 
    5 to other side 5, 
    7 to same side 8 (on both sides), 
    4 to same side 1 and 6 (on both sides)

You can also construct null modems with a 9-pin connector on one side and 25-pin on the other, but this discussion has already gone far enough. 

One must be extremely careful in handling the RS-232 pins and wires. RS-232 electrical characteristics require one logic level (a **"space"** or **logic LOW**) to be in the range between **+3V** and **+15** Volts and the other logic level (a "mark" or logic HIGH) in the range between **-3V** and **-15V**. Voltages between **-3V** and **+3V** are not allowed. The confusion with voltages and levels increases because when the line is idle, its level is HIGH, which is negative voltage and when the transmitter starts sending, it sends a start bit which is logic LOW and which is positive voltage. Control signals, when raised, become LOW which is a "space" with a positive voltage. Anyway, we do not need to go into details, just remember that we **MUST AVOID CONNECTING BY MISTAKE TX WITH THE TX OF THE OTHER SIDE**, especially when one is transmitting. Old components usually were not protected from such short-circuts, and a wiring error may result in frying the serial driver chip. 

I use a device which identifies the active pins with LEDs, so after connecting to each side separately, I am certain that I do not provoke a short-circuit. It is better to remove this device after the test, because the energy consumed by the LEDs may cause problems, in case the line drivers cannot provide so much current to light the LEDs. 

**RS-232 LED monitor**
{{ :retro:floppy-rs232-ledbox.jpg?300 | RS-232 LED monitor}}

If such a device is not available, use a voltmeter to test the voltage between TX, RX and Ground pin. A definite negative voltage will identify the TX pin. 

Another headache is caused by the number of pins of the connectors. RS-232 does not specify without a doubt the mechanical characteristics of a connector (at some version of the standard, it became mandatory but the game was already lost. Even telephone plugs were used to implement RS-232 for certain devices). The D-type 25-pin was originally the norm. Since most pins remain unused, a D-type with 9 pins became common. There are devices to convert the 25-pin format to 9-pin. It is just electrical connections from one side to the other, no electronics inside it.

**9/25 adaptor**
{{ :retro:floppy-9-25-adaptor_1.jpg?300 | 9/25 adaptor}}
{{ :retro:floppy-9-25-adaptor_2.jpg?300 | 9/25 adaptor}}

The final headache is the connector gender. The DTE had a male connector and the DCE a female one. It is obvious that the connectors of the interconnecting wire should match the gender of the endpoints. Since we have two DTEs, meaning two male connectors. But we also need to take into consideration the gender of the null modem connectors, as well as a 25-to-9 pin adaptor. 

The path of devices and connectors is:

<code>
Linux PC <->  USB-to-serial <->   9-to-25    <-> Null-Modem <-> Cable(3-wire) <-> Old PC
                  adapter         adapter                     
    [USB]      [USB     9-M]     [9-F 25-M]      [25-F 25-M]    [25-F   25-F]     [25-M]
</code> 

Since the old PC side is most probably a 25 pin male and the USB-to-serial converter is a 9-pin male, we would need a 9-to-25 adaptor where the 9-pin side is female. Most probably, the 25-pin side of this adaptor would be male. Our null modem would most probably had a male and a female connector at each side, so we end up again with a male side. Finally, we need a cable with female connectors at both ends, having a length suitable to reach the span between the two computers. If we only have a male to female cable, a female-to-female gender changer will finish the puzzle. 

I could also have suggested using a cable with 9-pin connectors on both sides instead of the most bulky 25-pin ones, but sometimes the null modem casing is big and under the stress of the weight of the cable, so it cannot mate the PC's connector efficiently. A cable would help to alleviate those problems and move the null modem away from the PC.

The above set-up is one of the many possible configurations and component combinations that can be made, depending on the availability of components.  To have a fit-all gender matching solution at the time when I was working extensively with such communications, I always carried with me two multi-gender devices that I have constructed with **[[https://en.wikipedia.org/wiki/Insulation-displacement_connector|Insulated Displacement  Connectors (IDC)]]** and a piece of ribbon cable. One with 2 male and 2 female connectors at 25 pins and another with 2 male and 2 female connectors at 9 pins. With those, along with several gender changers (male-to-male and female-to-female) such as the ones shown below, I could handle any possible configuration. 

===== Step 3. Set-up my Linux PC =====

Most contemporary PCs are no longer equipped with an RS-232 port. USB has made serial, parallel, keyboard, mouse and other ports obsolete several years ago. I am lucky to have an **HL-240 USB-to-serial adaptor** based on the CH-340/341 chip, such as the one shown below. You can find them online.

**HL-340 USB-to-serial adaptor**
{{ :retro:floppy-hl340.jpg?300 | HL-340 USB-to-serial adaptor}}

After inserting the USB-to-serial adaptor to a USB port of my PC, it is recognized as a serial terminal device:

<code>
$ dmesg

[96231.903250] usb 3-1.3: new full-speed USB device number 21 using uhci_hcd
[96232.028270] usb 3-1.3: New USB device found, idVendor=1a86, idProduct=7523
[96232.028275] usb 3-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[96232.028278] usb 3-1.3: Product: USB2.0-Ser!
[96232.030365] ch341 3-1.3:1.0: ch341-uart converter detected
[96232.043363] usb 3-1.3: ch341-uart converter now attached to ttyUSB0
</code>

The voltages produces by this device are close to the limits of the expected RS-232 operating range in the 5V area, so be cautious.  For the control signals (RTS and DTR), you can measure them with a voltmeter. The HL-340 as far as I understand, produces only +5V (which is a space or logic LOW) and relies on the opposite side to receive a negative voltage. Through this, it produces the negative voltage that it needs for its own TX. Therefore, it is not possible to test the TX pin with a voltmeter at an unconnected HL-340. Just make sure that your null modems are wired to the proper pins.

On the software side, **PuTTY** has served me well on Linux, but unfortunately it does not support file transfer over serial interface. I did not spend a lot of time to search around for extras, because I knew that **minicom** supports file transfers, with the addition of an external program **lrzsz**. The program lrzsz implements some file transfer protocols such as Xmodem, Ymodem and Zmodem. Those, along with Kermit alllowed the transmission and reception of files over dial-up serial ports.So, minicom and lrzsz to be installed:

<code>
$ sudo apt-get install minicom
$ sudo apt-get install lrzsz
</code>

After installation and since my serial adaptor is recognized as **/dev/ttyUSB0**, I start minicom at 9600 bps:

<code>
$ minicom -D /dev/ttyUSB0 -b 9600
</code>

Now, the two computers are able to talk to each other over the serial interface. Whatever you type on the keyboard of one, appears on the screen of the other. If everything has not gone as described above, there is no point to continue. Go back, search, research and fix. 

We are now good to go and start the transfer.

===== Step 4. File transfer =====

**IMPORTANT UPDATE:** On the Linux machine where you intend to transfer your MS-DOS files, I suggest that you create a Linux **Virtual Machine**  and do all the work from inside this VM. Although my original intention was to get a couple of text files, I ended up with complete disks with executable .COM and .EXE files. There is a strong concern that **__your disks might be infected by some form of computer virus__**. I do not know if the VM will provide 100% containment of the effects of a rejuvenated virus, but I think that it would be prudent to limit its consequences. In addition, use only terminal mode and avoid moving the files around with window file managers. These file managers interact with the files in order to read their extension and present a snapshot of their content in the graphical interface. **WE DO NOT WANT THAT! YOU HAVE BEEN WARNED. WORK AT YOUR OWN RISK.** 

On the Linux side, start a terminal and run ''minicom''. I had problems with aborted file transfers when I tested 115200bps. By trial and error, the **maximum stable file transfer speed was found to be 38400bps**.

<code>
$ minicom -D /dev/ttyUSB0 -b 38400
</code>

Prepare the reception on this side. Press **Control-A** then **Z** and you will see the minicom menu screen. 

**minicom menu**
{{ :retro:floppy-minicom-menu.jpg | minicom menu}}


Press **O** (omicron) to set the folder where the received side will be stored. Select an empty folder, because we may need below to delete unconditionally all received files and we wouldn't like to delete something other than the received files. **__DO NOT SKIP THIS POINT. YOU WILL REGRET IT LATER IF YOU DO__**.

From the menu, select **R** to receive files. You shall see a screen that asks you to select a transmission protocol. Select ymodem.

**minicom protocol selection**
{{ :retro:floppy-minicom-protocol.jpg?300 | minicom protocol selection}}

minicom will now wait for the other end to start the transmission. Do not take your time because it might timeout.

Now go to the old PC. First make sure that you have set the communication parameters to **38400, no parity, 8 data bits, 1 stop bit**. Use **Alt-P** from the main Menu. 

Then, load drive B: with the floppy which contains your data. Press the **PgUp** button and you will see a screen asking you to select the communication protocol. Select option **12, YMODEM-BATCH**. This will allow you to send multiple files at once, without specifying the name of each file. 

**Procomm Plus Protocol selection**
{{ :retro:floppy-pcplus-protocol.jpg | Procomm Plus Protocol selection}}

The following screen will ask you which files you want to transfer. For all files, select **B:\*.*** and press Enter. 

**Procomm Plus File selection**
{{ :retro:floppy-pcplus-file.jpg | Procomm Plus File selection}}

Hopefully, the file transfer will commence and you will end up in a little while with the file or files in the folder on your new computer. Messages in both computers that will inform you about the progress of the transfer. On the Procomm Plus side you can see the progress of each file but not the total time for all files. On the minicom side, you can see only the names of transferring files. 

**Procomm Plus Transfer Progress**
{{ :retro:floppy-pcplus-progress.jpg?300 | Procomm Plus Transfer Progress}}

**IMPORTANT NOTE:** On your new PC, start a terminal and enter the folder where you just transfered the files. In the best case scenario, the date of the files is set to **January 1, 1970**. In the bad scenario, the date is set to a //really large number// which causes window file managers to crash. I have not spent time to search why this happens. The easy way out is to delete all files and repeat the transfer. That is why I stressed the need to set up a distinct folder. In my case, most transfers were successful the first or second time. 

As you have already noticed, the date of each file, as it appeared on the 360K floppy is not preserved after the transfer. What I did was to keep a log of the original content of the floppy. While the 360K floppy is in drive B:, press **Alt-F4** in ProcommPlus. This will take you temporarily in MS-DOS command prompt, without hanging up the line. Since you started Procomm Plus while being in drive B:, this drive is still active. Type:

<code>
B> DIR > COM1:
</code>

You will see the contents of the floppy disk appearing on the screen of your Linux PC. I created a text file and copied the folder listing from the terminal to the file with copy and paste. Therefore, I kept the size and date of the file exactly as it was on the original floppy disk.

In addition, check the case of the file names. Some files end up in capital letters, others in small case. I have not checked why this happens. For text files that you have created, may be it is not important. But if you try to run a program with **qemu** or **dosbox**, I cannot anticipate the consequences.

After the transfer, the permission of each file is random (?). Set the proper permissions:

<code>
$ chmod 644 *
</code>

There are some additional gotchas in the file transfer. 

  - When Procomm Plus asked us to specify which files we wished to send, we responded *.*. If the files in the floppy were arranged in subfolders, those would not be transmitted unless you specified explicitly **''B:\SOME_SUBFOLDER\*.*''**. Thankfully, at the time when the size of the disks was so small, we usually kept our files in the root folder of each disk. Sub-folders became common in our day-to-day use only later, with the advent of hard drives and the ability to store and archive large amounts of data. (//I remember my first hard disk with the "huge" capacity of 10Mbytes which I considered inexhaustible//). Yet, if you face a situation where you need to move an entire folder tree, I suggest to compress the entire disk first with a ZIP utility into another disk in drive A: - because probably the free capacity of the original disk will not be sufficient - and then transfer the zip file. I have not done this myself but this is just a suggestion.  
  - Most floppy disks were infected with various forms of viruses. I would not risk to run a transferred program with qemu or dosbox in my working environment. I am also not certain if such a virus can be contained in a Virtual Machine. If you have any knowledge on the subject, please let me know.   
 
====== Conclusion ======

I have presented a process to retrieve data from old 5 1/4" 360K floppy disks into the hard drive of a new Linux PC using a serial transfer mode. Setting things up took most of the time. In contrast, transferring the files of an entire disk takes a few minutes. 

I took the opportunity to transfer several of the programs that I used back then, such as **OrCAD** for creating schematics, **smARTWORK** for designing PCBs, programming languages such as **Forth**, various cross assemblers and disassemblers. 

Most disks were read successfully. //From 53 disks transferred, only 3 files in one disk were not possible to read//, causing the infamous //"Abort, Retry or Ignore"// message. And those disks were written 35 years ago and remained untouched for the past 30 years!

//Problems encountered//:

  -  Speed limitation to avoid aborted transfers 
  - No preservation of original file date
  - No preservation of the filename letter cases
  - Not possible to transfer a folder structure 
  - Possibility of virus infection 

The old floppy disks stored information in a format which is less condensed than contemporary magnetic media. So, if your disks had not been subjected to strong magnetic fields, extreme temperatures, mechanical vibrations or any severe abuse, there are strong chances that you will be able to recover your data stored on those clumsy 360K floppies. 

Good luck!   

~~DISQUS~~