dos serial file install

(or, how to get that no-software/no-floppy-drive laptop going...)

the problem

I recently bought a used laptop off of eBay. One of the features I insisted on having was a CD-ROM; as things turned out, the class of laptops I was looking at required a choice: CD-ROM or floppy. Who ever uses a floppy drive anyway?

So, my shiny not-so-new laptop arrived, with the CD-ROM and sans floppy. Armed with the latest bootable RedHat CDs, I set out to set up and configure the machine. With disc 1 in the drive, I turned on the machine; the Windows 98 startup screen appeared, and then a DOS prompt. Apparently, the previous owner had removed everything from the hard drive but COMMAND.COM. No problem, I thought, the BIOS is probably set to boot from the hard drive.

As it turns out, the BIOS was set to boot from the hard drive, but there was no setting for booting from the CD-ROM. DOH! So I had a nice laptop that would happily boot to a dos prompt and do nothing else; since there was not a CD-ROM driver on the hard drive, I couldn't even access the CD.

the idea

Having started my computer life back in the pre-Internet days, I am somewhat familiar with serial ports and modems, so I decided to see what I could do with the machine. After digging around for information and trying seemingly endless combinations of commands, I finally got a program transfered onto the laptop. If you're in a similar situation and want to try what I did, read on!

standard disclaimer

These pages are provided as is, solely to describe the procedure I used to install an application on my laptop. I hope that this information will prove useful to you, but I cannot be responsible for the accuracy or completeness of this information nor for any havoc you may wreak on your machines, yourself, your spouse/pets/children/neighbor, etc. BY READING FURTHER, YOU ACKNOWLEDGE AND ACCEPT THIS DISCLAIMER AND ACCEPT RESPONSIBILITY FOR WHATEVER HAPPENS TO ANY MACHINES YOU ATTEMPT TO REPAIR.

background & theory

This document assumes a basic working knowledge of the serial communication hardware found on most x86 pc systems.

This is what I started with:

• Toshiba Tecra 500CS
• CD-ROM, no floppy
• serial port on COM1, modem on COM2
• COMMAND.COM from Windows 98, no other software
• Serial "Laplink" type cable (null-modem)
• second computer

As you may know, the DOS COPY command allows copying of files to and from the serial port. Since COPY is a built in command (it's part of COMMAND.COM), I used this as the basis for getting the machine running.

The problem is that whenever you COPY from the serial port, you must copy in ASCII mode so that COPY knows when to stop. Unfortunately, this means that while text files will copy correctly, applications cannot normally be copied using this method, which explains the myriad serial file transfer utilities that are available. Since I couldn't install a serial transfer utility, I dug around to find out exactly what ASCII characters COPY would not transfer in ASCII mode. As it turns out, the only difference (AFAIK) between binary and ASCII copies is that the hex character 0x1A is used to signal end of file transfer. This character (CTRL-Z) can be found in application programs, which is why these must be transferred in binary.

the procedure

For the install, I connected a desktop machine to the laptop via the serial cable. To test the connection, I used Tera Term to open the serial port on the desktop. My laptop's serial port was configured on COM1, so I typed

"CTTY COM1"

at the DOS prompt. The CTTY command changes the standard input, so that control of the computer was transfered to the serial line (incidentally, type "CTTY CON" to get control back to the keyboard). I had to play with the speed, parity, and stop bit settings on the desktop machine since the COM port on the laptop was stuck with the default values. You know they're matched when typing doesn't produce garbage on the terminal screen. :)

Once I verified that the serial link worked, I acquired a small terminal emulator that supported file transfers. The program I used is called VTemu, written by Mr.Wichai Patipaporn. This program appealed to me because it is less than 8KB in size and supports file transfers via the Kermit protocol.

The next step was to get the program over to the laptop. A direct copy over the serial line was not possible, since COPY would stop after each 0x1A character it encountered (there are 4 such characters in VTemu). In order to transfer the file, I split it into 5 pieces; using a hex editor, I saved each section of the file to a separate file, where each section was delineated by the 0x1A characters. So, for example, the first section starts from the beginning of the program up to and including the first 0x1A. The resulting files were:

• vtemu.co1, 88 bytes
• vtemu.co2, 561 bytes
• vtemu.co3, 70 bytes
• vtemu.co4, 1089 bytes
• vtemu.co5, 5675 bytes

To perform the transfer, on the laptop I issued the command

"COPY COM1 vtemu.coX"

for each of the 5 files. On the desktop, I used Tera Term's "Send File" option with the binary box checked. Each of the first 4 files should be ONE BYTE LESS on the DOS end. This is because COPY will strip the 0x1A character from the end of each of these files. Some of the files did not turn out at the correct size, probably due to transmission errors or other anomalies. Unfortunately, since there is no error detection or correction with COPY, the only metric available is the file size; if the sizes were not correct, I recopied the files. I had to do this a frustrating number of times, which is precisely the reason I chose a small program to transfer in the first place (smaller file = less possibility for errors). If you're trying this, it may help to set a transmission delay on the sending end. Also, using the desktop to control the laptop via CTTY may or may not help. (note)

Before recombining the file, I had to first recover the lost byte on each of the first four files. It turns out that the COPY command is again our friend here: issuing the command

"COPY /a vtemu.coX /b+,,"

has the effect of appending a 0x1A character to the end of the copied file! Our lost byte has returned!

Finally, to reconstruct the file, I issued the command

"COPY /b vtemu.co1 + vtemu.co2 + vtemu.co3 + vtemu.co4 + vtemu.co5 vtemu.com",

which stitched the pieces of the file back together. For those following along at home, vtemu.com should be 7,483 bytes when reassembled.

wrap up

After finally getting vtemu.com transfered to the laptop correctly, I was able to use it to transfer over other files, such as the CD-ROM drivers. Kermit dialects are not necessarily uniform, as I found out when trying to use Tera Term to transfer to vtemu. Use vtemu on both ends to transfer a serial copy utility or similar app. with which to do heavy duty file transfers.

Please let me know if there are any mistakes or possible enhancements.

October 2004: alternate technique

references, programs, and thanks

Thanks to Mr. Patipaporn, author of the amazing VTemu.

Thanks to Laurence, who provided the bit about appending 0x1A characters to the end of files.

The hex editor I used is called XVI32.

The excellent Tera Term is here.

Notes

David Byte writes:

"A note on getting the file sizes right.. the closer your can time starting the copy comX filename to the transfer initiating on the PC the less attempts you will have to make."

Thanks for the tip, David! (June 11, 2002)

(return to discussion)

VTemu seems to have vanished from the Web. Here is a zip archive with the original program as well as the 5 pieces described above.

(return to discussion)