Transferring programs TO a TRS-80

For years, I owned a TRS-80 Model IV two-disk system. I purchased it in the late 1990s at a community yard sale for only $25. Since then, there was little I could do with it. All I had was an L-DOS 6.3.1 boot disk. If all I wanted to do was format floppies, or type in the occasional BASIC program, then I was golden. Otherwise, I had no (cheap and convenient) means to get existing TRS-80 software transferred to a TRS-80 disk format so I can use it on the computer… until recently.

Many other classic computer systems have an easy means to transfer programs to/from a PC. This is useful for emulators and those who would like to try original programs found in archives on the Internet on a REAL classic computer. Commodore computers, for example, can have their disk drives connected to a PC using a relatively cheap special cable and write entire disk contents to a real floppy disk. For that matter, real floppies could be backed up to a disk image on a PC. There are many solutions for the latter for TRS-80 computers, but transferring file TO a TRS-80 from a PC isn’t so easy, nor appears to have been readily researched.

As far as I know, there are no other tutorials for this particular TRS-80 file transfer need. There are plenty of solutions for transferring TRS-80 files and programs TO a PC, but not FROM a PC, unless you want to invest monies into hardware solutions that may require you to disassemble your TRS-80 and/or PC to make it work. When the discovery of a TRS-80 DOS command I was not familiar with surfaced during one of my routine online romps around the collector’s scene, the solution to my dilemma came to mind. Read more for all the gory details…

At my disposal were the following items:

  • TRS-80 Model IV (w/ RS-232 port)
  • Modern PC running windows 7 (and having no serial port)
  • USB to Serial adapter
  • Laplink cable (for you newbies, Laplink was once a popular file transfer system which moved files through their included null-modem “Laplink cable”)

You may substitute your own cabling solution to connect the two computers together, as long as it’s equivalent to a null-modem cable. The first thing I needed to do was get the two computers talking via the null modem (aka Laplink) cable. To do this, I needed to install and configure my USB to Serial adapter as a low numbered COM port. A lot of times, these devices get assigned a two digit COM number like COM16 or something. I reconfigured the port in the Windows “Device Manager” to set it to COM3. I felt a low COM port number would work best with most terminal communications programs (like we used in the old days).

Once I had the PC and Model IV connected, I needed to test the connection by establishing two-way communications between the two. On the PC, I thought I’d use HyperTerm, but it has not been included by default in Windows 7, unlike earlier versions of Windows. The only way I could get HyperTerm now is if I buy it. Forget that!! Instead, I found and downloaded Tera Term v4.73 ( It has the features I need to transfer files directly through the serial connection.

Now that I have the PC side ready to communicate, it’s time to configure the Model IV. The Model IV has a rudimentary means of communication using the Communications Line device (known as *CL), SETCOM (for configuring communications parameters, and COMM (which provides the terminal interface). This procedure was only done on in LDOS, but it should also work with TRSDOS. The following steps need to be done, in order, so that file and data transfers can be initiated.

First, the *CL device needs to be configured by assigning it to a driver. On the Model IV type:

SET *CL COM/DVR  <Enter>

This sets the COM driver to the *CL device. If you get an error like, “Driver not found”, make sure the COM/DVR file is on your TRS-80 DOS disk. Next, the communications parameters need to be configured. NOTE: I tried so many different parameter configurations that I never bothered to check and see what would be the minimum amount of parameters I can get away with. So I may be “over configuring” the communications port with these values. Regardless, the values I used worked fine for me. Type:


The SETCOM command allows you to set many of the popular RS-232 communications parameters. Some parameters missing from the above statement might also be important parameters, but are already set as required by default. The command above changes certain default values to the desired ones. After the command is entered, we are left with the following configuration values:

  • Baud: 300bps (I’ll explain the slow speed later)
  • Word: 8-bit
  • Stop Bits: 1
  • Parity: None
  • RTS/CTS (a form of flow control): ON and ON
  • DST/DSR (another form of flow control): ON and ON

I used 300 Baud for one reason; because I spent many evenings enduring failed transfer attempts over several weeks trying to get this procedure perfected!! I tried all sorts of baud rates and other settings, coming close to perfecting a clean transfer of at least ONE useful CMD file which I could successfully run. However, I eventually discovered that the above settings are the most stable. 300 baud is extremely slow, but I only need to run this particular procedure to get one specific file transferred. After that, I can ramp up the communications speed. But I digress, I’ll get to the details in a bit.

Now that the RS-232 port is configured, I needed to run the main communications program, called COMM. The COMM program opens up a terminal interface where you can type and receive text to/from a connected computer. In this case, the PC is that other connected computer. To start the COMM program, type:

COMM *CL   <Enter>

This will launch the terminal program. First, you’ll need to understand how the program operates. After you run COMM, if you launch the terminal program on the PC (I’m using Tera Term) and set the communications parameters to match those set by SETCOM above, everything you type on the Model IV should appear on the PC terminal screen, and vice versa. This is an easy way to test communications. If you cannot see the text you type on the PC appearing on the Model IV, then the transfer process will not work. Please check your configuration before continuing. Also note that there is also no need to clear the screen of the text you’ve typed in to test the connection. Everything involved with transferring data files is done between the moments you start and stop the transfer program, regardless what’s on screen at the time.

My goal in this endeavor was to provide myself with an efficient means of transferring files. Simply using the COMM program isn’t enough, but it’s a starting point to transferring a special program which I found more efficient. The whole purpose of this exercise is to get that special program file onto a TRS-80 formatted floppy. You need to keep the following fact in mind:

The COMM program WILL ALMOST ALWAYS DROP DATA because there is no data checking or checksum capabilities in the program!!

That is the humbling part of the process, and the reason why I worked myself into frustration until I discovered a useable solution. Many of my file transfers would lose characters here and there, but I didn’t realize this for a long time because I had no easy indication of the issue. Characters from CMD files which I’ve tried transferring to the Model IV are in binary format, so I cannot tell if any data has been dropped. All it takes is one character to drop off in the transfer to render a CMD file inoperable. I had only one success in the past few weeks, but that success was not repeatable. I found that I needed to transfer an ASCII file (text file for you newbies) instead. That way, I can spot missing data as it gets transferred, or at least be able to correct the file manually.

The only type of text file which I thought would be useful was a BASIC program. If I find the right BASIC file, I will be able to easily monitor the transfer and check for errors, plus the program will do something useful in regards to performing more efficient file transfers. The BASIC language in LDOS (and perhaps TRSDOS) loads text files to load program content. I found the perfect BASIC program to transfer. It’s a BASIC program which reads from a collection of binary code stored in DATA statements and “builds” a working CMD file on disk. The BASIC program I chose creates a file called XMODEM/CMD on disk. With the XMODEM program, I can replace the COMM program for file transfers. XMODEM is an ancient (by today’s standards) means to transfer files over an RS-232 connection, but is perfect for transferring files from a PC to a TRS-80. XMODEM is also able to manage the transfer of data between two computers by correcting any errors or lost characters which occur. That way, all transfers are perfect copies, even for CMD files.

You can find the BASIC program here:

If you open the archive, you’ll find a file called XMDM2412.BAS inside. Save this file somewhere on your PC. If you’re curious, you can look at the contents of the file in Wordpad or other text editor (it won’t look right in Notepad).

Now back to the COMM program…

Navigating around the COMM program is a bit archaic. All commands in the COMM program involve selecting a function, then either  setting its value, or turning that function on or off. Get used to using the <CLEAR> key on the Model IV. In the COMM program, the <CLEAR> key acts like a CTRL or ALT key on a PC as it’s used in combination with another key. With the COMM program running, and the XMDM2412.BAS file ready on the PC, we need to start the file receive process on the Model IV. All keypresses in the following steps will be indicated in angle brackets “<>”, and combination keypresses will be separated by a “+” symbol, which means, press and hold the first key then press the next key, etc.

To capture data in COMM, we need to initialize the “File Receive” function. Press the following key sequences:


You will be prompted for a filename. Enter


followed by <ENTER>. The TRS-80 uses a slash “/” symbol like the PC uses a period “.” to separate the filename from the file type. The “:1” portion of the name above tells COMM to save this file on the disk in Drive 1. If you’re working on a single disk system, or have more than two disk drives on your Model IV, change the number after the colon to whatever drive number you are using.

Next, the “File Receive” function needs to be “opened” so that it will start capturing data sent to it by the PC. To start the capture process, press:


At this point, all data coming from the PC will be captured, so try not to type any text on the PC until the file transfer is completed. To start the file transfer, go to the PC (you have Tera Term running already, right?) and choose Send File… under the File menu. Find the XMDM2412.BAS file you extracted earlier and send it. Look at the TRS-80. You should now see the file contents appear on the screen. You may notice why I recommended 300 Baud for the transfer. First, it doesn’t take too long for this file to transfer, plus, the transfer goes slow enough that you may see indications of dropped characters. If you’re familiar with the structure of a BASIC program, you should spot dropped characters quite easily. This file being transferred has many numbered lines of text. There are also many DATA statements in the file. Other than a few of them, these DATA statements are all the same length. You will notice if characters get dropped because the DATA statements suddenly don’t line up anymore.

I want to step aside for a moment and mention a quirk (or bug) I’ve discovered at this point in the process. This may not happen to you, but I found that it is completely repeatable with my system setup. If, during the transfer of this file, you find your disk drive occasionally turning on and off, I guarantee you will be missing data. Even at 300 Baud, the disk writing process interrupts some of the data being transferred. What’s happening is, the transfer is being saved directly to disk. This is a bug in the process because at this point, we did not yet turn on the “dump to disk” process which saves the transferred file contents to disk. We only turned on the capture process which is only supposed to transfer to memory. I found this bug occurs ONLY during the first transfer I perform each time I run the COMM program. As long as I stay in the COMM program all subsequent transfers behave as expected and go right to memory as they are being captured. This is important to keep in mind. The solution to this “bug” is easy; once all the following steps have been completed, simply restart the capture process again, starting with initializing the “Data Receive” function mentioned earlier in this tutorial.

Now back to the transfer process…

After the file completely transfers, you’ll need to turn off the capture process on the TRS-80 by pressing:


Then, you need to save the capture buffer to disk by pressing:


and finally, close the capture file by pressing:


As mentioned before, if your computer started running the disk drive DURING the transfer, you’ll need to go back and repeat the steps to ensure a clean file transfer. There should be no disk activity on the TRS-80 while the file is being transferred. The disk should only run when you first create the capture filename on the TRS-80 and when you save/close the capture buffer.

You are now done with the file transfer. You can exit the COMM program by pressing:


Back at the TRS-80 DOS prompt, type:

DIR :1   <Enter>

to see if the file you transferred is there. I will continue to use “:1” in my examples throughout this tutorial. Substitute the appropriate drive number after the “:” above if you used a different disk drive. If the file XMDM2412/BAS doesn’t exist, you can try transferring it again by repeating the steps above, starting with running the COMM program.

Next, we need to run the BASIC program file we transferred. Type:

BASIC XMDM2412/BAS:1   <Enter>

This will load and run the BASIC program. If all is successful, you’ll see a bunch of “<DATA>” text on the screen while the disk drive is operating, then ending with two checksum numbers on the screen when done. If these checksum numbers match, everything was a success. Take a look at your disk directory again:

DIR :1   <Enter>

you should see a program called


From now on, the COMM program is unnecessary. You’ll still need to use the SET and SETCOM programs to initiate the RS-232 port after restarting your computer, but you’ll be able to substitute higher Baud rates now (I’ve tested speeds up to 9600).

To transfer files from your PC with XMODEM, use the Transfer / XMODEM / Send menu item under the Tera Term File menu on the PC. You will be prompted for a filename. Choose a TRS-80 file to transfer and send it. The XMODEM transfer on the PC will now wait for the TRS-80 to initiate the receive side of the transfer. Note the filename you picked on the PC. You will type it in on the TRS-80. For example, if you chose OMNITERM.CMD on the PC, you would type the following on the TRS-80 to initiate the XMODEM receive process:


This will start a receive (“R”) process to transfer the file OMNITERM/CMD (remember the slash) to drive “:1”. Depending on the size of the file, the transfer will pause on occasion while data is saved to disk. This is OK because XMODEM transfers support a waiting period AND error correction while data is being written to disk. The COMM program lacked these important features.

One thing to note is that TRS-80 emulator files often come in DSK or DMK format. These are “disk images” for use on an emulator. You cannot transfer these types of files to a TRS-80 using these means and expect them to work properly. You’ll need to use a program which extracts the files from the disk image on your PC, THEN transfer them individually to a blank formatted disk on the TRS-80. If someone knows how to handle entire disk images directly on a TRS-80, please let me know!

Using the above process, I have transferred many CMD and BAS files, games, and utilities to real TRS-80 formatted disks. My Model IV is now a useful exhibit in my collection of classic computers!! 🙂

I hope these instructions will help others get better use out of their TRS-80 computers.

26 Comments on “Transferring programs TO a TRS-80”

  1. Thank you, that was a great article. Ever since I got a model 4p, over a year ago, I’ve been scratching my head how to move software onto it. I have an old Pentium box that I was going to run an emulator on and write the disks, but this should be more manageable. I hope my 4p has a serial port, otherwise I might scream. 🙂

    1. Thanks! Just doing what I can to help collectors in their preservation attempts. 🙂

      I’m glad to hear that the transfer technique is useful to others. Let us know if you are successful with your data transfers.

  2. Hi – am trying to get this to work with a PC running Win7 and using the serial port on the PC (it’s a 2005 DELL D610 laptop).

    I can’t get any text to appear on the TRS-80 screen when I type in TeraTerm.

    Have made sure all the setting are correct, but just can’t get them to talk. Any troubleshooting suggestions most welcome!


    1. Hello John,

      Please bear with me. I’m not familiar with your current Teraterm settings, so I’m going to be asking some rather obvious questions. If anything, those questions might help others who reference this article in the future.

      Are you able to type on the TRS-80 and see the text appear on the PC, but not the other way around?

      If so, then it is a strange problem. I find that if one can talk to the other, then both can talk to each other. If that’s not the case, you may want to try changing the “duplex” or “echo” settings in Teraterm to see if that fixes it.

      Assuming that neither of them can talk to each other, I would suggest verifying the nature of your connecting cable and make sure it is truly a “null modem” cable. Plus, if you’re using an adapter of some sort with your cable, make sure that it is also not a null modem adapter. Two null modem devices would basically cancel each other out.

      You may also want to check the serial port settings in Teraterm, in particular, the “flow control” settings. Try the various settings; None, Hardware, Xon/Xoff, etc.

      I’ll need to set up my TRS-80 and PC connection again to verify my settings. Unfortunately, I’m unable to do that at the moment, but I will look into it.

      Another thing you can try, in order to test your serial cable, is to temporarily make it a “loopback” cable. But I must make an important disclaimer to, “DO THIS AT YOUR OWN RISK!!!” If you pull the serial connector out of ether computer and connect pins 2 and 3, on the CABLE CONNECTOR you just pulled out, using a wire of some sort, you should be able to type on the machine still connected to the other end of the cable and see everything being typed echoed back to you.

      Once again, I only recommend testing the cable that way as a last resort. I would suggest trying a different cable first, or connect two PCs together, both running Teraterm, to verify that the cable is working properly.

      I didn’t have to make any major changes to Teraterm when I used it. I only made serial port changes (300 baud, 8N1, flow control “none”)

      Are there any more details about your configuration that you can share with me so that I can help troubleshoot the problem better?


  3. Jeff,

    Thanks for the prompt response. I get no text from either computer on the other computer. Also, in Teraterm, when I type, nothing displays on it’s screen.

    I bought the cable recently, and it’s supposed to be a null modem cable, but perhaps it’s not. Am going to try another cable before I try anything else.

    I had started with the same TeraTerm settings that you mention above, and had tried changing the flow control etc, but this made no difference.

    Thanks for the advice though – I’ll let you know how I go.


  4. Jeff,

    Resolved the problem. I replaced the UART chip on the motherboard of my Model 4. Files now tranferring happily across to my TSR-80.

    Now just need to find some good 1980’s software to use on it!

    Thanks for your responses.


  5. Thanks for the great write-up and video. I was able to set up communications and get the xmodem BASIC program transferred and it ran OK with good checksum. Now, when I try to transfer another program using the XMODEM R command, I get a “Load File Format Error” message. I’m using Hyperterm at 2400 baud, Word=8,stop=1,parity=none. I’ve attempted with Xon/Xoff, Hardware and None as flow control options with the same results. Any idea what I’m doing wrong?

  6. PROBLEM SOLVED: I had changed my first attempt of running the program to put the xmodem/cmd file on drive:0 and it had errors. I reloaded it at slower baud rate (110) and re-ran it. It put the good file on drive :1 since I didn’t tell it otherwise. When I was trying to run it, it was seeing the bad file on drive :0. When I removed it, all is well. Thanks for looking anyway.

  7. I have sent the file several times through a cable that connects my COM1 to the parallel interface on my TRS-80 M4. Each time I initialize a save command (key combo) it does absolutely nothing. The file exists and is blank. Any suggestions? I am using TRSDOS 6.02, the only version I have access to.

    1. I must be competing for top number of comments here, but either way, I need help so I’m gonna post one more time. Even though pins 2 and 3 are crossed, my cable doesn’t work even between two PC’s. It is a parallel to serial cable. My desktop doesn’t have a parallel, and well of course the TRS80 does. What might I do about the cable? Either way, I left two other comments and I am hoping someone can help me.

      1. Sorry for the five day late response.

        The process won’t work via parallel connection. The protocols are incompatible.

        I’m not familiar with the stock configuration of TRS-80 Model III or IV. It might be that mine already had a DB25 serial connection, where some were added as options. After looking at some online resources, it seems the standard connector is the the “edge card” connection, which requires a different kind of cable to convert it to a DB25 pinout.

        Also (and I haven’t verified this personally) there is the possibility that there is no serial port present IF you only have the single disk drive version (Catalog Number 26‑1068) of the Model IV.

        The two disk drive version has catalog number 26‑1069 and is supposed to be the only version that came with RS-232 serial built-in and not as an installable option.

        1. Thanks so much for your reply, but today I solved my problem! It was a problem with the cable. I just routed it through a 25-pin (parallel) null modem, then through a diagnostics (LED display) box and sure enough it was all talking. I got the files transferred to begin sending software to disks.

          1. Maybe I might ask another question now… haha. Why won’t my TRS accept anything over 300 baud? It says something like “invalid parameter” for any other number including the standard 9600. Any idea? 25 bytes per second is getting old. At least it’s getting old slowly. Very, VERY SLOWLY.

          2. Good lord… so it did finally set to 9600 this time around and now the file won’t run that I am sending. I am transferring the DAT file for ZORK. I also tried ZORK3. The TRS reports “Cannot boot model-4 DATA DISK” and does nothing. Do I need to mark disks as bootable or something?

          3. You may want to make sure Zork is not a Model III game. If it is, you’ll need to find (and transfer) the GO/CMD program. That can be used to launch Model III games on a Model IV. Just put a copy of it on whatever games disks you create. Simply pass the name of the game (program) to runn in Model III mode as a parameter for the GO command. If the program you need to run is called ZORK/CMD, launch it this way:

            GO ZORK/CMD

            Some Model III games might be named with a “III” extension, like ZORK/III. In that case, use:

            GO ZORK/III

            GO can be found here:

          4. Yes, using the I/CMD file that came with the disk, I was able to start all 3 zorks from the same /CMD by executing “I/CMD ZORK/DAT” or ZORK2/DAT etc. Works like a charm. Thanks for the help.

  8. Question, I have been trying to use your guide to dothe same thing on my TRS-80 Model III. I am able to get as far as transfering xmodem via lcomm and that works great. but when I try to do the xmodem transfer, I get an error on the TRS-80 that says no carrier detected!!! I thought maybe it was my cable , so I ordered an actual laplink cable. Same thing,,,,, I must be missing something, any advice?

  9. First, what a great instructional article! Now for my problem. I can successfully communicate between my laptop PC and my TRS-80 Model 4P using XMODEM. I have been attempting to send ASCII /FIX files and find that the received file (the one now stored on the TRS-80 floppy) has extra blank lines.

    Original Received
    line 1 line 1
    line 2
    line 3 line 2
    line 4
    line 5 line 3

    line 4

    line 5

    Any thoughts or suggestions? Test simply typed into Hyperterm from the PC displays properly on the TRS-80 and vice-versa.

    Again, thanks for a great tutorial.


    1. I’m glad to hear that the transfer process is working out for you.

      Are you also using Hyperterm to do the ASCII/FIX file transfers? Try sending a TRS-80 program COM file using the same terminal program and see if it runs successfully on the TRS-80. If it does, I’m guessing that one of the terminal programs between the two is purposefully inserting line feed or carriage return codes.

      Are you transferring the ASCII files as text files or binary files? If there is a “text file” mode being used, it might be inserting line feeds. “Binary file” transfers do not modify the file content at all, but will still be able to transfer text files verbatim.

      The third possibility might be, are you transferring original TRS-80 ASCII files to the TRS-80, or are they ASCII files originally created on another platform. Those might have line feed characters that are ignored in DOS/Windows, but are represented on a TRS-80.

  10. WOW, you are fast! Yes, I am using Hyperterm to do the file transfers. The text file is stored as a Windows 7 Name.txt document. I have tried pasting the file through Hyperterm using windows-copy/Hyperterm Paste to Host with several missed characters, strange characters, etc. I’m not sure how to go about transferring these text files as pure binary. I also made sure that I am not using local echo, not appending line feeds to eol characters, etc.
    One thing I have not tried yet is to reduce the baud rate. I’m using 2400 with xmodem and no problems. Maybe going down to 300 will allow the paste function to work with the COMM utility.

    1. Great to meet you, too. Thanks for your input! When I was trying to bootstrap my Model IV, I was also trying to teach myself something new at the same time. I get a lot of satisfaction with these vintage systems by doing so.

      COMM was one of the first programs in DOS that I read about that looked like it could work, so I moved forward with it.

      I like the ROUTE idea. I never knew about that program. I guess I was too hasty to get started before reading the entire DOS manual. LOL. Your idea does work better to save a step or two. Great solution you have there.

  11. Great article! I followed your mirror video (with the only difference being that I used TRSDOS 6.2 instead of LSDOS) and everything worked like a charm! XMODEM worked great, and I transferred Fast Term ii to my Model 4 with no problems! 2 bad things about Fast Term, though: (1) I haven’t been able to successfully transfer programs from my Model 4 to my PC (using TeraTerm), either with X modem or Y modem. I either got errors, or in one case, it would just simply stop. (2) I don’t have anything else to download from my PC to my Model 4! While there are loads of disk images out there, there are very few single files to transfer, or at least none that I could find. What can I use to extract the files from the disk images?

Leave a Reply