View Full Version : Punching/uploading paper tape images

April 4th, 2015, 04:52 PM
I have a bunch of paper tape images (notably BASIC) for my Altair in .bin and SIMH's .tap format but I can't seem to figure out how to send them from my laptop to the computer. They seem to be in a format that's beyond plain ASCII and thus using something like Hyper Terminal just spews out garbage both to the altair or to my teletype. Should I try and make a real paper tape. How exactly do you do this?

April 5th, 2015, 04:20 AM
How about trying a binary-to-hex converter?


You can also find code online for a program on the Altair side to read the hex file and directly install the binary code into memory, ready to run.

Good luck!

April 5th, 2015, 04:22 AM
Oh, I have also used Kermit on a few platforms to do this kind of transfer.


April 5th, 2015, 04:57 AM
the Kermit tool, or an application called Kermit?

April 5th, 2015, 05:10 AM
the Kermit tool, or an application called Kermit?

Well, for me Kermit is both a tool and a computer application. I got my code for the vintage computer side from here:


Once you get it running on the vintage side, you can use a terminal program like Tera Term on the PC side.
Tera Term has a variety of file transfer protocols built in, like Kermit.

I am not trying to be pedantic here, I'm only offering suggestions that have worked for me.

Good luck!

April 5th, 2015, 05:16 AM

I'm not at all sure the encoding format used for the Altair is the same, but here is a tool to translate back and forth between paper tape encoding and clean ascii for the KIM-1 paper tape format, on the site of Hans Otten: link (http://retro.hansotten.nl/index.php?page=micro-kim). The wikipedia page on punched paper tape and the Teletype 33 also have some detail on how 8 bit ascii is encoded I believe.



April 5th, 2015, 07:49 AM
If the tapes are Altair paper tape images you will need a loader. They most likely are binary. The only question is which loader they need? For basic, you need a 1st stage loader and then the tape contains a second stage loader and the software. My suspicion is that your copy of basic could also be a strait binary dump and not the 2 stage as well since the file is .bin and not .tap

The only stuff I have seen in straight up ascii are actual basic programs and they will be ascii and a bunch of nulls at the end of each line. The number of nulls tells you the speed of the reader that it was punched for. With a PC over a real paper tape reader, you can have it simulate more nulls with a pause at the end of each line (CR/LF) to give basic time to process the line.


April 5th, 2015, 08:00 AM
I thought that .TAP were mag tape not paper tape. Unlike Mag Tape were there are blocks with unrecorded or erased gaps in between. Paper Tape can't have gaps as in order to be read paper tape needs holes down the middle. So there needs to be some kind of block start and end markers. Does this link help:-. It points to a utility to convert from .BIN to paper tape...


which is in their files section

April 5th, 2015, 08:59 AM
The holes offset down the middle of paper tape are not encoded into the data. Also MITS paper tape and audio images are identical. The 88-ACR uses the same routines as the SIO-A running at 300 baud. So much so you can hack basic to use the SIO-A port and use csave and cload by simply poking the port number.

Also the utility in that posting you refer to makes a binary MITS MBL loader compatible. There are checksum and stuff in the data it has to add that the loader reads off the tape. The system doesn't care if it's from actual tape or a serial connection to a PC.

April 5th, 2015, 09:27 AM
The holes are not encoded, which is kind of the problem. Its not easy to have pure binary paper tape. The tape leader before the data starts has holes, and if it was pure binary, and the first byte on the tape was a NULL or all zero bits, how would you know where the first byte started. So the tapes can't be pure "Binary".

HyperTerm will send Binary, so I don't see the problem is in sending binary. Its how you tell the Altair that you are going to start send a binary tape and to start listening for it.

April 5th, 2015, 10:03 AM
Typically there is a leader character. Sometimes it's null. Sometimes it's a specific byte. MITS basic uses a byte which depends on the version of basic. 3.x and 4.x have a different byte and their stage-1 boot loaders skips that byte until the data begins.

April 5th, 2015, 11:57 AM
So apparently I can find a loader for 4K BASIC 3.2 included with the Altair32 emulator. It's already in a hex format as well and the formatting looks familiar to what I saw when I opened the supposed hex of BASIC in notepad.

:1400000021AE0F311200DB060FD8DB07BDC82D77C0E903004 C

There's also an image for 4K BASIC in .tap and .bin format and in a hex editor or notepad they seem to be identical to images I already own. Both .bin files convert to identical files when I run them though bin2hex.
So now at the least we have what appears to be a loader, plus, what is probably 4K BASIC in .tap, .bin and .hex formats, but still no real idea how to send them off to the punch in a useable format. I've tried plugging them into the Altair32 emulator for now but either that thing is extremely buggy with tape operations (I can load its included disk images fine at least) or the images do not work.

Here, give it a try yourself. There's also a pile of images and documentation included. (http://www.altair32.com/Altair32code.htm)

Edited: Actually, now that I've better looked at the emulator and noticed it can use a terminal on the physical COM port, we could for now completely ignore my altair and feed the emulator an image, then with the teletype attached we can dump it out the serial port to the teletype's punch and boom, we got our tape. Problem is I still can't get this damn thing to work with any of the loaders/images.

April 5th, 2015, 12:28 PM
Is the punch on the Teletype or a separate punch. Basically if you set the baud rate properly and you need 8-bits no parity, then on Windows just do:-

copy /b file.tap com1:

April 5th, 2015, 06:09 PM
it's on the teletype.

April 6th, 2015, 12:10 AM
Pretty sure if you attach to PC Serial port you should just be able to copy the tape as above...

April 6th, 2015, 12:15 AM
I don't have a TTY but I do have a couple of GNT serial reader/punches. If you are still having problems I will see if I can set things up to work on the emulator with one of my paper tape punches. I was trying to use the emulator DOS console but it does not appear to work on 64-bit windows and I don't have Telnet client on this box. If I do produce a real tape I can probably mail it to you...

April 6th, 2015, 04:55 AM
I make paper tapes all the time using a USB serial to my punch. They work perfectly. The only time this doesn't work is with an ASR-33. For anyone reading this thread who has an ASR, even if you have a current loop to RS232 converter, the 110 baud is too slow for most modern computer serial ports or USB adapters. In that case you can use a modified Apple serial card with an Apple IIe or IIplus. I think Mike Willegal has done this in his blog to emulate a current loop connection to his Scelbi. Same technique should work to an ASR-33.

April 6th, 2015, 07:02 AM
copy /b file.tap com1:
...seems to work fine for punching out BASIC programs but either because the BASIC image uses a number of special characters or simply because I'm trying to punch it out on a teletype the machine loses its mind and does random things like start/stop the reader, do form feeds and trigger the HERE IS.

Define "Modern". I know for general text I/O my P4 computer works well and if that doesn't cut it, I got older thinkpads and toughbooks all over the place.

If I do produce a real tape I can probably mail it to you...
Thanks and I'll remember that should it come down to that but I'll leave that as a last resort because I know how expensive 1" tape is these days.

April 6th, 2015, 08:39 AM
I have 24 reels of blue and two reels of green in stock so its not likely to be a huge hole in my stocks...

.. yes, it would do things like that, which is why I assumed the tape wasn't really binary but some kind of hex. Its been many a year since I used an ASR33 and I don't remember if it was possible to disable the print mechanism while punching....

... let me as on the green keys list...

April 6th, 2015, 09:01 AM
I have a bunch of paper tape images (notably BASIC) for my Altair in .bin and SIMH's .tap format but I can't seem to figure out how to send them from my laptop to the computer. They seem to be in a format that's beyond plain ASCII and thus using something like Hyper Terminal just spews out garbage both to the altair or to my teletype. Should I try and make a real paper tape. How exactly do you do this?

Have you looked at Mike Douglas's videos (http://altairclone.com/altair_experience.htm)?

There is one specifically on loading 4K basic (https://www.youtube.com/watch?v=8InWiihlIQw&feature=youtu.be).

Geoff Harrison also has a great explanation of the process (http://www.solivant.com/altair_bootloaders/index.php?album=altair_bootloaders&pagen=0).

April 6th, 2015, 09:11 AM
I asked on the TTY list and yes weird things will happen, but the tape should come out OK. Can you set the reader to FREE to stop it being enabled? The answer I got was:-

Yes, the ASR33 can punch full 8 bit data when the data is received from an external source (e.g., a computer). Unfortunately, the printer mechanism tries to print everything that comes in as well, so you'll end up beating the printer to death and exercising most every function bar as control character values come in.

A "Print Nonprint" mechanism was available for the 33 that was used to disable the print mechanism when the operator pushed an external button provided as part of the mechanism. This mechanism blocked function bar activation as well. It's primary purpose was to allow punching of tapes without beating the poor print mechanism to death. Unfortunately, despite have specific part numbers for the parts, I've never been able to find them.

I created a small print-suppression bracket I manually insert into the codebar area that prevents the printer from printing when I punch a long binary tape. Note, however, that print suppression does NOT prevent function bar activation. So bells, carriage returns, line feeds, form feeds, etc., still occur. But since no printing will take place with the bracket in place, I remove paper before punching so runaway line feeds and form feeds aren't an issue.

I have asked for more details of themod...

April 6th, 2015, 02:37 PM
I have a bunch of paper tape images (notably BASIC) for my Altair in .bin and SIMH's .tap format but I can't seem to figure out how to send them from my laptop to the computer. They seem to be in a format that's beyond plain ASCII and thus using something like Hyper Terminal just spews out garbage both to the altair or to my teletype. Should I try and make a real paper tape. How exactly do you do this?

I do this all the time using a PC as the source of the paper tape data (as you've described), or from real paper tape, or from cassette. When loading original MITS software for the Altair (4K BASIC, 8K BASIC, Extended BASIC, etc.), the files you've found are the exact same data as on the paper tape and as on the cassette.

Based on the type of serial port in your system and the particular BASIC (size and version) you're loading, you need to enter the appropriate boot loader via the front panel switches. After the boot loader is entered, the sense switches (A15-A8) are then set to tell BASIC and the 2nd stage loader on the tape (the "checksum loader") which serial port is being used to load BASIC and as the BASIC console.

You'll have to use a terminal emulator other than HyperTerm as it won't do simple 8-bit transfers. TeraTerm is a great terminal emulator for working with old computers. Download the version I put on the Altair Clone website http://altairclone.com/downloads/teraterm477.zip. There's a short ReadMe file that will help with installation.

I can give you specific instructions and the proper loader if you want to choose a tape image you want to try first and tell me what type of serial port you have in your Altair.

Also, you can watch a couple of videos in which I do this exact boot of the Altair using the PC as the source of the paper tape. Go to http://altairclone.com/altair_experience.htm and look down the page for "Loading Altair 4K BASIC" (demo of loading 4K BASIC v3.2 through SIO board at I/O address 0/1) and for "Loading and Operating 8K BASIC" (demo of loading 8K BASIC v4.0 through SIO board at I/O address 6/7 - same as the cassette). I can point you to bootstrap loaders for the 2SIO card as well if this is what is in your machine.


April 6th, 2015, 06:56 PM
Okay, I'm starting to get the picture now. If it's normal for the teletype to work everything when punched that's something I can deal with. Years back when I first exercised and oiled the machine I made a looped piece of paper that meant that it just continued to print to the same two sheets until it wore the pages completely out. I can just fit that again to punch the roll. Yeah I spent the last couple days watching Mike's videos so I'm already up to date on that.
Let me go give something a try.

Edited: Ran it through Tera Term, set the COM port to 110, 7, E, 2 which I was told is what the teletype expects and it punched out but on verification it failed. :(


April 7th, 2015, 06:24 AM
Need to use 8N2 with the teletype in order to punch 8 bit data.


April 7th, 2015, 08:52 AM
Yep. That did it. I ran off a short piece of tape to compare and you could physically see that the eighth bit was being handled differently.


I then punched the full 4K BASIC tape and read it back to verify. Save for four bytes missed at the end by the reader cutting off too early it's a matched image. Thanks for the help. I'll look into making a how-to for Youtube as I'm sure I am not the only person asking these questions.


April 7th, 2015, 11:08 AM
That looks like progress, Mike Douglas on the Green Keys list send me these two pics of his function bar defeat mod...


April 7th, 2015, 06:10 PM
Save for four bytes missed at the end by the reader cutting off too early it's a matched image.

The end of the tape (as far as loading BASIC is concerned) are the three bytes "78 00 00" at 105D-105F. These bytes tell the loader to jump to address zero and begin execution.

Good job!

April 7th, 2015, 07:26 PM
They're so close to the absolute end of the tape that they're really just parts of the footer and do not affect the operation of the loading.

April 8th, 2015, 07:56 AM
They're so close to the absolute end of the tape that they're really just parts of the footer and do not affect the operation of the loading.

Yes, that's what I was getting at :). The actual end of the tape - as far data required for loading BASIC - is about 224 bytes prior to the end of the file shown as shown in the hex dump. The last required information on the tape is the 78 00 00 at offset 105D-105F.


December 5th, 2016, 11:10 AM
Hi All,

I reply to this old thread because I have a "similar" problem.
I have an Altair 4K basic 3.2 on paper tape and I would like to transfer it from my asr33 tape reader to my PC.
I have everything is needed to realize the communication between them (PC and tty), I can send and receive characters from both parts.

But when I tried to send the paper tape toward the PC, all characters were weird, then were deleted by others, and so on. I use TeraTerm on the PC side with a 8N2 and 110 bauds configuration.
My goal is to save my paper tape in a PC file.
I guess the paper tape contains binary data, right ?
Do I need kermit or another protocol to do this ?

Thank you in advance,


December 5th, 2016, 01:24 PM
If you read the Altair manual it tells you how to copy binary data to a file using TeraTerm. I think you need to start the tape at the first non-zero character...


File->Log... Receives a file over the serial port with no protocol (e.g., paper tape or cassette). Be sure the "Binary" checkbox at the bottom of the file dialog box is checked. When the file log operation is started, a new taskbar tile appears (TeraTerm:Log). When file reception is complete, click on the log taskbar tile and then click the “Close” button to complete the file receive operation.

December 6th, 2016, 12:45 PM
Thank you Dave.

I got my file from the paper tape. But I had to remove manually several (141) hexa sequences : 5B 42 52 45 41 4B 5D
They correspond to : [BREAK]
I guess it's a matter of transfer configuration.

Then, to have the same content of the 4kbas32m.tap file from Altair32, I had to replace 0D 0A by 00. This sequence (0D 0A) was right after each [BREAK] sequences.

I noticed that I got a lot of hexa data before the "program" begins. Could they be the loaders you're talking about in this thread ?
At the end too, I have an additionnal hexa data paquet in comparaison with the Altair32 file.

Finally, I cannot find the 78 00 00 sequence, mine is 78 00 9A.

Have a nice evening,

December 11th, 2016, 05:41 AM
Hi guys,

I finally figured out that the [BREAK] were added by my usb tty adapter when a break was sent from the tty.
May be the 0D 0A have to do with CR/LF ??

I now have problem to transfer data to the tty. I sent a small part of the 4kbas32m.tap file and the punched result tape was a succession of identicals sequences.
I sent :


And I received :


I noticed another point : if I send a simple sentence "hello, this is a test" with TeraTerm or HyperTerm, the punched tape isn't the same. The usb adapter configuration is always the same, I don't know which sofware configuration is responsible for this behaviour. Do you have any idea ?
Thank you.


December 12th, 2016, 12:56 AM
0D 0A are cr and lf. You might have problems if USB adaptor is set wrongly. for binary tape needs to be 8-bits no parity.

December 12th, 2016, 02:29 AM
I use the usb adapter made by Eric, from Greenkeys forum. May be someone else uses it to communicate with a 33.
I think that the adapter configuration is correct, because despite the [BREAK] and 0D 0A sequences, I got my tape image.

Both softwares are set with 8N2.

I don't understand why is the beginning of the result tape correct (the 10 first bytes at least) and then it loops on the same sequence.

January 7th, 2017, 01:04 PM
Hi guys,

I finally figured out my problem.
I only have to set a transmit delay