41

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?

  • 8
    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 May 27 '18 at 13:15
  • 18
    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 May 27 '18 at 19:55
  • 8
    laplink anyone? – PlasmaHH May 27 '18 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 May 28 '18 at 3:28
  • 5
    RS232 9600 baud 8N1. " beee brrrr brrrrt .... beeeeeeee" – Tommylee2k May 28 '18 at 7:31

20 Answers 20

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

  • 1
    the parallel port was also sometimes (ab)used, but only among some systems. – Tom May 28 '18 at 17:49
  • 2
    Kermit also had a kick-ass terminal emulator and scripting support. – EvilTeach May 28 '18 at 22:49
  • @Tom I once had a Ethernet adapter that interfaced with the parallel port. PLIP driver and everything. – Thorbjørn Ravn Andersen May 29 '18 at 23:08
21

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 May 27 '18 at 14:53
  • 1
    Another widely used program for file transfers over serial connections was "Kermit" – Brian Borchers May 28 '18 at 17:10
  • Kermit for me too. – Laconic Droid May 29 '18 at 3:35
  • Wow what a blast from the past! – Mehrdad May 29 '18 at 4:18
18

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 MSDOS 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 May 28 '18 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 Jun 11 '18 at 21:54
  • Sold well from what I heard. – Michael Karas Jun 11 '18 at 22:27
17

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.

  • 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 May 27 '18 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 May 27 '18 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 May 28 '18 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... – a CVn May 30 '18 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 May 30 '18 at 10:42
12

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 May 27 '18 at 18:39
11

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.

7

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.

6

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.

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

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.

1

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.

Until 1988, when we purchased a couple of workstations and a server from Sun Microsystems we had of these connected through a locally developed network, accessed through the RS-232 serial ports.

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 out of the box was abysmal, but increasing the packet size from the default 64 characters improved that quite a lot.

1

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 May 29 '18 at 12:37
1

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.

1

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.

0

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.

0

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. – Will Hartung Jun 6 '18 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 Jun 8 '18 at 9:25
0

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

-1

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 May 28 '18 at 10:31
  • I remember one course in 1985 or 1986 at the University of MD programming Ethernet for message passing between IBM ATs. – manassehkatz May 28 '18 at 21:31
-1

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/

-1

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 May 30 '18 at 18:30
-1

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.