keyboard scancodes, ascii, asr33, and os/8

[Will Senn]

All,

I have been working to get my mind wrapped around how the sending of key presses to OS/8 work. I'm not really understanding what's going on at what level. I press a key combination on my mac, in the simulated ASR33. Something get's generated (I'm guessing the source code is definitive for what), OS/8 receives something (I'm guessing based on the OS/8 handbook that this is an 8-bit ascii keycode in the range 000-377. I can pretty much predict what's gonna happen if I type an uppercase letter or a punctuation character, but lower case letters appear to be ignored. Also, I'm a little lost as to how to generate characters like Leader/Trailer (or why I might want to) or FORM, or Blank, or RUBOUT (fnDelete on the Mac, but this appears to be the sim, not a standard control sequence)... After some painstaking research on what ASCII is (surprisingly little quality discussion of it is out there, and asking around, I figure out that I could use CONTROL-letter to send some of the control characters that are understood by OS/8 - CTRL-J for LINE FEED, CTRL-G for BELL (this appears to be related to the ASCII itself, not just an arbitrary mapping).

The chart in the handbook (and elsewhere) shows characters I would expect to see plus this list (I added the binary and the 7bit octal interpretation in parens following):
11 011 110 - Arrow up, open paren, carat, close paren, superscript 2 (whatever that's supposed to represent ): 336 (136)
11 011 111 - Arrow left, open paren, underscore, close paren, superscript 2 (whatever that's supposed to represent ): 337 (137)
10 000 000 - Leader/Trailer: 200 (0)
10 001 010 - LINE FEED: 212 (12)
10 001 101 - Carriage RETURN: 215 (15)
10 100 000 - SPACE: 240 (40)
11 111 111 - RUBOUT: 377 (177)
00 000 000 - Blank: 0 (0)
10 000 111 - BELL: 207 (7)
10 001 001 - TAB: 211 (11)
10 001 100 - FORM: 214 (14)

At first, I was l confused by the big numbers. Then I figured it out:

A is shown to be 301 in the table, which is 11 000 001 binary. This is 193 in decimal (way bigger than 127, which is what I thought the biggest character was supposed to be. This is why, when working with DEC stuff, you should stick to octal. So, since A is 101, in octal (65 in decimal), it looks like it's off by 200 octal. Subtract 200 from anything in the list and it looks like it maps back to modern ASCII pretty well.

I still don't know why RUBOUT needs to be fn-DEL, what Blank is, or those Arrow key things, or the Leader/Trailer stuff.


Anyhow, my question is - where's a good source of information on what's going on with the ASR33 -> OS/8 side of things.... other than the ASR33 manuals which go into WAY too much detail about levers and tines and such?

Later,

Will

[Johnny Billquist]

There is pretty much no discussions about ASCII because everyone is
assumed to already know what it is.

See https://en.wikipedia.org/wiki/ASCII if you need more information.
I'm surprised you didn't figure out to check on Wikipedia if you wanted
to know what ASCII is. If you Google for ASCII, you'll find plenty of
information as well. So I don't know how you could not have found
information.

Next you need to understand what an ASR33 is, which you also seem to not
have tried to find out. An ASR33 was one of the first terminals
available that used ASCII. It was a printing terminal, and it *do not*
have lowercase characters. So no surprise if you emulate one, you will
not have lowercase characters.

Another thing about the ASR33 is that it by standard uses MARK parity.
ASCII is a 7 bit code. And then you have one parity bit, which the ASR33
always sets to 1. So all codes will be in the range 128 to 255 (decimal).

About control characters, I guess you have never wondered why there is a
key marked "control", or what it does. Exactly what different control
characters might do depends on the software.

A few additional comments below.

Post by Will Senn
All,
I have been working to get my mind wrapped around how the sending of key presses to OS/8 work.
I'm not really understanding what's going on at what level. I press a key combination on my mac,
in the simulated ASR33. Something get's generated (I'm guessing the source code is definitive for what),
OS/8 receives something (I'm guessing based on the OS/8 handbook that this is an 8-bit ascii keycode
in the range 000-377. I can pretty much predict what's gonna happen if I type an uppercase letter or
a punctuation character, but lower case letters appear to be ignored. Also, I'm a little lost as to how
to generate characters like Leader/Trailer (or why I might want to) or FORM, or Blank, or RUBOUT
(fnDelete on the Mac, but this appears to be the sim, not a standard control sequence)... After some
painstaking research on what ASCII is (surprisingly little quality discussion of it is out there, and
asking around, I figure out that I could use CONTROL-letter to send some of the control characters that
are understood by OS/8 - CTRL-J for LINE FEED, CTRL-G for BELL (this appears to be related to the
ASCII itself, not just an arbitrary mapping).

There are *no* arbitrary mappings.

Post by Will Senn
11 011 110 - Arrow up, open paren, carat, close paren, superscript 2 (whatever that's supposed to represent ): 336 (136)

Are you not able to read plan books with footnotes? 136 is shown to be
an UPARROW, and then you have a footnote saying that the character in
parenthesis might be shown by some models of ASR33. The story behind
this is that 136 was originally UPARROW but in the ASCII table, it was
later replaced by the caret character.

Post by Will Senn
11 011 111 - Arrow left, open paren, underscore, close paren, superscript 2 (whatever that's supposed to represent ): 337 (137)

Same story here: LEFTARROW, later replaced by underscore. Really, how
hard can it be to understand a footnote?

Post by Will Senn
10 000 000 - Leader/Trailer: 200 (0)
10 001 010 - LINE FEED: 212 (12)
10 001 101 - Carriage RETURN: 215 (15)
10 100 000 - SPACE: 240 (40)
11 111 111 - RUBOUT: 377 (177)
00 000 000 - Blank: 0 (0)
10 000 111 - BELL: 207 (7)
10 001 001 - TAB: 211 (11)
10 001 100 - FORM: 214 (14)

There are a whole range of control characters. Basically, every
character from 0-31 (0 - 37 in octal) have a meaning, but they are all
non-printable characters. That's what control characters are.
Some might perform some action when received by the ASR33, such as a LF
advancing the paper by one line, or CR moving the printing head to the
leftmost column. But send towards the operating system, it's all up to
the software to do something if it want to.
It's all with MARK parity.

Post by Will Senn
A is shown to be 301 in the table, which is 11 000 001 binary. This is 193 in decimal (way bigger than 127, which is what I thought the biggest character was supposed to be. This is why, when working with DEC stuff, you should stick to octal. So, since A is 101, in octal (65 in decimal), it looks like it's off by 200 octal. Subtract 200 from anything in the list and it looks like it maps back to modern ASCII pretty well.

It's all standard ASCII. You are just observing the characters with the
included parity.

Post by Will Senn
I still don't know why RUBOUT needs to be fn-DEL, what Blank is, or those Arrow key things, or the Leader/Trailer stuff.

Talk to Apple about that. This has nothing to do with ASCII, PDP-8, OS/8
or ASR33. It's just a question of what Apple decided to interpret the
keys you press on your computer as, when translated to ASCII characters.

The arrow things are just characters. Replaced by caret and underscore
in more modern ASCII (more modern measning something like the end of the
60s.)

The leader/trailer stuff is only relevant for paper tape, which an ASR33
also had, and which was used by PDP-8 software to distribute source code
as well as binaries. And since it could be a hassle to position the
paper tape exactly at the character that started the content, you
usually had a bunch of filler characters at the start of the tape, which
were acting like no-ops. Same at the end. Hence leader/trailer.

Post by Will Senn
Anyhow, my question is - where's a good source of information on what's going on with the ASR33 -> OS/8 side of things.... other than the ASR33 manuals which go into WAY too much detail about levers and tines and such?

I don't understand the question.
When OS/8 sends a character out, the terminal (don't matter what model)
will either display, or act, on the character.
When you press a key on the terminal (don't matter what model) the
corresponding ASCII code will be sent to OS/8, and OS/8 will process it.

There isn't really anything more to it.

Or are you just wondering which control characters OS/8 do something
special with?
If so, see page 1-33 (Using the keyboard monitor) in the OS/8 handbook.

Johnny

[William Cattey]

Post by Johnny Billquist
There is pretty much no discussions about ASCII because everyone is
assumed to already know what it is.
See https://en.wikipedia.org/wiki/ASCII if you need more information.
I'm surprised you didn't figure out to check on Wikipedia if you wanted
to know what ASCII is. If you Google for ASCII, you'll find plenty of
information as well. So I don't know how you could not have found
information.
Next you need to understand what an ASR33 is, which you also seem to not
have tried to find out. An ASR33 was one of the first terminals
available that used ASCII. It was a printing terminal, and it *do not*
have lowercase characters. So no surprise if you emulate one, you will
not have lowercase characters.
Another thing about the ASR33 is that it by standard uses MARK parity.
ASCII is a 7 bit code. And then you have one parity bit, which the ASR33
always sets to 1. So all codes will be in the range 128 to 255 (decimal).
About control characters, I guess you have never wondered why there is a
key marked "control", or what it does. Exactly what different control
characters might do depends on the software.
A few additional comments below.

Post by Will Senn
All,
I have been working to get my mind wrapped around how the sending of key presses to OS/8 work.
I'm not really understanding what's going on at what level. I press a key combination on my mac,
in the simulated ASR33. Something get's generated (I'm guessing the source code is definitive for what),
OS/8 receives something (I'm guessing based on the OS/8 handbook that this is an 8-bit ascii keycode
in the range 000-377. I can pretty much predict what's gonna happen if I type an uppercase letter or
a punctuation character, but lower case letters appear to be ignored. Also, I'm a little lost as to how
to generate characters like Leader/Trailer (or why I might want to) or FORM, or Blank, or RUBOUT
(fnDelete on the Mac, but this appears to be the sim, not a standard control sequence)... After some
painstaking research on what ASCII is (surprisingly little quality discussion of it is out there, and
asking around, I figure out that I could use CONTROL-letter to send some of the control characters that
are understood by OS/8 - CTRL-J for LINE FEED, CTRL-G for BELL (this appears to be related to the
ASCII itself, not just an arbitrary mapping).

There are *no* arbitrary mappings.

Post by Will Senn
11 011 110 - Arrow up, open paren, carat, close paren, superscript 2 (whatever that's supposed to represent ): 336 (136)

Are you not able to read plan books with footnotes? 136 is shown to be
an UPARROW, and then you have a footnote saying that the character in
parenthesis might be shown by some models of ASR33. The story behind
this is that 136 was originally UPARROW but in the ASCII table, it was
later replaced by the caret character.

Post by Will Senn
11 011 111 - Arrow left, open paren, underscore, close paren, superscript 2 (whatever that's supposed to represent ): 337 (137)

Same story here: LEFTARROW, later replaced by underscore. Really, how
hard can it be to understand a footnote?

Post by Will Senn
10 000 000 - Leader/Trailer: 200 (0)
10 001 010 - LINE FEED: 212 (12)
10 001 101 - Carriage RETURN: 215 (15)
10 100 000 - SPACE: 240 (40)
11 111 111 - RUBOUT: 377 (177)
00 000 000 - Blank: 0 (0)
10 000 111 - BELL: 207 (7)
10 001 001 - TAB: 211 (11)
10 001 100 - FORM: 214 (14)

There are a whole range of control characters. Basically, every
character from 0-31 (0 - 37 in octal) have a meaning, but they are all
non-printable characters. That's what control characters are.
Some might perform some action when received by the ASR33, such as a LF
advancing the paper by one line, or CR moving the printing head to the
leftmost column. But send towards the operating system, it's all up to
the software to do something if it want to.
It's all with MARK parity.

Post by Will Senn
A is shown to be 301 in the table, which is 11 000 001 binary. This is 193 in decimal (way bigger than 127, which is what I thought the biggest character was supposed to be. This is why, when working with DEC stuff, you should stick to octal. So, since A is 101, in octal (65 in decimal), it looks like it's off by 200 octal. Subtract 200 from anything in the list and it looks like it maps back to modern ASCII pretty well.

It's all standard ASCII. You are just observing the characters with the
included parity.

Post by Will Senn
I still don't know why RUBOUT needs to be fn-DEL, what Blank is, or those Arrow key things, or the Leader/Trailer stuff.

Talk to Apple about that. This has nothing to do with ASCII, PDP-8, OS/8
or ASR33. It's just a question of what Apple decided to interpret the
keys you press on your computer as, when translated to ASCII characters.
The arrow things are just characters. Replaced by caret and underscore
in more modern ASCII (more modern measning something like the end of the
60s.)
The leader/trailer stuff is only relevant for paper tape, which an ASR33
also had, and which was used by PDP-8 software to distribute source code
as well as binaries. And since it could be a hassle to position the
paper tape exactly at the character that started the content, you
usually had a bunch of filler characters at the start of the tape, which
were acting like no-ops. Same at the end. Hence leader/trailer.

Post by Will Senn
Anyhow, my question is - where's a good source of information on what's going on with the ASR33 -> OS/8 side of things.... other than the ASR33 manuals which go into WAY too much detail about levers and tines and such?

I don't understand the question.
When OS/8 sends a character out, the terminal (don't matter what model)
will either display, or act, on the character.
When you press a key on the terminal (don't matter what model) the
corresponding ASCII code will be sent to OS/8, and OS/8 will process it.
There isn't really anything more to it.
Or are you just wondering which control characters OS/8 do something
special with?
If so, see page 1-33 (Using the keyboard monitor) in the OS/8 handbook.
Johnny

Additionally, under the PiDP-8/i project, Warren and I worked up configurations for PDP-8 SIMH
that are setups for either upper case only environments, or environments that supported lower
case terminals, but wanted to conveniently understand most commands whether typed in
either upper or lower case.

That documentation also talks about dealing with how you demonstrate you deleted a character
you just typed. When OS/8 was first deployed, printing terminals were the vast majority of deployments.
Support for screen-based terminals that made deleted characters vanish was added later.

See our documentation at: https://tangentsoft.com/pidp8i/wiki?name=OS/8+Console+TTY+Setup&p

-Bill

[Will Senn]

Post by William Cattey

Post by Johnny Billquist
There is pretty much no discussions about ASCII because everyone is
assumed to already know what it is.
See https://en.wikipedia.org/wiki/ASCII if you need more information.
I'm surprised you didn't figure out to check on Wikipedia if you wanted
to know what ASCII is. If you Google for ASCII, you'll find plenty of
information as well. So I don't know how you could not have found
information.
Next you need to understand what an ASR33 is, which you also seem to not
have tried to find out. An ASR33 was one of the first terminals
available that used ASCII. It was a printing terminal, and it *do not*
have lowercase characters. So no surprise if you emulate one, you will
not have lowercase characters.
Another thing about the ASR33 is that it by standard uses MARK parity.
ASCII is a 7 bit code. And then you have one parity bit, which the ASR33
always sets to 1. So all codes will be in the range 128 to 255 (decimal).
About control characters, I guess you have never wondered why there is a
key marked "control", or what it does. Exactly what different control
characters might do depends on the software.
A few additional comments below.

Post by Will Senn
All,
I have been working to get my mind wrapped around how the sending of key presses to OS/8 work.
I'm not really understanding what's going on at what level. I press a key combination on my mac,
in the simulated ASR33. Something get's generated (I'm guessing the source code is definitive for what),
OS/8 receives something (I'm guessing based on the OS/8 handbook that this is an 8-bit ascii keycode
in the range 000-377. I can pretty much predict what's gonna happen if I type an uppercase letter or
a punctuation character, but lower case letters appear to be ignored. Also, I'm a little lost as to how
to generate characters like Leader/Trailer (or why I might want to) or FORM, or Blank, or RUBOUT
(fnDelete on the Mac, but this appears to be the sim, not a standard control sequence)... After some
painstaking research on what ASCII is (surprisingly little quality discussion of it is out there, and
asking around, I figure out that I could use CONTROL-letter to send some of the control characters that
are understood by OS/8 - CTRL-J for LINE FEED, CTRL-G for BELL (this appears to be related to the
ASCII itself, not just an arbitrary mapping).

There are *no* arbitrary mappings.

Post by Will Senn
11 011 110 - Arrow up, open paren, carat, close paren, superscript 2 (whatever that's supposed to represent ): 336 (136)

Are you not able to read plan books with footnotes? 136 is shown to be
an UPARROW, and then you have a footnote saying that the character in
parenthesis might be shown by some models of ASR33. The story behind
this is that 136 was originally UPARROW but in the ASCII table, it was
later replaced by the caret character.

Post by Will Senn
11 011 111 - Arrow left, open paren, underscore, close paren, superscript 2 (whatever that's supposed to represent ): 337 (137)

Same story here: LEFTARROW, later replaced by underscore. Really, how
hard can it be to understand a footnote?

Post by Will Senn
10 000 000 - Leader/Trailer: 200 (0)
10 001 010 - LINE FEED: 212 (12)
10 001 101 - Carriage RETURN: 215 (15)
10 100 000 - SPACE: 240 (40)
11 111 111 - RUBOUT: 377 (177)
00 000 000 - Blank: 0 (0)
10 000 111 - BELL: 207 (7)
10 001 001 - TAB: 211 (11)
10 001 100 - FORM: 214 (14)

There are a whole range of control characters. Basically, every
character from 0-31 (0 - 37 in octal) have a meaning, but they are all
non-printable characters. That's what control characters are.
Some might perform some action when received by the ASR33, such as a LF
advancing the paper by one line, or CR moving the printing head to the
leftmost column. But send towards the operating system, it's all up to
the software to do something if it want to.
It's all with MARK parity.

Post by Will Senn
A is shown to be 301 in the table, which is 11 000 001 binary. This is 193 in decimal (way bigger than 127, which is what I thought the biggest character was supposed to be. This is why, when working with DEC stuff, you should stick to octal. So, since A is 101, in octal (65 in decimal), it looks like it's off by 200 octal. Subtract 200 from anything in the list and it looks like it maps back to modern ASCII pretty well.

It's all standard ASCII. You are just observing the characters with the
included parity.

Post by Will Senn
I still don't know why RUBOUT needs to be fn-DEL, what Blank is, or those Arrow key things, or the Leader/Trailer stuff.

Talk to Apple about that. This has nothing to do with ASCII, PDP-8, OS/8
or ASR33. It's just a question of what Apple decided to interpret the
keys you press on your computer as, when translated to ASCII characters.
The arrow things are just characters. Replaced by caret and underscore
in more modern ASCII (more modern measning something like the end of the
60s.)
The leader/trailer stuff is only relevant for paper tape, which an ASR33
also had, and which was used by PDP-8 software to distribute source code
as well as binaries. And since it could be a hassle to position the
paper tape exactly at the character that started the content, you
usually had a bunch of filler characters at the start of the tape, which
were acting like no-ops. Same at the end. Hence leader/trailer.

Post by Will Senn
Anyhow, my question is - where's a good source of information on what's going on with the ASR33 -> OS/8 side of things.... other than the ASR33 manuals which go into WAY too much detail about levers and tines and such?

I don't understand the question.
When OS/8 sends a character out, the terminal (don't matter what model)
will either display, or act, on the character.
When you press a key on the terminal (don't matter what model) the
corresponding ASCII code will be sent to OS/8, and OS/8 will process it.
There isn't really anything more to it.
Or are you just wondering which control characters OS/8 do something
special with?
If so, see page 1-33 (Using the keyboard monitor) in the OS/8 handbook.
Johnny

Additionally, under the PiDP-8/i project, Warren and I worked up configurations for PDP-8 SIMH
that are setups for either upper case only environments, or environments that supported lower
case terminals, but wanted to conveniently understand most commands whether typed in
either upper or lower case.
That documentation also talks about dealing with how you demonstrate you deleted a character
you just typed. When OS/8 was first deployed, printing terminals were the vast majority of deployments.
Support for screen-based terminals that made deleted characters vanish was added later.
See our documentation at: https://tangentsoft.com/pidp8i/wiki?name=OS/8+Console+TTY+Setup&p
-Bill

Brilliant! Thanks. BTW, your work on that site is quite amazing. Some of it's drop dead easy to assimilate, other parts, not so much - very technical. I appreciate the effort you put into it and hope to one day, be able to appreciate it fully.

Will

[Will Senn]

Hi Johnny,

Boy, I must have been really bad about how I asked the question. Of course I know what ASCII is. But, the vast majority of articles that I came across (hundreds) were drivel. The wikipedia article is practically drivel, unless you're just looking for a table and talk about the table. It is pretty much declarative and wanders all over the place in its description, with no real accurate, explicit, discussion of the evolution or history, beyond presenting a chronology... but after reconsideration (and your smackdown on footnotes), I reread it and found a gem in the footnotes :):

Mackenzie, Charles E. (1980). Coded Character Sets, History and Development (PDF). The Systems Programming Series (1 ed.).

I really meant to ask why is it coded the way it is? Which the MacKenzie book answers. As for the ASR 33, I also know what it is, in the general and mechanical sense. I use it in a simulator daily for v6, v7, 4.2, 4.3, RT-11, RSX, sheesh! My question was meant to ask about a very specific aspect of the interface between the ASR33 and OS/8. What codes are sent by the ASR33, how are they sent, and how are they processed on the receiving end.

That said, you definitely answered critical parts of the question (with as much chiding as I did whining):

1. The ASR33 defaults to MARK parity!!!
That explains the range of codes.
2. There are no arbitrary mappings.
This remains to be seen. Hopefully, I can find the logic.
3. ^ was the up arrow and _ was the left arrow!
Obvious in hindsight, thanks!
4. There are 31 non-printable characters
This is reflected in man ascii, so no news there.
5. The ASR33 doesn't have lowercase letters
I believe you, but I don't totally get it given that I thought simh was emulating ASR33 for the console and mixed case works in unix on simh. I must be mistaken. I'll go look into it.
5. The DEC manuals discuss this.
Well, they do, but it's distributed all over the place. I did find a summary, after quite a bit of searching:
Appendix E of the 1974 Software Support Manual-DEC-S8-OSSMB-A-D.

Thanks for answering the previous question. I always do my homework first, then ask. If it doesn't sound like it, chalk it up to inartful asking. To be clear, I don't care what is printed (sent from OS/8) at all. I'm almost afraid to ask, but I'm gonna do it anyway... Do you happen to know how (numerically) the ASR33 converts the control-alpha combinations before sending the 31 control codes? It looks to me like it just masks bit 7 off. Also, is ALTMODE, the same as ESC? When it's pressed, does it change the code before sending?

Thanks!

Will

There is pretty much no discussions about ASCII because everyone is assumed to already know what it is.
See https://en.wikipedia.org/wiki/ASCII if you need more information. I'm surprised you didn't figure out to check on Wikipedia if you wanted to know what ASCII is. If you Google for ASCII, you'll find plenty of information as well. So I don't know how you could not have found information.
Next you need to understand what an ASR33 is, which you also seem to not have tried to find out. An ASR33 was one of the first terminals available that used ASCII. It was a printing terminal, and it *do not* have lowercase characters. So no surprise if you emulate one, you will not have lowercase characters.
Another thing about the ASR33 is that it by standard uses MARK parity. ASCII is a 7 bit code. And then you have one parity bit, which the ASR33 always sets to 1. So all codes will be in the range 128 to 255 (decimal).
About control characters, I guess you have never wondered why there is a key marked "control", or what it does. Exactly what different control characters might do depends on the software.
A few additional comments below.

Post by Will Senn
All,
I have been working to get my mind wrapped around how the sending of key presses to OS/8 work.
I'm not really understanding what's going on at what level. I press a key combination on my mac,
in the simulated ASR33. Something get's generated (I'm guessing the source code is definitive for what),
OS/8 receives something (I'm guessing based on the OS/8 handbook that this is an 8-bit ascii keycode
in the range 000-377. I can pretty much predict what's gonna happen if I type an uppercase letter or
a punctuation character, but lower case letters appear to be ignored. Also, I'm a little lost as to how
to generate characters like Leader/Trailer (or why I might want to) or FORM, or Blank, or RUBOUT
(fnDelete on the Mac, but this appears to be the sim, not a standard control sequence)... After some
painstaking research on what ASCII is (surprisingly little quality discussion of it is out there, and
asking around, I figure out that I could use CONTROL-letter to send some of the control characters that
are understood by OS/8 - CTRL-J for LINE FEED, CTRL-G for BELL (this appears to be related to the
ASCII itself, not just an arbitrary mapping).

There are *no* arbitrary mappings.

Post by Will Senn
11 011 110 - Arrow up, open paren, carat, close paren, superscript 2 (whatever that's supposed to represent ): 336 (136)

Are you not able to read plan books with footnotes? 136 is shown to be an UPARROW, and then you have a footnote saying that the character in parenthesis might be shown by some models of ASR33. The story behind this is that 136 was originally UPARROW but in the ASCII table, it was later replaced by the caret character.

Post by Will Senn
11 011 111 - Arrow left, open paren, underscore, close paren, superscript 2 (whatever that's supposed to represent ): 337 (137)

Same story here: LEFTARROW, later replaced by underscore. Really, how hard can it be to understand a footnote?

Post by Will Senn
10 000 000 - Leader/Trailer: 200 (0)
10 001 010 - LINE FEED: 212 (12)
10 001 101 - Carriage RETURN: 215 (15)
10 100 000 - SPACE: 240 (40)
11 111 111 - RUBOUT: 377 (177)
00 000 000 - Blank: 0 (0)
10 000 111 - BELL: 207 (7)
10 001 001 - TAB: 211 (11)
10 001 100 - FORM: 214 (14)

There are a whole range of control characters. Basically, every character from 0-31 (0 - 37 in octal) have a meaning, but they are all non-printable characters. That's what control characters are.
Some might perform some action when received by the ASR33, such as a LF advancing the paper by one line, or CR moving the printing head to the leftmost column. But send towards the operating system, it's all up to the software to do something if it want to.
It's all with MARK parity.

Post by Will Senn
A is shown to be 301 in the table, which is 11 000 001 binary. This is 193 in decimal (way bigger than 127, which is what I thought the biggest character was supposed to be. This is why, when working with DEC stuff, you should stick to octal. So, since A is 101, in octal (65 in decimal), it looks like it's off by 200 octal. Subtract 200 from anything in the list and it looks like it maps back to modern ASCII pretty well.

It's all standard ASCII. You are just observing the characters with the included parity.

Post by Will Senn
I still don't know why RUBOUT needs to be fn-DEL, what Blank is, or those Arrow key things, or the Leader/Trailer stuff.

Talk to Apple about that. This has nothing to do with ASCII, PDP-8, OS/8 or ASR33. It's just a question of what Apple decided to interpret the keys you press on your computer as, when translated to ASCII characters.
The arrow things are just characters. Replaced by caret and underscore in more modern ASCII (more modern measning something like the end of the 60s.)
The leader/trailer stuff is only relevant for paper tape, which an ASR33 also had, and which was used by PDP-8 software to distribute source code as well as binaries. And since it could be a hassle to position the paper tape exactly at the character that started the content, you usually had a bunch of filler characters at the start of the tape, which were acting like no-ops. Same at the end. Hence leader/trailer.

Post by Will Senn
Anyhow, my question is - where's a good source of information on what's going on with the ASR33 -> OS/8 side of things.... other than the ASR33 manuals which go into WAY too much detail about levers and tines and such?

I don't understand the question.
When OS/8 sends a character out, the terminal (don't matter what model) will either display, or act, on the character.
When you press a key on the terminal (don't matter what model) the corresponding ASCII code will be sent to OS/8, and OS/8 will process it.
There isn't really anything more to it.
Or are you just wondering which control characters OS/8 do something special with?
If so, see page 1-33 (Using the keyboard monitor) in the OS/8 handbook.
Johnny

[Vincent Slyngstad]

Post by Will Senn
It looks to me like it just masks bit 7 off. Also, is ALTMODE, the same as ESC? When it's pressed, does it change the code before sending?

We number the bits from the other/wrong end here in PDP-8 land. (There
are 12 of them, with bit 11 as LSB.)

ALTMODE is not generally the ESC (\033) code. It's the older ALTMODE
code (\176). It's not unusual, though, to choose to remap the ESC key
to ALTMODE so that it can be typed more naturally on modern keyboards.

Some of the software is new enough (well, a couple of programs) to even
accept ESC as an alternate for ALTMODE.

Vince

[Will Senn]

Post by Vincent Slyngstad

Post by Will Senn
It looks to me like it just masks bit 7 off. Also, is ALTMODE, the same as ESC? When it's pressed, does it change the code before sending?

We number the bits from the other/wrong end here in PDP-8 land. (There
are 12 of them, with bit 11 as LSB.)
ALTMODE is not generally the ESC (\033) code. It's the older ALTMODE
code (\176). It's not unusual, though, to choose to remap the ESC key
to ALTMODE so that it can be typed more naturally on modern keyboards.
Some of the software is new enough (well, a couple of programs) to even
accept ESC as an alternate for ALTMODE.
Vince

Hi Vince, thanks, for the info about bit order and ALT. Scott's pointer to the Small Computer Handbook has a wealth of information related to the topic. I'm off to reading up some more.

[Vincent Slyngstad]

Post by Will Senn
Hi Vince, thanks, for the info about bit order and ALT. Scott's pointer to the Small Computer Handbook has a wealth of information related to the topic. I'm off to reading up some more.

A couple other notes of clarification, for other folks headed down this
path:

The 7-bits and Mark Parity are actually features of the model 33 TTY
keyboard. The teleprinter mechanism ignores the MSB entirely, and the
data path is actually 8 bits and no parity. The 8 bit data path becomes
important in the discussion of the ASR-33 tape reader and punch.

The actual parity generation of the keyboard, the treatment of
ESC/ALTMODE, up-arrow, left-arrow, and a few other oddities were
actually configurable when you ordered your model 33. So what we are
talking about is the ASR-33 as intended/sold by DEC for use with a PDP-8.

As far as protocol issues, one must remember that the PDP-8 dates from a
time when transistors were more expensive and less reliable than wire.
As a result, there are *no* extra transistors in there. This means
there's no FIFO, no XON/XOFF (unless you implemented it in software),
and no buffering at all.

The BIN and RIM paper tape loaders impose an interpretation on the data
that isn't ASCII, but again, it is done in the software.

Also, the entire standard PDP-8 has 48K *bits*, which isn't a lot of
space for sophisticated software. As a result, most protocol stuff is
missing in the software, too. Much of the software doesn't fold upper
case, doesn't even ignore the parity bit, etc.

Hardware flow control, on the PDP-8 *input* side, is implemented, with a
couple of extra transistors and the reader-run relay :-). There is no
output flow control at all. It became common practice to know the
limits of your output device, and send extra nulls, etc. to allow for
slow operations.

The model 33 teleprinter, mostly, has no such problems. The only
requirement is that carriage return is slow, but it is independent from
the line-feed mechanism, so sending line-feed suffices to provide the
required delay.

Vince

[Johnny Billquist]

Post by Vincent Slyngstad

Post by Will Senn
Hi Vince, thanks, for the info about bit order and ALT. Scott's
pointer to the Small Computer Handbook has a wealth of information
related to the topic. I'm off to reading up some more.

A couple other notes of clarification, for other folks headed down this
The 7-bits and Mark Parity are actually features of the model 33 TTY
keyboard.  The teleprinter mechanism ignores the MSB entirely, and the
data path is actually 8 bits and no parity.  The 8 bit data path becomes
important in the discussion of the ASR-33 tape reader and punch.

Well, you could argue that the printer mechanism was 8 bits no parity,
or 7 bit and whatever parity. It all ends up the same way, since the
ASR33 don't actually have any parity checking or generation normally (I
have some vague recollection that it was optionally available, but I
could be misremembering).

Post by Vincent Slyngstad
The actual parity generation of the keyboard, the treatment of
ESC/ALTMODE, up-arrow, left-arrow, and a few other oddities were
actually configurable when you ordered your model 33.  So what we are
talking about is the ASR-33 as intended/sold by DEC for use with a PDP-8.

Yes. Or actually for any DEC computer. DEC had the same variant for all
systems. Nothing PDP-8 unique about it.

But I think it actually mattered if you ordered one with or without the
paper tape option. Without, you got it with mark parity. If you had the
paper tape, I seem to remember it didn't. But maybe if differed if the
data came from the keyboard or the paper tape reader... I really should
re-check some manuals here...

Post by Vincent Slyngstad
As far as protocol issues, one must remember that the PDP-8 dates from a
time when transistors were more expensive and less reliable than wire.
As a result, there are *no* extra transistors in there.  This means
there's no FIFO, no XON/XOFF (unless you implemented it in software),
and no buffering at all.

The same is true for PDP-11 and VAX as well (well, flow control that is,
some newer hardware did have FIFOs). So it don't have much to do with
the age of things, but more with the design philosophy of DEC. They
usually never used hardware flow control, because that actually didn't
exist in the RS-232 standard.

Post by Vincent Slyngstad
The BIN and RIM paper tape loaders impose an interpretation on the data
that isn't ASCII, but again, it is done in the software.

BIN and RIM deals with binary stuff for a PDP-8, which is a 12 bit
system. So obviously not compatible with ASCII at that level.

Post by Vincent Slyngstad
Also, the entire standard PDP-8 has 48K *bits*, which isn't a lot of
space for sophisticated software.  As a result, most protocol stuff is
missing in the software, too.  Much of the software doesn't fold upper
case, doesn't even ignore the parity bit, etc.

Plenty of space to do these things if you wanted to, and newer versions
of things like OS/8 do a lot more of this. But old software was more
primitive. Perhaps because they hadn't seen it as a problem yet.

Post by Vincent Slyngstad
Hardware flow control, on the PDP-8 *input* side, is implemented, with a
couple of extra transistors and the reader-run relay :-).  There is no
output flow control at all.  It became common practice to know the
limits of your output device, and send extra nulls, etc. to allow for
slow operations.

The input flow control for the ASR33 is kindof an hack (I think), which
I think only existed on the 8/i (and earlier?). I don't think the KL8E
or KL8JA have it, but I could be misremembering.

Basically the serial receiver had a busy signal, which was pretty much
equivalent to the reader flag you could see in software, which went back
to the ASR33 for the paper reader to advance it to the next character.
I don't believe it prevents you from continue typing...

Post by Vincent Slyngstad
The model 33 teleprinter, mostly, has no such problems.  The only
requirement is that carriage return is slow, but it is independent from
the line-feed mechanism, so sending line-feed suffices to provide the
required delay.

Well, it can only run at 110bps anyway, which gives quite a lot of time
to do things. But if you just passed a CR, and tried to print stuff, and
the head was at the right end, I suspect it did loose characters. (There
is no hard requirement that you send an LF just because you sent a CR.)

Johnny

[Vincent Slyngstad]

Post by Johnny Billquist

Post by Vincent Slyngstad
The actual parity generation of the keyboard, the treatment of
ESC/ALTMODE, up-arrow, left-arrow, and a few other oddities were
actually configurable when you ordered your model 33.  So what we are
talking about is the ASR-33 as intended/sold by DEC for use with a PDP-8.

Yes. Or actually for any DEC computer. DEC had the same variant for all
systems. Nothing PDP-8 unique about it.
But I think it actually mattered if you ordered one with or without the
paper tape option. Without, you got it with mark parity. If you had the
paper tape, I seem to remember it didn't. But maybe if differed if the
data came from the keyboard or the paper tape reader... I really should
re-check some manuals here...

The keyboards DEC used generate mark parity in the ASR models too. The
tape readers and punches, though, treat the "parity" bit as data.

Post by Johnny Billquist

Post by Vincent Slyngstad
Also, the entire standard PDP-8 has 48K *bits*, which isn't a lot of
space for sophisticated software.  As a result, most protocol stuff is
missing in the software, too.  Much of the software doesn't fold upper
case, doesn't even ignore the parity bit, etc.

Plenty of space to do these things if you wanted to, and newer versions
of things like OS/8 do a lot more of this. But old software was more
primitive. Perhaps because they hadn't seen it as a problem yet.

Yes and no. Certainly room enough to do them, but the 128 word pages
and other restrictions meant it was often tough to do everything in 4K
words.

If you want to run OS/8, you have to have at least twice the memory.

Post by Johnny Billquist

Post by Vincent Slyngstad
Hardware flow control, on the PDP-8 *input* side, is implemented, with
a couple of extra transistors and the reader-run relay :-).  There is
no output flow control at all.  It became common practice to know the
limits of your output device, and send extra nulls, etc. to allow for
slow operations.

The input flow control for the ASR33 is kindof an hack (I think), which
I think only existed on the 8/i (and earlier?). I don't think the KL8E
or KL8JA have it, but I could be misremembering.

They do, though not everyone uses it, particularly since it's a current
loop thing. Almost no-one bothers to convert it to EIA (and it's not
clear there's a standard way to do it even if you want to).

Post by Johnny Billquist

Post by Vincent Slyngstad
The model 33 teleprinter, mostly, has no such problems.  The only
requirement is that carriage return is slow, but it is independent
from the line-feed mechanism, so sending line-feed suffices to provide
the required delay.

Well, it can only run at 110bps anyway, which gives quite a lot of time
to do things. But if you just passed a CR, and tried to print stuff, and
the head was at the right end, I suspect it did loose characters. (There
is no hard requirement that you send an LF just because you sent a CR.)

True, but if you don't send something after the CR, the next character
will likely appear elsewhere than the left edge. (The mechanism will
print it, if it's a printable character.)

Vince

[Johnny Billquist]

Post by Johnny Billquist

Post by Vincent Slyngstad
The actual parity generation of the keyboard, the treatment of
ESC/ALTMODE, up-arrow, left-arrow, and a few other oddities were
actually configurable when you ordered your model 33.  So what we are
talking about is the ASR-33 as intended/sold by DEC for use with a PDP-8.

Yes. Or actually for any DEC computer. DEC had the same variant for
all systems. Nothing PDP-8 unique about it.
But I think it actually mattered if you ordered one with or without
the paper tape option. Without, you got it with mark parity. If you
had the paper tape, I seem to remember it didn't. But maybe if
differed if the data came from the keyboard or the paper tape
reader... I really should re-check some manuals here...

The keyboards DEC used generate mark parity in the ASR models too.  The
tape readers and punches, though, treat the "parity" bit as data.

Obviously the paper tape is 8-bit clean. Otherwise a lot of things would
not work. :-)
Which is why I was trying to remember if there actually was some
difference in the equipment if your ASR33 was equipped with the paper
tape or not. I do seem to remember reading somewhere that there was, but
I haven't tried locate the documentation again. It was something
somewhere in the ASR33 manuals, if my brain is to be trusted.

Post by Johnny Billquist

Post by Vincent Slyngstad
Also, the entire standard PDP-8 has 48K *bits*, which isn't a lot of
space for sophisticated software.  As a result, most protocol stuff
is missing in the software, too.  Much of the software doesn't fold
upper case, doesn't even ignore the parity bit, etc.

Plenty of space to do these things if you wanted to, and newer
versions of things like OS/8 do a lot more of this. But old software
was more primitive. Perhaps because they hadn't seen it as a problem yet.

Yes and no.  Certainly room enough to do them, but the 128 word pages
and other restrictions meant it was often tough to do everything in 4K
words.

Folding to uppercase is pretty trivial, but sure, it still a couple of
words extra. Masking off parity is really just two words.

Flow control on the other hand is certainly more complex. The OS/8 TTY
device driver does it (among other things), but that is a two page handler.

If you want to run OS/8, you have to have at least twice the memory.

True. But here we are talking about mostly very simple things that can
be done by just about everyone. But fact is that OS/8 added a lot of
these things along the way, which is more about refinement with
experience, and there is not much technical argument against it being
possible. Heck, all OS/8 device drivers needs to live in field 0, and
are not allowed to be more than 2 pages in total.
It's not like you have all 32K to play with for these...

Post by Johnny Billquist

Post by Vincent Slyngstad
Hardware flow control, on the PDP-8 *input* side, is implemented,
with a couple of extra transistors and the reader-run relay :-).
There is no output flow control at all.  It became common practice to
know the limits of your output device, and send extra nulls, etc. to
allow for slow operations.

The input flow control for the ASR33 is kindof an hack (I think),
which I think only existed on the 8/i (and earlier?). I don't think
the KL8E or KL8JA have it, but I could be misremembering.

They do, though not everyone uses it, particularly since it's a current
loop thing.  Almost no-one bothers to convert it to EIA (and it's not
clear there's a standard way to do it even if you want to).

I was trying to remember if that was current loop only. Thanks for
mentioning it.
No, there is no standard way of doing this with EIA (RS-232).

Post by Johnny Billquist

Post by Vincent Slyngstad
The model 33 teleprinter, mostly, has no such problems.  The only
requirement is that carriage return is slow, but it is independent
from the line-feed mechanism, so sending line-feed suffices to
provide the required delay.

Well, it can only run at 110bps anyway, which gives quite a lot of
time to do things. But if you just passed a CR, and tried to print
stuff, and the head was at the right end, I suspect it did loose
characters. (There is no hard requirement that you send an LF just
because you sent a CR.)

True, but if you don't send something after the CR, the next character
will likely appear elsewhere than the left edge.  (The mechanism will
print it, if it's a printable character.)

Yeah. Hence the need for padding characters.

Johnny

[hb9aik]

Post by Johnny Billquist

Post by Vincent Slyngstad

Post by Johnny Billquist

Post by Vincent Slyngstad
The actual parity generation of the keyboard, the treatment of
ESC/ALTMODE, up-arrow, left-arrow, and a few other oddities were
actually configurable when you ordered your model 33. So what we are
talking about is the ASR-33 as intended/sold by DEC for use with a PDP-8.

Yes. Or actually for any DEC computer. DEC had the same variant for
all systems. Nothing PDP-8 unique about it.
But I think it actually mattered if you ordered one with or without
the paper tape option. Without, you got it with mark parity. If you
had the paper tape, I seem to remember it didn't. But maybe if
differed if the data came from the keyboard or the paper tape
reader... I really should re-check some manuals here...

The keyboards DEC used generate mark parity in the ASR models too. The
tape readers and punches, though, treat the "parity" bit as data.

Obviously the paper tape is 8-bit clean. Otherwise a lot of things would
not work. :-)
Which is why I was trying to remember if there actually was some
difference in the equipment if your ASR33 was equipped with the paper
tape or not. I do seem to remember reading somewhere that there was, but
I haven't tried locate the documentation again. It was something
somewhere in the ASR33 manuals, if my brain is to be trusted.

Post by Vincent Slyngstad

Post by Johnny Billquist

Post by Vincent Slyngstad
Also, the entire standard PDP-8 has 48K *bits*, which isn't a lot of
space for sophisticated software. As a result, most protocol stuff
is missing in the software, too. Much of the software doesn't fold
upper case, doesn't even ignore the parity bit, etc.

Plenty of space to do these things if you wanted to, and newer
versions of things like OS/8 do a lot more of this. But old software
was more primitive. Perhaps because they hadn't seen it as a problem yet.

Yes and no. Certainly room enough to do them, but the 128 word pages
and other restrictions meant it was often tough to do everything in 4K
words.

Folding to uppercase is pretty trivial, but sure, it still a couple of
words extra. Masking off parity is really just two words.
Flow control on the other hand is certainly more complex. The OS/8 TTY
device driver does it (among other things), but that is a two page handler.

Post by Vincent Slyngstad
If you want to run OS/8, you have to have at least twice the memory.

True. But here we are talking about mostly very simple things that can
be done by just about everyone. But fact is that OS/8 added a lot of
these things along the way, which is more about refinement with
experience, and there is not much technical argument against it being
possible. Heck, all OS/8 device drivers needs to live in field 0, and
are not allowed to be more than 2 pages in total.
It's not like you have all 32K to play with for these...

Post by Vincent Slyngstad

Post by Johnny Billquist

Post by Vincent Slyngstad
Hardware flow control, on the PDP-8 *input* side, is implemented,
with a couple of extra transistors and the reader-run relay :-).
There is no output flow control at all. It became common practice to
know the limits of your output device, and send extra nulls, etc. to
allow for slow operations.

The input flow control for the ASR33 is kindof an hack (I think),
which I think only existed on the 8/i (and earlier?). I don't think
the KL8E or KL8JA have it, but I could be misremembering.

They do, though not everyone uses it, particularly since it's a current
loop thing. Almost no-one bothers to convert it to EIA (and it's not
clear there's a standard way to do it even if you want to).

I was trying to remember if that was current loop only. Thanks for
mentioning it.
No, there is no standard way of doing this with EIA (RS-232).

Post by Vincent Slyngstad

Post by Johnny Billquist

Post by Vincent Slyngstad
The model 33 teleprinter, mostly, has no such problems. The only
requirement is that carriage return is slow, but it is independent
from the line-feed mechanism, so sending line-feed suffices to
provide the required delay.

Well, it can only run at 110bps anyway, which gives quite a lot of
time to do things. But if you just passed a CR, and tried to print
stuff, and the head was at the right end, I suspect it did loose
characters. (There is no hard requirement that you send an LF just
because you sent a CR.)

True, but if you don't send something after the CR, the next character
will likely appear elsewhere than the left edge. (The mechanism will
print it, if it's a printable character.)

Yeah. Hence the need for padding characters.
Johnny

[Johnny Billquist]

Post by Vincent Slyngstad

Post by Will Senn
It looks to me like it just masks bit 7 off. Also, is ALTMODE, the
same as ESC? When it's pressed, does it change the code before sending?

We number the bits from the other/wrong end here in PDP-8 land. (There
are 12 of them, with bit 11 as LSB.)

Indeed. :-)

Post by Vincent Slyngstad
ALTMODE is not generally the ESC (\033) code.  It's the older ALTMODE
code (\176).  It's not unusual, though,  to choose to remap the ESC key
to ALTMODE so that it can be typed more naturally on modern keyboards.

It's all very confusing actually. There are old ASCII tables that place
ALTMODE at 033 and ESCAPE at 0176 as well. But I'm pretty sure the ASR33
sent 0233 both on models with a key marked ALTMODE and those with a key
marked ESCAPE.

Post by Vincent Slyngstad
Some of the software is new enough (well, a couple of programs) to even
accept ESC as an alternate for ALTMODE.

I guess it was sensible back when you still had ASCII evolving.

Johnny

[Scott Lurndal]

Post by Johnny Billquist

Post by Vincent Slyngstad

Post by Will Senn
It looks to me like it just masks bit 7 off. Also, is ALTMODE, the
same as ESC? When it's pressed, does it change the code before sending?

We number the bits from the other/wrong end here in PDP-8 land. (There
are 12 of them, with bit 11 as LSB.)

Indeed. :-)

Post by Vincent Slyngstad
ALTMODE is not generally the ESC (\033) code.  It's the older ALTMODE
code (\176).  It's not unusual, though,  to choose to remap the ESC key
to ALTMODE so that it can be typed more naturally on modern keyboards.

It's all very confusing actually. There are old ASCII tables that place
ALTMODE at 033 and ESCAPE at 0176 as well. But I'm pretty sure the ASR33
sent 0233 both on models with a key marked ALTMODE and those with a key
marked ESCAPE.

I have an old burroughs reference card for USASCII. On the front,
it has USASCII X3.4-1963, with ESC at 0x7e (0176) and S3 at 0x1b (033).

The flip side of the card shows USASCII X3.4-1967 which moved
ESC to 0x1b and 0x7e becomes the tilde character.

[d***@comcast.net]

Post by Johnny Billquist

Post by Vincent Slyngstad
ALTMODE is not generally the ESC (\033) code.  It's the older ALTMODE
code (\176).  It's not unusual, though,  to choose to remap the ESC key
to ALTMODE so that it can be typed more naturally on modern keyboards.

175.

Post by Johnny Billquist
It's all very confusing actually. There are old ASCII tables that place
ALTMODE at 033 and ESCAPE at 0176 as well. But I'm pretty sure the ASR33
sent 0233 both on models with a key marked ALTMODE and those with a key
marked ESCAPE.

I don't know if there were any options, but the ASR33 my school had
definitely was labelled ALTMODE and sent 375 (175 + mark). Edusystem
BASIC $n, for I don't recall which $n, used it for line delete (!)
which I used pretty frequently including while punching.

[Johnny Billquist]

Hi.

Post by Will Senn
Hi Johnny,

Some of your questions/comments were really on the weird side. :-)

Post by Will Senn
Mackenzie, Charles E. (1980). Coded Character Sets, History and Development (PDF). The Systems Programming Series (1 ed.).
I really meant to ask why is it coded the way it is? Which the MacKenzie book answers. As for the ASR 33, I also know what it is, in the general and mechanical sense. I use it in a simulator daily for v6, v7, 4.2, 4.3, RT-11, RSX, sheesh! My question was meant to ask about a very specific aspect of the interface between the ASR33 and OS/8. What codes are sent by the ASR33, how are they sent, and how are they processed on the receiving end.

As for why ASCII looks like it does, that's a different topic, and one
you seem to have found some information about. Just be glad we didn't
end up with EBCDIC.

Post by Will Senn
1. The ASR33 defaults to MARK parity!!!
That explains the range of codes.

Yes.

Post by Will Senn
2. There are no arbitrary mappings.
This remains to be seen. Hopefully, I can find the logic.

Well, it's arbitrary in that saying that decimal 65 is a capital A is
sortof arbitrary. Having them all in sequence seems to be less
arbitrary, and starting at some power of 2 is (I would say) also a
conscious choice. And having the lowercase letters be off by 32 from the
uppercase is also not arbitrary. Having control characters basically be
the same as the normal letters, but 64 less, is in itself also pretty
straight forward. Having numbers also start at something nicely
divisible by 16 also seems pretty obvious. And the rest of the
punctuations were slightly arbitrary placed for the rest of it. Not
entirely arbitrary, but to some extent...

So if that was what you meant by arbitrary, then yes, it is.
But the mapping between letters and control characters are really just
the letters minus 64. There is nothing arbitrary about that.

Post by Will Senn
3. ^ was the up arrow and _ was the left arrow!
Obvious in hindsight, thanks!

:-)

Post by Will Senn
4. There are 31 non-printable characters
This is reflected in man ascii, so no news there.

There are 33 non-printable characters. But I think you're all good. :-)

Post by Will Senn
5. The ASR33 doesn't have lowercase letters
I believe you, but I don't totally get it given that I thought simh was emulating ASR33 for the console and mixed case works in unix on simh. I must be mistaken. I'll go look into it.

Uh... No. simh do not emulate an ASR33. simh emulates computers, not
terminals. You are then using some terminal program to run simh. Does
that terminal really emulate an ASR33? I suspect not. :-)

But beyond that, you need to look at the actual software running inside
simh, and what it does. If it thinks there is an ASR33 connected, it
might process input and output based on this, or it might not.
simh itself don't care.

Post by Will Senn
5. The DEC manuals discuss this.
Appendix E of the 1974 Software Support Manual-DEC-S8-OSSMB-A-D.
Thanks for answering the previous question. I always do my homework first, then ask. If it doesn't sound like it, chalk it up to inartful asking. To be clear, I don't care what is printed (sent from OS/8) at all. I'm almost afraid to ask, but I'm gonna do it anyway... Do you happen to know how (numerically) the ASR33 converts the control-alpha combinations before sending the 31 control codes? It looks to me like it just masks bit 7 off. Also, is ALTMODE, the same as ESC? When it's pressed, does it change the code before sending?

Yes. When we talk about control characters, it's just when you hold down
the control key, it masks the appropriate bit off. Depending on from
which end you count bits, and what base you use, you might number it
differently, but it's the bit with the value 64. (In the most
traditional numbering, that would be bit 6.)

ALTMODE and ESC was discussed in another post, but the key just sends
one code. Which in the ASR33 is encoded on a comb. Nothing can change it.

Johnny

[Scott Lurndal]

Post by Johnny Billquist
Hi.

Post by Will Senn
2. There are no arbitrary mappings.
This remains to be seen. Hopefully, I can find the logic.

Well, it's arbitrary in that saying that decimal 65 is a capital A is
sortof arbitrary. Having them all in sequence seems to be less
arbitrary, and starting at some power of 2 is (I would say) also a
conscious choice. And having the lowercase letters be off by 32 from the
uppercase is also not arbitrary. Having control characters basically be
the same as the normal letters, but 64 less, is in itself also pretty
straight forward. Having numbers also start at something nicely
divisible by 16 also seems pretty obvious. And the rest of the
punctuations were slightly arbitrary placed for the rest of it. Not
entirely arbitrary, but to some extent...
So if that was what you meant by arbitrary, then yes, it is.
But the mapping between letters and control characters are really just
the letters minus 64. There is nothing arbitrary about that.

If you look at the chart, it becomes much less arbitrary.

https://www.historyofinformation.com/detail.php?id=803

[Scott Lurndal]

All,
I have been working to get my mind wrapped around how the sending of key pr=
esses to OS/8 work.

Many of your questions are answered in chapter 7 section 7-1
of the Small Computer Handbook (1970 edition).

[Will Senn]

Post by Scott Lurndal

All,
I have been working to get my mind wrapped around how the sending of key pr=
esses to OS/8 work.

Many of your questions are answered in chapter 7 section 7-1
of the Small Computer Handbook (1970 edition).

Nice! I have the handbook in pdf and you're correct, it answers a lot of my questions. Thanks for the tip.Sooo many handbooks, sooo many pages to read.

[Roger Ivie]

Post by Will Senn
I still don't know why RUBOUT needs to be fn-DEL, what Blank is, or those Arrow key things, or the Leader/Trailer stuff.

rubout is all holes punched; any character on a paper tape can be rubbed out (turned into a rubout) by punching any
unpunched holes.

blank has no holes punched.

leader/trailer is NUL with bit 7 punched; mark parity lets you tell the difference between blank tape and NUL.