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.

On 2022-02-07 01:39, Will Senn wrote:
> 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.

> 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)

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.

> 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?

> 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.

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

It's all with MARK parity.

> 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.

> 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.

> 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]

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]

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

[Will Senn]

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

[Vincent Slyngstad]

On 2/7/2022 7:55 AM, Will Senn wrote:
> 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

[Scott Lurndal]

Will Senn <will...@gmail.com> writes:
> 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]

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.

[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.

[Vincent Slyngstad]

On 2/7/2022 11:37 AM, Will Senn wrote:
> 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]

On 2022-02-07 18:11, Vincent Slyngstad wrote:
> On 2/7/2022 7:55 AM, Will Senn wrote:
>> 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. :-)

> 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.

> 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

[Johnny Billquist]

Hi.

On 2022-02-07 16:55, Will Senn wrote:
> 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 :):

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

> 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.

> 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.

Yes.

> 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.

> 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.

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

> 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.

> 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?

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

[Johnny Billquist]

On 2022-02-07 22:01, Vincent Slyngstad wrote:
> On 2/7/2022 11:37 AM, Will Senn wrote:
>> 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.

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).

> 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...

> 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.

> 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.

> 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.

> 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...

> 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

[Roger Ivie]

On Sunday, February 6, 2022 at 4:39:26 PM UTC-8, will...@gmail.com wrote:
>
> 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.
--
roger ivie
roger...@gmail.com

[Vincent Slyngstad]

On 2/7/2022 6:59 PM, Johnny Billquist wrote:
> On 2022-02-07 22:01, Vincent Slyngstad wrote:
>> 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.

>> 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.

>> 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).

>> 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]

On 2022-02-08 04:33, Vincent Slyngstad wrote:
> On 2/7/2022 6:59 PM, Johnny Billquist wrote:
>> On 2022-02-07 22:01, Vincent Slyngstad wrote:
>>> 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.

>>> 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...

>>> 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).

>>> 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

[Scott Lurndal]

Johnny Billquist <b...@softjar.se> writes:
>On 2022-02-07 18:11, Vincent Slyngstad wrote:
>> On 2/7/2022 7:55 AM, Will Senn wrote:
>>> 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. :-)
>
>> 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.

[Scott Lurndal]

Johnny Billquist <b...@softjar.se> writes:
>Hi.

>> 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

[hb9aik]

[dave_th...@comcast.net]

On Tue, 8 Feb 2022 02:49:04 +0100, Johnny Billquist <b...@softjar.se>
wrote:

> On 2022-02-07 18:11, Vincent Slyngstad wrote:

> > 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.

> 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.