Today there are adapters available allowing you to connect historic floppy drives to a modern PC. This allows you to copy data from historic floppy disks to the PC.
In the late 1980s and the early 1990s many users switched from an 8-bit system to a 16- or 32-bit system. So the problem of transferring data between systems should already have existed in that time.
How was data typically copied from a 8-bit system to a 16-bit system in that time?
Were similar adapters already available then?
The most classic serial solution here was ofc a direct serial connection and Kermit the most versatile software solution. Developed at the Columbia University, NYC, Kermit supported already in the early 1980s several hundred different systems. It's most prominent feature was the ability to run over non transparent and code converted connections.
Similar, but less comfortable and universal, X/Y/Z-Modem was used. With a straight, transparent 8 bit capable connection XMODEM and its follow ups, where easy to implement.
If the target was a PC or PC-alike machine, and the source some machine able to write standard FM/MFM diskettes (usually CP/M and alike), foreign floppy reader utilities were availible. Most prominent back then Xeno-Disk from Vertex. But also Sydex' ANADISK (or 22DISK) and Teledisk. (*1,2)
For more exotic formats, like the Apple II, there where hardware solution, as Vertex' Turnover Card for the PC of 1984. In April 1984 the German computer magazine mc published an article about using the Commodore VIC-1541 Floppy with other systems. As a follow up several solutions to connect a 1541 to PCs showed up. (*3)
*1 - Herb Johnson did dig a bit into the actual situation about ANADISK.
*2 - More recent developments are for example OnmiFlop or PC-Lect.
*3 - Nowadays there is also Kyroflux an expensive but rather good solution for weird formats.
I personally did not do any data transfer from home 8-bit systems to other systems, but I did do transfers from several older proprietary systems to Unix and MSDOS systems back in the 80’s.
We used a null modem cable (serial cable) and software called B.L.A.S.T. which was a commercial product that was ported to a wide variety of systems. It is a serial transfer protocol, on the lines of xmodem/zmodem/kermit.
We would use those more “open” protocols when possible, but the benefit of BLAST was that they did the ports to so many systems, so it was easier to just buy it for the systems you needed. For example we moved many customers from DG Nova systems to Unix, and used it to transfer their data files.
I worked on a project quite a few years ago (late 80's) where a client purchased truckloads of surplus military electronics inventory that he intended to sell into the spare parts market. The inventory documentation came out of a mainframe computer and was printed onto a three inch stack of fanfold green bar computer paper. The project I was hired for was to move this data to PC type machine that was modern at the time.
I implemented the project in the following stages:
Out of the work I recall that there were only about 20 records that did not come across clean and the filter program rejected as not able to correct. Almost all of those were due to handwritten notations that had been made on the original computer printouts.
In the end the result was way more reliable than if a data entry person would have had to spend a huge amount of time retyping thousands of records of data that had about 120 columns in each record. It took me about 4-5 days to do the task and probably cost the client less than hiring someone to hand type all that data.
No, there were no adapters for different floppies.
Data was typically copied by serial port, if it was copied at all: Programs on some 8-bit computer (e.g. Apple II, Commodore 64) wouldn't run on an 16-bit 8086 PC. There were no emulators (and the original 8086 PC would probably also have been too slow).
So stuff you'd like to copy were typically source files of your own code, so you could re-compile (after adaption) on the new computer. Businesses probably also would want to copy data, but I was too young to have witnessed how that was done.
I actually transferred my source code from the Apple II to an IBM PC this way, and as I didn't have a serial card, I used the game port on the Apple II with a bit of external electronics to emulate a (slow) serial port. That was enough for my needs.
There were (and are) a few possibilities to transfer programs* and data between 8 bit Commodore systems and other platforms via floppy disks and other media.
Commodore 1541 floppy drives could be modified to read, and to a limited extent, write PC compatible floppies.
Commodore 1571 and 1581 floppy drives for 8-bit Commodore home computers were able to read and write PC compatible floppy disks. No hardware modifications are needed, just some software.
The X1541 Cable and it's derivatives made it possible to connect a Commodore floppy drive to a PC parallel port, and read-write Commodore floppies in DOS.
Not limited to Commodore:
Serial modems were used to transfer files between computers located far away from each other. One could upload files to a BBS and download them to a different computer.
Cassette tapes could be read on any platform that had an audio input. I can vaguely remember coding a tape loader for Commodore +4 that could display a picture saved on a ZX Spectrum.
*Commodore emulators for the PC were already in development in 1990, they obviously needed the ROM images and as much test programs as possible.
I have done my share of transfers between incompatible systems.
There were some service bureaus that could convert floppy disks between different systems, and I used some to convert CP/M-86 commercial software for an Altos 586 (my first computer) that had a floppy format not supported by all vendors, which was a common problem when new systems came out. But that was actually between compatible (architecture & operating system) systems.
For incompatible systems (whether 8-bit vs. 16-bit or minicomputer to PC-compatible or anything else), my first choice would be a proper communications program on both systems. My second choice, which I had to rely on quite a few times due to the old system being relatively proprietary - i.e., often customer didn't have access (or had access but not the knowledge) to do anything on the old system except run the application program - was to connect printer output from the old computer to a serial port on the new computer. Then I would run whatever reports I needed to retrieve all the necessary data, typically customers, accounts receivable and open orders, but it would depend on the particular situation. And finally, I would write some conversion routines to get the data into a format usable by the new system. In at least one case, the old system only had a parallel printer port configured (medical billing system, Alpha Micro if I remember correctly) and I had to throw a parallel->serial converter into the mix as well.
Resorting to manual data entry was always an extreme "last resort" due to the inevitable errors in that process.
I transferred a lot of text documents and spreadsheets/databases from my ZX Spectrum to my Sinclair QL using the Sinclair network, a 80kBps serial network that was inbuilt into the QL and provided by Interface 1 on the ZX Spectrum. This network could connect up to 64 QLs and ZX Spectrum. My Spectrum also had to serve as a print spooler for the QL, as I did not have a Centronics interface for the QL to connect it to my printer for quite some time.
The network was compatible between the two machines as Sinclair planned to sell this as teacher/student (or, rather, server/client) setup for classroom use. Even though the ZX Spectrum and the QL used the same microdrives, their format was not interchangeable - Sinclair apparently decided for this incompatibility during the last few months of QL development, in favour to give the QL 20kBytes or so more storage on a cartridge.
When later moving from the QL to the PC, I could use floppy disks, as the QL could be made to be capable to read and write PC floppies with the ATR ("Atari floppy") driver.
on ZX (Zilog Z80) we usually used tape interface (save on ZX) which is a serial link in its core. We sometimes connected 2 ZX by it without the tape to copy data for testing ... It can be also used to move data to new tech like PC by connecting tape output to LPT on PC and using emulator load into it (by using tape load...) Or even save the tape as wav/mp3 and play it in emulator... or use the PC soundcard input.
Latter on with MDOS floppies (ZX+D40/80) we used a floppy file manager (IIRC it was this one MFC but not sure) and format floppy with it on ZX to enable PC usage (as MDOS and PC FDC are not compatible) and then we use the same manager to copy files. The floppy was formated as FAT but using sync markers compatible with booth sides FDC. But this was more like 1990.
On top of that I also created my own FDC (using AT32UC3A0512) which scan the whole MFM data of floppy and send to PC by USB and then on PC I decoded it into floppy images suitable for my emulator but this was relatively recent like 2012 as I decided to convert all of my FDDs (~100) for safe keeping before they got demagnetized after a long time of storage.
Computers in around 1980 usually got directly accessible HW ports (usually done by i8255) which could be used in any way. Was really common to create own custom serial and or parallel links with protocols and everything in Software.
For example on older stuff like PMD85 (Intel i8080 or i8085) we usually used 2 wire serial link done purely on SW (no UART present).
We also used PROMs programmed on one type of computer and inserted as cartridge on a different one.
In the late eighties I was financing my study in computing science as a sysadmin in the CS department. We had a Data General Nova, a lot of Dec Rainbows, and an AT&T 3B2 Unix machine.
We had all of these connected through a locally developed ring network, accessed through the RS-232 serial ports.
Then in 1988 we purchased a couple of workstations and a server from Sun Microsystems, and got ethernet installed shortly after that.
In order to transfer files between all of these machines we used C-Kermit, as it was free, and very portable. It allowed us to transfer files in either binary (bit by bit) or as text.
It was very effective. Throughput with the default settings was abysmal, but increasing the packet size from the default 64 characters improved that quite a lot.
Transporting data between larger machines was often done with magnetic tape. I was tasked with porting a system and the annual updates to various models and manufacturers' systems. The code was in Fortran IV and required very little customization.
The first step in the process was determining the specifics of the tape format the target system would accept. 800BPI/1600BPI, EBCDIC/Ascii, parity requirements (mark, even, odd, none), and maximum block/record size. I had a tape utility which would produce the requisite format on our local system, and I would write the source code and data to magnetic tapes. I would build the applications that built the databases and indices from the tape, run them, then build the interactive application. At the end of each unique installation, I would build a release tape for that system, which we would duplicate on demand for additional compatible machines. Typical first port to a new system would usually take 4-5 days. Annual updates were completed in 1 or 2 days.
Many companies implemented departmental mini-computers such as the VAX running VMS or Unix. This was just one example of an 80s style minicomputer. These were classical big 32-bit systems typically using multiple serial connected terminals like the VT100. There were also 16 bit systems such as the PDP-11. Natively they used hard-disks and hierarchical file systems for storage. However they supported many other formats for storage and data interchange.
One method used was the floppy disk. At least one model of VAX came with an 8" floppy disk drive that was typically used for initial boot media and diagnostics. With some messing around this could be used for copying files to and from the host file system. The disadvantage is that such computers were often remote and kept locked up in a computer room so you had to ask someone with access to do the job for you (always took time).
The classic, already mentioned by others was Kermit, a program using a serial protocol that allowed you to use an eight bit system such as an early 8-bit computer as a terminal and to make reliable file transfers. Kermit had the advantage that there were plenty of free implementations available for different systems.
Many other communication programs would provide terminal emulation but implemented protocols such as XMODEM, YMODEM and ZMODEM for file transfer.
To simplify transfer and to reduce time, usually files were compressed first. This is how format like ZIP started although there were several predecessors.
It was theoretically possible to use other protocols like UUCP, but the programs tended to be rather big in those days and sometimes cost money.
The disadvantage of serial links is that they would be limited by the speed of the communications lines. Again, distance was a major factor, so it was seldom that you would get above 19200 bits per second which would be slowed by the protocol to 1920 characters per second.
People would often do their work on the minicomputer as it typically ran reliably with a properly backed up file system and then use cross compilers to build software to be debugged and run locally on the 8-bit microcomputer.
FTP.
Neworking was around before some people believe.
I was using FTP to transfer data between computers over TCP/IP networks from the early 1980s.
This was reasonably easy between computers on a local network, known in those days as an internet. Access to the wider the Internet was harder to get. Part of my job involved exchanging data with laboratories in the USA. We used FTP transfers both from the HP boxes in the office and from BBC Micros with Prism modems. The latter ran in those days at 300bd, so transfers took a while.
I transfered my Apple II floppies to my Atari TT using the super-serial card in the Apple. I wrote a little program that would load sectors with the RWTS routine and use the monitor to hexdump over PR#1. On the TT a small GFA Basic program would get the data from the serial port, convert the hexcodes to binary and write it in a file. A transfer at 9600 took less than 10 minutes, voilà Apple II floppy image files. It took me few days to transfer all floppies that were worth transfering. Later when I switched to PC and tried Applewin emulator I was quite happy that my image files worked perfectly.
There's two things here. First, where there was a need for ad-hoc transfers Kermit was very popular, supported (in the case of Lowbrow University when I worked there) by a campus-wide Gandalf network.
Second, where there was a need to e.g. create installation media there were commercial boxes which supported all possible types of drive and several OSes (8", 5 1/4" with both hard- and soft-sectors etc.; CP/M, MS-DOS, PC-DOS and so on). When direct transfer wasn't possible, companies such as Grey Matter would fall back to Kermit or X-Modem.
As a variant of the latter, /some/ computers could read and write multiple formats. For example, the Future Computers FX20 and FX30 running CP/M-86 had tables in the BIOS which configured their 800K discs to emulate various other systems... there were various humorous comments in the source from one CPKS including reference to a "bijou subroutinette".
Later on, there were various plugin cards for PCs supported by specialist software, and there were things like Quaid Disk Explorer specifically written to explore copy protection etc.
On minicomputers, not quite the focus of this question, in the 1970s we used post office leased lines to transfer files.
My very first professional project was to implement a remote job entry station, i.e., transfer files (representing cards) to a remote mainframe and transfer files (representing printouts) back.
This was communicating between a 16-bit machine and a 36-bit machine; or, in character terms, between an 8-bit machine and a 6-bit machine.
Implicit in this is the problem of data conversion. But it wasn't really an issue: if you need to connect A and B, then you need to handle data compatibility issues. In my case it was only a matter of character codes.
Using a network is way easier than using disks.
I used Xmodem and variants to transfer to/from my 286 via RS232. I remember that Data General had a program called BLAST although I suspect that it was a wrapper for Ymodem protocol. Not long before that I wrote a driver for 110-baud 20mA current loop to interface a BBC micro to a teletype that I had acquired, which had a paper tape punch. Sadly I was never able to persuade anyone else to get on board and so I was never able to use it for data transfer per se, although technically it would have done the job. It was rather slower than using a cassette tape, but had the advantage that if you dropped your tape in a puddle you could dry and iron it and it would still work.
Everybody has been talking about microcomputers, where serial lines was the best technology for the task.
For larger computers, more professional networks were available.
Ethernet was introduced in 1980 and it was an instant hit. There were also a number of alternatives that lost in competition to Ethernet.
By the late 80's/early 90's a number of competing protocols were in use that worked on top of Ethernet. These allowed file sharing and other network services much like today. Though obviously slower.
However, most of these were vendor specific and could not be used for cross-platform file transfer.
(This is probably a simplification. I am sure there were some cooperating vendors and some cross-platform networking)
Enter the Internet Protocol. IP version 4 was introduced in 1981 and deployed in the international Internet in 1983. We still use IPv4 for most of the Internet though work is in progress to start using IPv6 instead.
IP was developed in part by the US government and in part by universities, and it was an open standard, available to every vendor. This was one selling point, the other being it was scaled for a truly world-wide network with 4 billion addresses. In short, they won.
At some point, PCs became powerful enough to use Ethernet and IP. I am not sure when this happened, but I know I used it in 1991. It was probably possible in the very late 80's.
There were a couple basic strategies I remember employing for migrating data from one PC to another. The simplest of these was just moving disks from one PC to another. For small volumes of data, this could be done with built-in DOS commands (copy, etc.). For larger volumes of data, it was useful to use tools like ZIP and ARJ that could create coherent multi-floppy archive images.
This was actually how I got my first copy of Linux... I found/downloaded disk images using telnet and FTP on my university's lab of 286 PS/2 machines, and then took the images home to install on my personal PC.
For faster and more efficient PC-to-PC transfers, there were also options like Copy 2 PC. In current terms, the best way to think of this is as something like a TUI version of rsync. You connect two machines together, select what you want to copy, press the button, and go. The inter-machine connection was either a null-modem cable or a parallel port link over a custom cable that was shipped in the box with the software. (Certain parallel ports could do, IIRC, bi-directional 4-bit-per cycle transfers that were much faster than a null-modem Serial connection.)
For cross-platform transfers, the generally easiest mechanism was to use a network connection of some sort. This ranged in complexity from a simple null-modem link between two machines, to a modem connection, to full-fledged networking like we know today. For serial links, Kermit was standard, but slow... the BBS community ran through a series of progressively more efficient download protocols. XMODEM was one, but there were also YMODEM, ZMODEM, JMODEM, and others... These typically gained their efficiency by changing buffering paramaters, tweaking the handshaking, adding compression, etc. One other useful feature was the ability to resume a failed download mid-stream. That way, if you had to disconnect the phone line or otherwise lost the connection, you could pick back up where you left off rather than starting from scratch.
I mostly used direct serial connections, sometimes resorting to copying raw text files using BASIC programs. There were also utilities available for reading foreign floppy formats; I believe the one I used was called "Uniform". There was little difficulty with 8 inch floppies, as virtually everyone used the same IBM standard for physical access. By the time PC's came along most 5 1/4 inch floppies were also using the same physical format, requiring only software (like Uniform) to convert file format. There were still some problem devices that used variable speed drives, hard sectors, and different track spacing; those you had to fall back on serial.
Back in the early 1980s, I wrote my dissertation on a CDC Cyber 170/750. 60 bit words, 6-bit characters... which of course meant that it had only upper case letters (and numbers and symbols). Since dissertations don't look good in all upper-case, the typesetting system (using that term loosely) implemented lower case letters with escaped upper case letters, \T\H\U\S\L\Y.
I dumped the final dissertation to a 9-track tape (the kind with the 10.5 inch reel that you used to see in movies that featured a computer in the 1960s). The next computer I went to was a VAX, which of course had ASCII. Someone wrote me a small C program to translate the escaped characters into ASCII lower case characters.
And that's how it was. What an improvement over boxes of punch cards!
Remote job entry was still very popular on large systems in the 80's, and many medium and small systems emulated the various RJE protocols to transfer data via network (sorta). Remote Job Entry was available as far back as the 60's and was very well established. It wasn't particularly fast, with lots of the modems used topping out at 2400 or 4800 baud, but it's not like it was your average fat programs and graphics going back and forth either. I do remember establishing remote networking between mainframes and midrange with a mix of 8/16/32/36 bit words. I remember talking to an Air Force Colonel and he wanted to know what was the fastest way to get new systems releases from Georgia to Utah and California now that they have the new fancy 9600 baud connections. I told him "FedEx".
When I was moving stuff from an Apple IIe to a Mac SE, I ended up wiring the Mac's serial port to a couple of pins on the IIe's joystick port, then using a program that bit-banged serial output at like 300 baud. I used a terminal program on the Mac to capture the stuff to text files.
"Back in the day" I remember trying to transfer code and data via a 300baud modem using a BBS which limited clients to a 45-minute connection time! Fortunately, I knew the "sender" and got him to split it up into workable chunks.
In early nineties, after retirement of mainframe computers in Czechoslovakia, there were many powerful drum printers left in our computing center.
If someone is interested how we managed to print files from IBM PC-XT on mainframe printers, we used ECPrint.
Sometimes, I used the ten-finger cables (ie retype), but for the most part, the 8-bit computer did its deed, and there really wasn't worth the effort to copy these things. REXX does most of what rombasic did, and a program i cobbled together around rexx, did in the time it took to take a sip of coffee, sixty times what I had done in two years.
The 8-bit machines were mostly (in numbers at least) used non-professionally for home use. I found that most of the files from those machines found their way onto bulletin board systems. Much of that has been archived at http://textfiles.com/bbs/
