Communications on Toshiba T1000 laptop

Hi everyone, good morning! I have been able to repair a Toshiba T1000 laptop, now I’m trying to send some files to it using a serial null-modem cable. The problem it’s that I can send and receive text using termite on my windows machine and “type com1” command in the Toshiba, but I can’t send files to it.
I have tried to follow the method explained here without any success.
Anyone knows (or have been able to) how to transfer files from a modern pc to my old Toshiba?

Thanks in advance!

1 Like

I’m guessing you’ll need a program at the receiving end - and to load that, you’d need to type it in (do you have DEBUG?) or type it in (do you have a BASIC?) I’m supposing you have no floppy or solid state storage or CD ROM to boot from? (You could presumably remove the hard drive and put it into another machine and put some useful utilities on it that way?)

These two stackexchange sites might have some clues:

1 Like

Hi Ed! The Toshiba has a floppy drive, but I don’t have any floppy or another working floppy drive to use with a modern pc to copy the data. The laptop has DOS 2.11 in ROM, without basic but it has the debug program. I have thought that the “copy” method would work but I have some kind of issue with the file transfers. I can communicate both computers and send text between them but when I try to send a file I can’t do it. I will check the links that you have shared, I hope to have good news soon, thanks!

Could be an interesting adventure! I think when using COPY you have to watch out for ^Z characters which act as end-of-file. Maybe there’s a binary mode.

I notice from the links I posted that DOS has a CTTY command which can allow it to accept input from serial. So, whatever complex things you might otherwise need to type into DOS, you can instead copy and paste over serial.

I have in the past used srecord to make an intel format, or motorola format, ascii version of data for file transfer purposes. You’d need an srecord loader for DOS which you could create in DEBUG. You can already create a binary in DEBUG using the ‘enter’ command.

But if you find a ZMODEM executable, you could just paste all of that into a DEBUG session, in appropriate hex format, and then you’d have ZMODEM on the DOS machine. No need for any intermediate loader.

1 Like

With all my retro kit, I remove the floppy drives and replace with a Gotek Floppy Emulator - they are inexpensive and do the trick for me. (search ebay, they are about the same price as a box of floppies)

Replace the firmware with FlashFloppy - the stock firmware is quite ropey…


Thanks Richard!
Yes, I know it, Gotek emulator it’s a great device but I just wanted to test the machine in a “quick” way. Also, I’m on Argentina and here the emulator it’s too expensive due to the import taxes, sadly we are in a complicated economic situation and I need to save money until the situation be normalized again.

I can appreciate the difficulty… I done some searching about and came across this site, send the file in text and use a BASIC program to convert from HEX to binary. (this converts everything to 7 bit and no special characters to confuse the copy)


1 Like

Not sure if @aleperez has a Basic or QBasic… here’s a short DEBUG script to pipe in from the big machine, which builds a uudecode program:

Then you can copy over something like Kermit, having uuencoded it to make it printable.

Edit: see also xxdecode.txt in this kit of useful things:

via this 1999 usenet posting

Edit 2: see also NETRUN which converts an executable into an executable which uses only printable ASCII.

Edit 3: See also this discussion on a C compiler which produces executables formed only of printable characters. In that discussion several other conversion tools are named.

Edit 4: For completeness, there’s another method or two linked from the page @RichardP posted.

Edit 5: also see this stackexchange Q&A.


A post was split to a new topic: Programming Z80 using only printable characters - a challenge

Hi everyone! Good morning!

I haven’t forgotten this topic, just I have taken time to test all the options that I have found thanks to the group.
Sadly, I haven’t been able to use the serial port to send data to the Toshiba successfully. I was able to send as a dbg file and compiled in the Toshiba file, but any attempt with any other bigger file has been unsuccessful.
By some reason, the Toshiba serial port isn’t able to establish a stable communication with my usb serial adapter, I have several suspects:

  • A possible difference in the Toshiba hardware, that isn’t compatible with vterm application.
  • A possible problem in the implementation of RS232 communication on the serial adapter.

I have discarded possible problems with the null modem cable, and I have tried several baud rates combinations on a loopback configuration and it seems that it’s fine.

The serial adapter it’s based on Prolific chip, so this could be a problem. The chip is know by their problems, so it’s a possible culprit.
On another hand, I have tried to find technical details about Toshiba serial port, and accord to the minimal information that I found it should be IBM PC compatible. The sad part it’s that the information isn’t enough to be sure that it’s full compatible or not.

Finally, I have been able to find a usb floppy drive able to read and write single density floppies, with it I have been able to test the notebook with several applications and games
I’m planning to get another USB serial adapter but based on the FTDI chip, and I will test the options covered here again. I hope to obtain different results, anyway I will share them with the group!

Thanks to all for your help!


Good idea to try an FTDI adapter. The flow control on these adaptors is often missing or idiosyncratic. If you have a way to pace the communications from the PC side - some comms programs allow you to set a small delay at the end of each line - that might help.

1 Like

Hi Ed!
Yes, I have tested several terminal applications with this approach. I have tried with an extra delay per char, and line too without success.
Seems that the adapter has some kind of problem with the amount of data, or fails to maintain the data flow after a time. Could be a problem with their drivers implementations too, I have tried to use Windows 10, Ubuntu 18, and older SOs from virtual boxes without success. The communication begins, but after a little time extra chars begins to appear in the Toshiba side, seem like the communication protocol fails, or I have misunderstood how to achieve the communication with it.

I have taken several notes about my attempts hoping to have a bit more time to share them with a bit more of organization. I haven’t discarded this idea, but I’m overworked and overburned at this time of the year so I have needed to postpone my work with the Toshiba.


Regarding USB-disk drives: My personal go-to device is the Imation SuperDisk, which supports 720K and 1.4MB formats along its own 120MB format (there’s a second gen. 240MB format, as well). A bit retro on its own, but still works perfectly without any maintenance.

(Note: On a Mac, you’ll have to format single density disks from within a VM running DOS or similar, since Apple discarded 720K options decades ago. However, it still works from a guest OS and a drive directly mounted to the VM.)

Other: Congrats for the successful boot!
Regarding adapters with FTDI chips, I’ve one that worked well for me with vintage hardware. Mind that you often can’t actually use the fastest speeds specified for the hardware due to software limitations. (E.g., there’s too much time spent on a line saved on encountering a line break and some of the consecutive bits are missed.) Reducing speed often helps with unstable communications.
(I also observed that I can’t reach top speeds mentioned in period publications for a particular hardware using a USB adapter. Sticking to the lower ranges for a start may help.)

just double checking that the NULL modem cable is a full one with RTS/CTS DSR/DTR with the usual data. I have seen many cheating serial devices that dont do the full -12V to +12V swing that RS232 specifies.

From basic, you can change tact and do a Toshiba asking the PC for X bytes… That way there is a soft-flow control. Request-Response type method. you can also do basic check-sums then.


1 Like