UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 11th May 2021, 11:22 am   #1
JohnJones
Diode
 
Join Date: May 2021
Location: Hatfield, Hertfordshire, UK.
Posts: 4
Default MK14 computer with a OK-80a paper tape reader - what data required for the paper tape

Hello All

Firstly, this is my first posting to this forum, so forgive me if I've managed to post to the wrong one.

I am in the process of assembling a replica OP-80a punched paper tape reader for use with replica MK14.

Of course, to test it all out I'll need a punched paper tape.

I have identified a company that produces punched paper tapes.

My question is: What is the format of the data file that I need to supply?

I appreciate that this might seem an obvious question but for me it isn't. If I compare the situation with my experience of using a KIM-1: that computer has routines in its monitor to print to a paper tape puncher or produce a correctly formatted file for that use, but (at least I don't think so) the MK 14 has no such routine.

As an example: if I take the Moon Landing program (or any program) from out of the MK14 user guide, in what format would I need to save that to a file to get it printed as a punched paper tape?

Any help would be very much appreciated.

And, yes, I have asked the company that produce the punched paper tapes but they have - quite reasonably - said that they cannot advise on individual makes of computer.

I hope the following might be of help:

I'm trying to achieve what is shown in this YouTube video: https://youtu.be/yg2P5I3URrw

If I can provide any other information that could help, please just ask and I'll do my best.

Many thanks.

John
JohnJones is offline   Reply With Quote
Old 11th May 2021, 2:28 pm   #2
TonyDuell
Dekatron
 
Join Date: Jun 2015
Location: Biggin Hill, London, UK.
Posts: 4,182
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

I don't think I've ever seen a paper tape reader on an MK14.

It would be quite easy to interface one to one of the ports of the IND8154 chip, but as you say there's no standard software to drive it. You'd have to write your own routine, at which point the paper tape format could be just about anything you like.

I would avoid raw binary, simply because you would have to start the tape at exactly the right point. But 'skip over nulls until you find a non-zero character, ignore it, and read following characters into memory' would work. So would using 2 characters on the tape per byte, low nyble is a nybble to store, upper nybble is anything non-zero. Intel hex, while standard is probably a bit too much work.
TonyDuell is offline   Reply With Quote
Old 11th May 2021, 3:14 pm   #3
Mark1960
Hexode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 459
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

I didn’t listen to the youtube video, or even really watch it as I find them to be mostly advertisements, broken up by youtube advertisements. Skipping through quite quickly, I didn’t notice him entering a bootloader on the MK14. This would probably take just as long to enter on the keypad as it would to enter the moonlander program from the keypad. I don’t think the cassette interface routine of the later version prom would be much use for this as it requires serial data.

A more useful paper tape input for the MK14 would use the keypad input routines of the MK14, with the papertape containing codes for the keypresses. As the MK14 keypad interface is a scanned matrix this would not be trivial in basic logic circuits, but quite possible to achieve. Using an arduino or similar would be easier but seems like cheating. The interface would need to match part of the character on the tape with the keyboard scan address for the coded keypress and then activate the correct keypad sense input based on the remainder of the character from the tape.
Mark1960 is offline   Reply With Quote
Old 11th May 2021, 3:33 pm   #4
JohnJones
Diode
 
Join Date: May 2021
Location: Hatfield, Hertfordshire, UK.
Posts: 4
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Quote:
Originally Posted by TonyDuell View Post
I don't think I've ever seen a paper tape reader on an MK14.

It would be quite easy to interface one to one of the ports of the IND8154 chip, but as you say there's no standard software to drive it. You'd have to write your own routine, at which point the paper tape format could be just about anything you like.

I would avoid raw binary, simply because you would have to start the tape at exactly the right point. But 'skip over nulls until you find a non-zero character, ignore it, and read following characters into memory' would work. So would using 2 characters on the tape per byte, low nyble is a nybble to store, upper nybble is anything non-zero. Intel hex, while standard is probably a bit too much work.
Many thanks for your reply.

Indeed, I'd never seen one until I saw the YouTube video I linked to.

Luckily, all the things you mention are solved for me, except the actual format of the punched paper tape Ė or, rather, the format of the data file I need to send to the punched paper tape provider to make the tape.

The interface to the MK14 is, as you say, via the IND8154; I already have a routine to enter into the MK14 to process the data coming in from the paper tape reader via the IND8154, which is based on the approach suggested in the original OP-80a manual (and as shown in the YouTube video). That is based on setting the start location of memory to be populated, looking for the first non-zero character, taking that and putting it into the first memory location, incrementing the memory location, loading the next character, and looping through that process. To quote the manual:

"This loader places binary data from the OP-80a in memory beginning at the 'starting address'."

So, I know it's looking for binary data.

For example: if I take the first 10 bytes in Hex of the Moon Landing program for the MK 14 they are (loaded starting at memory location 0F14):

08
50
00
99
80
00
99
98
00
02

So, is the data file I send to the people who print out the punched paper tape reader just these values in a text file, in this format (one value per line)? I'm assuming not, as the routine processing the incoming data say it wants binary data.

So, instead, do I create a file of the binary equivalent values, like this?

1000
1010000
0
10011001
10000000
0
10011001
10011000
0
10

And, is that the right format.

I have no idea
JohnJones is offline   Reply With Quote
Old 11th May 2021, 4:53 pm   #5
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 923
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

I had planned to do this myself since seeing Jerrry's OP80 and having one of his MK14's, when retro budget allows the OP80 and thought that maybe replacing the SCIOS 2 tape routines with a paper tape loader would be a good idea.

My main interest though has changed to do so with the longer programs for the 1.5K memory expansion where the tape routines might still be needed and the basic loader is only short anyway using binary.

There is another HEX loader firmware available but, so much of the SCIOS is removed it is more useful for development off machine to squirt data for running over serial - another half completed YouTube video I intend to put up reviewing the MK14 scene. This proves Tony's point.

I do like Mark's idea of using the keyboard but, having a BINARY format on the tape would allow me to use it to load code into the SCRUMPI as well - I published on a thread here a minimum serial binary loader on here which should be easy to adapt to parallel. I think the loader is visible in the video and would be easy to type in anyway - I manged to get an entire game from freeze framed video once...

As regards the OP original question - the format of file to supply is a question for the person who will punch it - I expect a RAW file of bytes or a plain HEX ASCII (Not intel etc) where each byte is just a character par in HEX

C9B3001A etc
Timbucus is offline   Reply With Quote
Old 11th May 2021, 5:28 pm   #6
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 923
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Just a thought as well - most of the programs are available in HEX format already so you may be best using known good ones to create the punch requests... If you have an EPROM programmer the software is a quick and easy way to load the Intel HEX file and then export a binary block... Other programs are available at the command line to do this especially in Linux...

I have also been thinking that the bare binary format would be a problem for the split address used with the expanded memory on the MK14 - e..g SEGTRIS uses the full 512 bytes at both B00 and F14 - it is a risk overwriting the bytes at 0F00-0F14 so you would need the safe values in there - or maybe not as the RESET would wipe them anyway. You then would write a file from B00-FFF as is and allow the boot loader to read and throw away the NULLS that would be included.

Then you have to cross the two IO shadows at C00 and E00 so you would need to ensure the image on the tape at this points was your boot loader as it would get overwritten. I suppose the other values need to be clever for the INS8154 as well as the config would change as the read/write passed over there

The KB and Display Shadow may cause the display to be funny but, should be risk free.

The best solution would be a small pre-amble so the minimal boot loader loads a small longer loader in the 8154 RAM which then knows how to skip writing when in the C,D and E pages... or make that part of the loader - it will probably only add a few bytes and makes the paper tapes more universal.

The Memory map
-----------------------

Only the first 12 bits of the program counter are decoded - the remainder are
present on the Data Bus so need to be latched for decoding - note that SCIOS
relies on the wrap from FFF to 000 in the lower 4K making memory expansion more
difficult. The "decoded by" fields cover A11-A8 - A7-A0 are within 256 slot...

000-1FF 512 byte SCIOS ROM Decoded by 0xxx - see mod to A11 for expansion

200-3FF ROM Shadow / Expansion RAM
400-5FF ROM Shadow / Expansion RAM
600-7FF ROM Shadow / Expansion RAM

800-87F I/O Ports Decoded by 1xx0
800-824 are control registers
800-807 - Clear BIT port A
808-80F - Clear BIT port B
810-817 - Set BIT port A
818-81F - Set BIT port B
820 Read/Write Port A
821 Read/Write Port B
822 Port A direction register D BUS (ACC) to ODA (1 = Output, 0 = Input)
823 Port B direction register D BUS (ACC) to ODB (1 = Output, 0 = Input)
823 Port B Mode Definition Reg D BUS (ACC) to MDR
7 6 5 4-0 (Port B Bit 7 Input, Bit 6 - Output to use this mode)
x x 0 xxxxx - BASIC I/O
x 0 1 xxxxx - STROBED INPUT
0 1 1 xxxxx - STROBED OUTPUT
1 1 1 xxxxx - STROBED OUTPUT WITH TRI-STATE
825-87F undefined

880-8FF 128 bytes I/O chip RAM Decoded by 1xx0

900-9FF Keyboard & Display Decoded by 1x01
900 Left Digit 1 (see later table of letters etc)
-
908 Right Digit 8
A00-AFF I/O Port & RAM Shadow
B00-BFF 256 bytes RAM (Extended) / VDU RAM Decoded by 1011

User programs

C00-CFF I/O Port & RAM Shadow
D00-DFF Keyboard & Display Shadow - Used by SCIOS for Tape as 0D5 and 0D6

E00-EFF I/O Port & RAM Shadow (used by some programs e.g. CT Life)

F00-FFF 256 bytes RAM (Standard) / VDU RAM Decoded by 1111

F00-F11 are used by ROM Monitor (document)
F00 - Right most digit on display
..
F07 - Left most digit on display (shown by calling KYBD in SCIOS)
F08
..
F11

F12 onwards for User programs - usually variables... for -ve relative access

F20 convention for Start of User programs.

Stack Pointer P2 by convention in Williamson book starts at FF8 and grows
down in memory (the book uses the other term that increasing address is down
which can confuse the reader...) The pointer is always pointing at the last
filled address by this convention.

Top bytes are used by ROM monitor for register store for GO
FF9 P1 High
FFA P1 Low
FFB P2 High
FFC P2 Low
FFD A
FFE E
FFF S

This is the bit that relies on the address wrap...
Timbucus is offline   Reply With Quote
Old 11th May 2021, 8:34 pm   #7
JohnJones
Diode
 
Join Date: May 2021
Location: Hatfield, Hertfordshire, UK.
Posts: 4
Default

Hello Timbucus

Quote:
As regards the OP original question - the format of file to supply is a question for the person who will punch it - I expect a RAW file of bytes or a plain HEX ASCII (Not intel etc) where each byte is just a character par in HEX

C9B3001A etc
Many thanks for the reply. That's certainly put me on the right path.

And, again, many thanks Timbucus. Yes, I had been wondering about the issue of split addresses, so these ideas a really helpful.
JohnJones is offline   Reply With Quote
Old 11th May 2021, 8:52 pm   #8
Mark1960
Hexode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 459
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Another possible option is remove the proms from the MK14, when the prom is enabled provide the data from the tape reader, drive the nhold low until the next byte is read. The tape is then programmed with the binary image of an unrolled program to write a program into ram and then jump to ram. It might need a few jumps added to stop the program counter reaching the end of the prom.

I have done something similar using a z80 and an ft245, initial bootstrap data writes a bootloader to ram, then executes the bootloader to download the rest of the ram.

A paper tape reader might be interesting, but I don’t think I would bother without a way to punch tapes myself. I had wondered if it might be possible to adapt one of the cheap music box mechanisms and manual punch the tapes.
Mark1960 is offline   Reply With Quote
Old 11th May 2021, 9:34 pm   #9
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 923
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

An advert for the original OP80 for those interested.

Click image for larger version

Name:	Byte _7_77_OAE.jpg
Views:	26
Size:	76.9 KB
ID:	233820

I had thought that I might attempt a small program with my hand editor - 20 or thirty bytes for an MK14 is perhaps possible - or even to stitch a small boot loader on a long leader pre punched tape - it is shown here with the only Tape I have left from when I used a teletype and punch on the Alpha we had in college.

Click image for larger version

Name:	keyvalbas.jpg
Views:	25
Size:	42.0 KB
ID:	233821
Timbucus is offline   Reply With Quote
Old 11th May 2021, 9:37 pm   #10
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 923
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Quote:
Originally Posted by Mark1960 View Post
Another possible option is remove the proms from the MK14, when the prom is enabled provide the data from the tape reader, drive the nhold low until the next byte is read. The tape is then programmed with the binary image of an unrolled program to write a program into ram and then jump to ram. It might need a few jumps added to stop the program counter reaching the end of the prom.

I have done something similar using a z80 and an ft245, initial bootstrap data writes a bootloader to ram, then executes the bootloader to download the rest of the ram.

A paper tape reader might be interesting, but I donít think I would bother without a way to punch tapes myself. I had wondered if it might be possible to adapt one of the cheap music box mechanisms and manual punch the tapes.
That is really clever - by remove the PROMS I assume you mean some form of digital switch that takes them out of the memory map temporarily while using the reader?
Timbucus is offline   Reply With Quote
Old 11th May 2021, 10:50 pm   #11
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 6,529
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

I have the impression that JohnJones already has the following sorted:

-Replica MK14 from JMP

-Replica punched tape reader also from JMP and connected to the 8154 ports as per that supplier's instructions.

-A bit of software (supplied by JMP? which has to be typed in or loaded from tape possibly into the RAM I/O area, which does the actual reading / loading from tape.

The two areas for conjecture are:

What format is the reader software supplied by JMP expecting to find on the punched tape? Code as plain binary? Code as ASCII hex? Code as Intel Hex?

What file format will the punched tape supplier require the code supplied to them to be in?

JJ has provided the first - sequential raw binary, with the user manually supplying the first address to which to load the code - in other words exactly as per the tape interface.

For the second, the question needs to be asked of the punched tape supplier - if they are offering a punched tape 'programming' service then it is incumbent on them to explain what file formats they can accept.

There are other ways of getting code into an MK14 at fairly high speed without having to punch tape (search other MK14 threads here) but if JJ just likes the idea of getting the MK14 / Tape reader combination working as originally intended, that is a good and noble enough reason to do it.

Last edited by SiriusHardware; 11th May 2021 at 10:56 pm.
SiriusHardware is offline   Reply With Quote
Old 11th May 2021, 11:41 pm   #12
Mark1960
Hexode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 459
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Quote:
Originally Posted by Timbucus View Post
That is really clever - by remove the PROMS I assume you mean some form of digital switch that takes them out of the memory map temporarily while using the reader?
It could be temporary I guess, though that needs some way to disable the chip enable so might mean hacking the board or lifting IC legs. On the z80 I used ram with battery backup, no rom, in bootstrap mode read from ram is disabled but write to ram and io is still enabled. If the code to be loaded doesnít use any routines from prom then they could just be removed.
Mark1960 is offline   Reply With Quote
Old 12th May 2021, 3:59 am   #13
ortek_service
Heptode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 629
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

I found this useful webpage about the original OP-80A: https://deramp.com/swtpc.com/OAE80_R...AE80_Index.htm which has a copy of the original manual, plus also has software listings to read tapes on 6800-systems. It seems from this document, that straight 8bit binary format (no header characters, checksum, address pointers, etc) could be used (on black tape?), for simplicity of entering a small program to handle that:
https://deramp.com/swtpc.com/OAE80_R...NewsLetter.pdf

There's not much here https://en.wikipedia.org/wiki/Punched_tape on the individual standards, but these show a number of different systems
(Mainly what seems the most common later 'standards' of 7bit ASCII + Parity / 8 bit binary)
https://www.cryptomuseum.com/telex/r...es/ecma_10.pdf
http://www.chilton-computing.org.uk/...apman/p015.htm
https://www.cryptomuseum.com/telex/r...es/ecma_10.pdf

Although no mention of header characters, checksum, address pointers etc. with these - Which I would expect to be documented somewhere, as Motorola did an EXORtape for their 6800 EXORciser etc. system, supply software on this. As well as various other systems like Altair around then (But maybe wasn't common on the SC/MP)

You could in theory make your own tapes, either totally manually: https://www.cryptomuseum.com/telex/repair/index.htm
or using a silhouette portrait printer (a bit costly at around £200?) to produce short strips with small index holes on blank paper etc, as well as a DIY reader:
https://www.instructables.com/DIY-Pa...er-and-Reader/

I'm sure I've got a roll of 1" wide? completely blank paper tape, a picked-up a few years ago (from a Radio Rally ?). So might still be able to get this (TNMoC must get through a bit on colossus, running in a continuous loop but only 5bit - It's surprising that hand-pulling of the tape on the OP-80A could get to 5,000 cps speed that involved a high-power lamp in colossus and expensive fast selenium? sensors (Although that was before semiconductors)

Last edited by ortek_service; 12th May 2021 at 4:19 am.
ortek_service is offline   Reply With Quote
Old 12th May 2021, 4:31 am   #14
TonyDuell
Dekatron
 
Join Date: Jun 2015
Location: Biggin Hill, London, UK.
Posts: 4,182
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

I do not believe you can hand-pull paper tape at 5000 cps. There are 10 characters/inch on paper tape, so that's 500 inches/second, or over 40 feet/second. Hmm....

A good powered optical reader will do 700-1000 cps. And the tape is really 'flying' when you do that. Punching is a lot slower, about 1/10th that speed on a good punch.

If you are desperate I can probably find a spare reel (1000 feet) of 1" (8 data tracks + sprocket track when punched) tape. I use it on serveral of my computers, so I don't want to give up all the stock I have, but the odd reel would be OK

Other than the issue of knowing where to start (perhaps assume the first character to load is non-zero, or skip the to the first non-zero character, ignore it, and read valid characters after that point) there is no reason not to use the 8 rows of data holes as 8 bits, and that will simplify the loader. For various reasons I've not looked at the video linked to above, is there any clue as to what the loader software consists of?
TonyDuell is offline   Reply With Quote
Old 12th May 2021, 7:53 am   #15
circuitryboy
Triode
 
circuitryboy's Avatar
 
Join Date: Jun 2012
Location: Bristol, UK.
Posts: 46
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Tape is Moon Landing code. Which starts x08 50 00 99 80 etc.

So we can see tape format is pure binary - Bit 0 at left and Bit 7 at right in the demo. Which is read straight into Port A of the '8154.

As SH has said, the tape preparation people are the ones to ask for how they want the data..

Can you see the error in byte 11? (Should be x58)
Attached Thumbnails
Click image for larger version

Name:	Format.JPG
Views:	24
Size:	26.3 KB
ID:	233828  
circuitryboy is offline   Reply With Quote
Old 12th May 2021, 8:36 am   #16
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 6,529
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

We should probably explain that as a new forum member for the first few posts JohnJones's post are being are being held for moderator approval and then when they are approved they appear in the thread in their correct chronological place - so all posts from post #8 to post #15 (as currently numbered) were probably made before JJ's post #7 became visible. To confuse matters, more of JJ's held posts may well be inserted into that range as time goes on.

This will wear off when JJ has made a few more posts, in the meantime we would do well to look right back through the thread first before adding anything new.
SiriusHardware is offline   Reply With Quote
Old 12th May 2021, 5:12 pm   #17
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 923
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Quote:
Originally Posted by TonyDuell View Post
If you are desperate I can probably find a spare reel (1000 feet) of 1" (8 data tracks + sprocket track when punched) tape. I use it on serveral of my computers, so I don't want to give up all the stock I have, but the odd reel would be OK

Other than the issue of knowing where to start (perhaps assume the first character to load is non-zero, or skip the to the first non-zero character, ignore it, and read valid characters after that point) there is no reason not to use the 8 rows of data holes as 8 bits, and that will simplify the loader. For various reasons I've not looked at the video linked to above, is there any clue as to what the loader software consists of?
Tony - if you could spare a few feet for me for experimenting with my hand punch it would be appreciated!

The loader is clearly visible in a few frames:

Click image for larger version

Name:	MK14PaperTapeB.jpg
Views:	13
Size:	31.6 KB
ID:	233876

By the way for those who generally avoid youtube (I am sure you do not avoid my channel ) I really like Jerry's channel and it is well worth a watch, he has recently fully restored an ASR33 and sometime ago restored a tape punch mechanism. His series on how core memory works - which he admits is to drum up interest in his book and a kit was still really well done and enjoyable...
Timbucus is offline   Reply With Quote
Old 12th May 2021, 5:28 pm   #18
Mark1960
Hexode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 459
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Its been a very long time since I last used paper tape so this might be a stupid question. Does the unused paper tape already have sprocket holes? Or are the sprocket holes punched by the tape punch?

Just curious if Tim’s manual punch would be able to use blank tape, or can only be used to edit tape that was already punched on a machine.
Mark1960 is offline   Reply With Quote
Old 12th May 2021, 5:50 pm   #19
Timbucus
Heptode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 923
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

Quote:
Originally Posted by Mark1960 View Post
Its been a very long time since I last used paper tape so this might be a stupid question. Does the unused paper tape already have sprocket holes? Or are the sprocket holes punched by the tape punch?

Just curious if Timís manual punch would be able to use blank tape, or can only be used to edit tape that was already punched on a machine.
Normally the punch creates the sprocket holes - my little hand punch has a way to add them but, of course that is to patch tapes not really create several feed of mechanically powered tape with accurate spaced holes as it relies on having some punched tape - it would be hand pulled in my use so not so vital but, good point the few feet from Tony would benefit from having them added.
Timbucus is offline   Reply With Quote
Old 13th May 2021, 3:45 am   #20
TonyDuell
Dekatron
 
Join Date: Jun 2015
Location: Biggin Hill, London, UK.
Posts: 4,182
Default Re: MK14 computer with a OK-80a paper tape reader - what data required for the paper

FWIW the ASR33 punch (and reader) are horrible things.... I certainly wouldn't use either for working with a lot of data. And I wouldn't put any tape I cared about on said reader, it's roughly like playing a rare LP on a Dansette with a mono cartridge (!)

Blank tape (as in the new reels I have) is totally unpunched, but I can easily run off a few feet of tape with sprocket holes on one of my punches. Incidentally the hole spacing for normal (not 'typesetter') tape is on a 0.1" matrix so bits of stripboard can be used to make splicing jigs, etc.
TonyDuell is offline   Reply With Quote
Reply

Thread Tools



All times are GMT. The time now is 1:48 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2021, vBulletin Solutions, Inc.
Copyright ©2002 - 2021, Paul Stenning.