> "Interestingly, MS-DOS also has a separate paper punch API."
Where did he pull that one from? No such thing that I'm aware of, and I've had my share of poring over MS-DOS API docs. If you wanted to talk to a paper punch using nothing but DOS, you'd likely have to do it over the serial port at COM1/2, which used the same generic I/O device API as the console (CON)... hence the ability to "CTTY" to those devices.
MS-DOS did implement CP/M function calls (along with the CALL 5 interface itself) to simplify porting code, even when those calls were meaningless in DOS and only returned dummy values. But this paper tape stuff doesn't seem to exist anywhere in DOS, which in turn makes me skeptical about it being in CP/M. When you think about it, it would've been an inexcusable waste to implement such a thing in either of them - seeing as they were disk operating systems, which (as the article points out) had every reason to be as minimal as possible.
Besides, if it was there in MS-DOS, you'd think Ralf Brown would know about it.
Starting with MS-DOS 2.0, a program has five open files available to it [1], stdin, stdout, stderr, stdaux and stdprn. By default, the first three point to the CON: device, stdaux to the AUX: device (usually the serial port) and stdprn to PRN:. I suppose a paper tape punch could be either AUX: or PRN:, but the reference I'm using (_The MS-DOS Encyclopedia_) doesn't have a reference for a paper tape at all.
[1] Much like Unix programs have three open files.
The paper punch saw wide use in two areas I have some experience with.
Amazingly, I handled paper tape punch stuff until the very early 00's!
I actually love paper tape. It is just fun, and it features an actual bit bucket with punched out bits in it! Good for all manner of work place tomfoolery, but I digress.
Tapes were typically read up to about 9600 baud (fast), with most at half that or less. Punching was 1200 tops if you cared about your gear and uses the black paper tape infused with lubricants.
The most common in manufacturing was Gcode punched to tape as 7 bit ASCII. Most punches could do 8 bits, so it also saw use as file storage, say master data read in to generate specific machine data.
One example I can cite was sheet metal CNC punch programming on a Tek storage tube computer. The application was read from tape and had various modules. Edit, backplot, generate gcode from master, archive, etc...
User would input tool lists and source gcode. That got written to paper tape much like a floppy drive would be used. Then it could be used to generate an actual gcode tape for a real machine. Load the backplotter, then feed it a tool list from paper tape and then the long program tape.
Being a storage tube, the system would simply draw all the tool punches to the screen so the programmer could see the result, correct errors and such. This was a lot more robust than one might imagine. The Tektronix model I used had a 1024x1024 vector space. Some of those could do 4k vector spaces on a large tube. Manage brightness, and it was pretty much effective resolution.
Then take the finished tape to the machine! Really old ones had no program memory, so they literally read the same tape, formed into a loop, over and over to make parts.
Newer ones would read it into their program memory and run from there.
The reason for a separate API may just be due to punches and readers only being streaming character or byte devices.
Start reading might be operator assisted or automatic depending on the punch / reader and how the operator configured it. Often, the read would be initiated in software, then an operator presses a go button.
Flow control is a thing. Readers and punches will stop and start xon xoff ctrl q ctrl s style too. Edit: Nope. It is RTS, CTS hardware signals in almost all cases. Whoops!
A tape can be punched with block formatting of course. I never saw this happen.
Gcodes can be block expressions!
;This is a comment[eob]
O1324 ;Program number[eob]
G1 X12 Y13[eob]
G3 X50.1 Y3.2343 R12.1 A30.6[eob]
But they are variable and can reach darn near a page of ASCII text (256 bytes )for a single code, but the average might be 32.
Where did he pull that one from? No such thing that I'm aware of, and I've had my share of poring over MS-DOS API docs. If you wanted to talk to a paper punch using nothing but DOS, you'd likely have to do it over the serial port at COM1/2, which used the same generic I/O device API as the console (CON)... hence the ability to "CTTY" to those devices.
MS-DOS did implement CP/M function calls (along with the CALL 5 interface itself) to simplify porting code, even when those calls were meaningless in DOS and only returned dummy values. But this paper tape stuff doesn't seem to exist anywhere in DOS, which in turn makes me skeptical about it being in CP/M. When you think about it, it would've been an inexcusable waste to implement such a thing in either of them - seeing as they were disk operating systems, which (as the article points out) had every reason to be as minimal as possible.
Besides, if it was there in MS-DOS, you'd think Ralf Brown would know about it.
[1] Much like Unix programs have three open files.
In MSDOS, I was able to use:
A mode line may be needed, and was with a tape punch:
MODE COM3:1200,N,8,1,P
And then, given the cable is setup to exchange the flow control signals: RTS, CTS
Then in MSDOS, this would work:
COPY GCODE.TXT COM3
The punch would start cutting paper tape.
I never did the reverse. Not sure how in MSDOS. I used PROCOM then clean up the capture and save to file.
And if one wants a binary, the /B option is needed so MSDOS will send 8 bits, not 7
Amazingly, I handled paper tape punch stuff until the very early 00's!
I actually love paper tape. It is just fun, and it features an actual bit bucket with punched out bits in it! Good for all manner of work place tomfoolery, but I digress.
Tapes were typically read up to about 9600 baud (fast), with most at half that or less. Punching was 1200 tops if you cared about your gear and uses the black paper tape infused with lubricants.
The most common in manufacturing was Gcode punched to tape as 7 bit ASCII. Most punches could do 8 bits, so it also saw use as file storage, say master data read in to generate specific machine data.
One example I can cite was sheet metal CNC punch programming on a Tek storage tube computer. The application was read from tape and had various modules. Edit, backplot, generate gcode from master, archive, etc...
User would input tool lists and source gcode. That got written to paper tape much like a floppy drive would be used. Then it could be used to generate an actual gcode tape for a real machine. Load the backplotter, then feed it a tool list from paper tape and then the long program tape.
Being a storage tube, the system would simply draw all the tool punches to the screen so the programmer could see the result, correct errors and such. This was a lot more robust than one might imagine. The Tektronix model I used had a 1024x1024 vector space. Some of those could do 4k vector spaces on a large tube. Manage brightness, and it was pretty much effective resolution.
Then take the finished tape to the machine! Really old ones had no program memory, so they literally read the same tape, formed into a loop, over and over to make parts.
Newer ones would read it into their program memory and run from there.
Start reading might be operator assisted or automatic depending on the punch / reader and how the operator configured it. Often, the read would be initiated in software, then an operator presses a go button.
Flow control is a thing. Readers and punches will stop and start xon xoff ctrl q ctrl s style too. Edit: Nope. It is RTS, CTS hardware signals in almost all cases. Whoops!
A tape can be punched with block formatting of course. I never saw this happen.
Gcodes can be block expressions!
;This is a comment[eob]
O1324 ;Program number[eob]
G1 X12 Y13[eob]
G3 X50.1 Y3.2343 R12.1 A30.6[eob]
But they are variable and can reach darn near a page of ASCII text (256 bytes )for a single code, but the average might be 32.