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?

  • 9
    Big companies would often print out reams of information and pay menial staff to sit in a room copying the data from one system to the other.
    – Valorum
    Commented May 27, 2018 at 13:15
  • 20
    It wasn't as much of an issue as you are likely thinking, simply because raw data transferred between systems was usually unusable anyway. Not just disk formats, but virtually all application file formats, were not directly interchangeable. And most popular applications were still platform specific, not cross-platform. If you had application data files that you really needed to port over, then you developed a particular strategy for the particular applications' data. In those early days, THIS was the main driver for emulation software being developed and sold.
    – Brian H
    Commented May 27, 2018 at 19:55
  • 10
    laplink anyone?
    – PlasmaHH
    Commented May 27, 2018 at 21:17
  • 3
    In 1986 I was working for a company installing Novell networks, and I had installed Corvus Omninet networks before that. We used networks to copy files between different systems. In the late '70s and early '80s, we used modems.
    – Ron Maupin
    Commented May 28, 2018 at 3:28
  • 5
    RS232 9600 baud 8N1. " beee brrrr brrrrt .... beeeeeeee"
    – Tommylee2k
    Commented May 28, 2018 at 7:31

26 Answers 26

  • 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.

  • 2
    the parallel port was also sometimes (ab)used, but only among some systems.
    – Tom
    Commented May 28, 2018 at 17:49
  • 3
    Kermit also had a kick-ass terminal emulator and scripting support.
    – EvilTeach
    Commented May 28, 2018 at 22:49
  • @Tom I once had a Ethernet adapter that interfaced with the parallel port. PLIP driver and everything. Commented May 29, 2018 at 23:08
  • I used Norton Commander Link with a parallel port cable (official yellow one) and this was acceptably quick and very reliable but that was on two 16-bit systems. Commented Nov 14, 2020 at 2:19
  • 1
    @ThorbjørnRavnAndersen xmodem is essentially just "send a CP/M file block … receive a CP/M block": great for small files and small computers, but a bit slow for faster machines.
    – scruss
    Commented Nov 18, 2020 at 21:59

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.

  • 2
    I only copied some 8-bit stuff much much later, once there were decent emulators on more current hardware. I was surprised the 5.25" floppies were still mostly readable.
    – Joe
    Commented May 27, 2018 at 14:53
  • 1
    Another widely used program for file transfers over serial connections was "Kermit" Commented May 28, 2018 at 17:10
  • Kermit for me too. Commented May 29, 2018 at 3:35
  • Wow what a blast from the past!
    – user541686
    Commented May 29, 2018 at 4:18
  • The kermit distribution came on two reels of mag tape. You had to find the implementation for the two machines, some how load them on to the machines and that was it. It was really impressive - they had implementations from CP/M to Commodore, right through to VAX, CDC and lots of machines I'd never heard of.
    – cup
    Commented Nov 18, 2020 at 11:57

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:

  1. We burst the fanfold paper into separate sheets so we could make a backup photo copy of the data.
  2. We sent the paper stack to an OCR vendor to scan and convert to files on MS-DOS floppy disks. Note that this step was expensive because simple scanning and OCR technology was not mainstream at the time and uses sophisticated hardware. I seem to recall that the OCR house was paid some 3 to 5 USD per sheet.
  3. I got the raw ASCII text files off the floppys and merged them in the correct order onto a computer HDD. As I recall there was one file per OCR scanned sheet.
  4. I then wrote a first stage filter program that scanned the large ASCII text file and removed things like page headers, blank lines and page numbers. It required iterative development to add heuristic algorithms to deal with variations between sheets and special odd corner cases. The result of this stage was a file that had one line for each inventory record in the original listing.
  5. Then a second stage filter process was made to convert the raw ASCII text data into a comma delimited text file. The original listing had something like twenty or so fields per inventory record. Once again a whole slew of heuristics were applied to the filtering activity. Some examples of things that had to be done were to realign columns of the OCR scanner was not correctly aligned to the page. Another thing was to look for things like "B" characters in fields that were known to be numeric and convert to "8". I recall that there were about 45 or 50 rules that were created in the filter program to deal with OCR type errors.
  6. Finally the resulting comma delimited data was imported to a dBase database file that the customer could use on his computers.

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.

  • 3
    TL;DR: Good old-fashioned paper. :-)
    – wizzwizz4
    Commented May 28, 2018 at 8:00
  • Outstanding operation there - I hope the rest of the project went well, did the equipment sell or end up as scrap?
    – PhasedOut
    Commented Jun 11, 2018 at 21:54
  • Sold well from what I heard. Commented Jun 11, 2018 at 22:27
  • Since this is retrocomputing - I am aware of a slightly cheaper method being used to reconstitute old software from paper listings. Scan the listings as images (usually old LP printouts do not OCR well, and besides we want the code only, not all the assembler output). Get as many people as you can enlist to type the listings into a computer. Have someone compare the typed-up copy against the original. For faster convergence, have redundant copies typed that you can compare. Requires highly-motivated people. (Best when you have typists that understood the original system).
    – dave
    Commented Mar 11, 2020 at 12:47

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.

  • 1
    I don't know about adapters for floppies, but there were floppies that adapted. I.e. the Amiga and the Atari ST could r/w msdos floppies (3.5" 740k) in addition to their native formats. Also the Commodore 1571 drive, introduced with the C= 128, was a fast version of their old 1541, and it could handle multiple 5.25" cp/m formats. I don't remember if it could also handle msdos. Various flavors of Unix typically handled multiple disk formats as well.
    – RichF
    Commented May 27, 2018 at 12:41
  • 2
    We didn't because it wouldn't run anyway, +1... Before the games were all online I hadn't played Karateka in almost 20y.
    – Mazura
    Commented May 27, 2018 at 18:21
  • 2
    @RichF: Adapting existing floppies to read or write foreign formats is really difficult and in most cases impossible if the formats are substantially different. And I'm talking flux encoding (FM/MFM/GCR with the odd "funny byte" for sync etc) here, not the differences between CP/M directory layout, Unix layout, and DOS 3.3 or whatever layout - that's (more or less) trivial to handle.
    – dirkt
    Commented May 28, 2018 at 10:28
  • "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." Something tells me that much source code written on, say, an Apple II or C-64 or ZX81 wasn't of much use on an IBM PC compatible or a Macintosh. Certainly anything non-trivial would need major adaptations to run on a new platform, and that's before even mentioning how to get it to run with decent performance. I can imagine basic BASIC code might transfer without too much hassle, but that's not the kind of code you'd typically compile...
    – user
    Commented May 30, 2018 at 10:35
  • 1
    @MichaelKjörling: Pascal source from UCSD Pascal or Turbo Pascal (Apple II with Z80 card and CP/M) transferred to run under Turbo Pascal on the PC didn't need that much adaption, and that was the bulk of it.
    – dirkt
    Commented May 30, 2018 at 10:42

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.

  • 1
    tl;dr: By a professional who knows how to "write some conversion routines" - the rest of us had to buy The White Album again.
    – Mazura
    Commented May 27, 2018 at 18:39

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.

  • 4
    USB … in the late 1980s?
    – scruss
    Commented May 27, 2018 at 22:42
  • 3
    mp3 ... in the late 1980s? ;-) Commented May 28, 2018 at 7:17
  • @scruss of coarse not but you can use it for the tech from 1980 today :)
    – Spektre
    Commented May 28, 2018 at 7:27
  • @StéphaneGourichon I eddited it a bit to make more clear what was done when :)
    – Spektre
    Commented May 28, 2018 at 7:36
  • @Spektre nice pile of hacks. :-) Commented May 28, 2018 at 9:58

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.

  • 1
    We wrote a data entry program in Turbo Pascal, and then we'd use Crosstalk to upload the file to our VAX. We would simply COPY CON: WORK.DAT (or whatever the console device was), and then XTalk would shove the file up. The problem was that our data entry program was a bit too generous on the characters it allowed, including ^C. So, uploading a file with that typo immediately failed. We obviously cleaned up the DE program, but was an amusing incident nonetheless after trying to upload a file 2 or 3 times. Commented Jun 6, 2018 at 16:37
  • Terminal input on these systems was designed primarily for VDUs with a rich set of actions depending on control characters. Straight ASCII was little problem but otherwise you had to switch the terminal into a "no interpretation mode"/raw mode (set tty/passall) which programs like Kermit would do automatically. The mode would be restored when the transfer ended. The problem was when the program hung and then you had to force a reset by reconnecting.
    – hughk
    Commented Jun 8, 2018 at 9:25


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.

  • Patrick, if you still have the GFA Basic code, I would be very interested as I am trying to send stuff to an Atari ST via rs232 and all I have is GF Basic floppy and no floppy drive.
    – guax
    Commented Feb 7, 2021 at 14:15
  • Sorry. I did that more than 25 years ago. While I still have my Apple II+ clone and my Atari TT I do not have the software anymore. I lost the harddisk of the TT 20 years ago. I might have a backup on DDS2 tapes but I will have to restore the tape drives and the TT before. Commented Feb 8, 2021 at 8:58
  • No problem, it's been a good challenge to try to write my own. Been fighting control characters and now link reliability and buffer sizes. I'll eventually get there, its better this way as I am learning a lot from the experience.
    – guax
    Commented Feb 9, 2021 at 9:09

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 was more interested on data transfer between two computers placed immediately next to each other: If I was using a C64 before and switched to an Amiga - just as an example - and I wanted to transfer some of my "old" data (stored on 1541 disks) to my new computer. Commented Nov 18, 2020 at 12:17

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.

  • 2
    Do larger computers count as the "8-bit" mentioned in the question? I'd be surprised if a larger computer was really 8-bit. :-)
    – dirkt
    Commented May 28, 2018 at 10:31
  • I remember one course in 1985 or 1986 at the University of MD programming Ethernet for message passing between IBM ATs. Commented May 28, 2018 at 21:31

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.

  • Wasn't the question about migration toward PCs?
    – Raffzahn
    Commented May 29, 2018 at 12:37

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!

  • Welcome to Retrocomputing Stack Exchange. Please read the tour. This answer does answer the titular question, so I won't delete it; it does however need some editing to make it suitable for this site.
    – wizzwizz4
    Commented May 30, 2018 at 18:30

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/

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .