Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PDP8s, UARTs, and ASCII
324 views
Skip to first unread message
Rob Doyle
Jun 23, 2012, 3:48:03 PM6/23/12
to
I'm going through my list of 'loose ends' on my PDP8 FPGA
implementation:
I had noticed that when one version of OS/8 boots, the
first three characters that are sent to the UART are
0x8D, 0x8A, and 0xAE.
Without thinking about it too much, I just zeroed out the
MSB of the UART input and output which gives me the expected
CR, LF, and 'dot' prompt.
I don't think all version of OS/8 that I find does this...
I've got my terminal emulator set to 8-bits, not parity,
1 stop bit - which matches my UART implementation.
Can any body explain why the MSB is set?
Bob.
implementation:
I had noticed that when one version of OS/8 boots, the
first three characters that are sent to the UART are
0x8D, 0x8A, and 0xAE.
Without thinking about it too much, I just zeroed out the
MSB of the UART input and output which gives me the expected
CR, LF, and 'dot' prompt.
I don't think all version of OS/8 that I find does this...
I've got my terminal emulator set to 8-bits, not parity,
1 stop bit - which matches my UART implementation.
Can any body explain why the MSB is set?
Bob.
David Gesswein
Jun 23, 2012, 10:21:33 PM6/23/12
to
In article <Fo2dncS035O1g3vS...@giganews.com>,
(DMS) only works correctly receiving that. The teletype didn't care
what the parity was for printing but frequently the data sent to it is
mark parity also. This is done in software since the hardware is 8 bit.
I haven't paid attention to what software does what with the 8th bit. I
set the terminal to pdp-8 direction to set the 8th bit and strip it
for display.
Rob Doyle <radi...@gmail.com> wrote:
>I'm going through my list of 'loose ends' on my PDP8 FPGA
>implementation:
>
>I had noticed that when one version of OS/8 boots, the
>first three characters that are sent to the UART are
>0x8D, 0x8A, and 0xAE.
>
>I'm going through my list of 'loose ends' on my PDP8 FPGA
>implementation:
>
>I had noticed that when one version of OS/8 boots, the
>first three characters that are sent to the UART are
>0x8D, 0x8A, and 0xAE.
>
>Can any body explain why the MSB is set?
>
Teletypes are commonly 7 bits mark parity. Some early DEC software
>
(DMS) only works correctly receiving that. The teletype didn't care
what the parity was for printing but frequently the data sent to it is
mark parity also. This is done in software since the hardware is 8 bit.
I haven't paid attention to what software does what with the 8th bit. I
set the terminal to pdp-8 direction to set the 8th bit and strip it
for display.
Rob Doyle
Jun 24, 2012, 3:47:12 AM6/24/12
to
drive does not.
I will strip the MSB in the UART. If I ever need to muck with parity, I
can fix that up in the UART as well.
Thanks.
Johnny Billquist
Jun 24, 2012, 5:24:10 AM6/24/12
to
are 8-bit clean.
In general, I recommend that you run with 7M on your terminal when
talking to a PDP8 running OS/8.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Robert Adamson <rwadamsonhotmail<dot>com>
Jun 24, 2012, 4:27:02 PM6/24/12
to
On Sat, 23 Jun 2012 12:48:03 -0700, Rob Doyle <radi...@gmail.com>
wrote:
No really an answer, however if you glance at the Digital handbooks of
the time and the Pocket Reference cards you will note that Digital set
the msb in their ascii lists.
Commonly Digital packed ascii as 2 characters to a word (which is
non-unique) and unpacked it using an algorithm which forced uppercase
and msb. Depending on how lazy or short of space the code writers (or
if they knew that the messages were a particular subset) were they
sometimes shortcut this algorithm.
wrote:
the time and the Pocket Reference cards you will note that Digital set
the msb in their ascii lists.
Commonly Digital packed ascii as 2 characters to a word (which is
non-unique) and unpacked it using an algorithm which forced uppercase
and msb. Depending on how lazy or short of space the code writers (or
if they knew that the messages were a particular subset) were they
sometimes shortcut this algorithm.
Johnny Billquist
Jun 24, 2012, 8:44:55 PM6/24/12
to
characters. That is not enough if you want both lowercase and uppercase,
along with numbers and special characters.
So, in short, SIXBIT does only store uppercase. So it's not a question
about unpacking algorithm, but a simple case of that is all there is in
there. As for setting the MSB, well, that is not neccesary in the
"algorithm" as such, but since most everything back then were in fact
using mark parity, it was pretty natural for DEC to do mark parity as
well...
Johnny Billquist
Jun 24, 2012, 9:34:24 PM6/24/12
to
like this: (Silly PDP8 program)
/ PRINT - Prints SIXBIT string until a ZERO word is encountered.
/ Calling sequence:
/ JMS PRINT
/ <address of SIXBIT string>
/
/ AC is zeroed by this function.
/ Index register 10 is used.
/
PRINT, 0
CLA CMA
TAD I PRINT
DCA 10
ISZ PRINT
PLOOP, TAD I 10
SNA
JMP I PRINT
JMS PWORD
JMP PLOOP
/ PWORD - Prints one SIXBIT word, which consists of two SIXBIT characters.
/ In: AC - Word
/ Out: AC cleared
/
PWORD, 0
DCA TMP
TAD TMP
JMS PSIX
TAD TMP
RTR;RTR;RTR
JMS PSIX
JMP I PWORD
TMP, 0
/ PSIX - Print a SIXBIT character
/ In: AC - SIXBIT character
/ Out: AC cleared
/
PSIX, 0
AND (77
TAD (-40
SPA SZA
TAD (100
TAD (40
JMS PCHAR
JMP I PSIX
/ PCHAR - Print one character
/ In: AC - Character
/ Out: AC cleared
/
PCHAR, 0
TLS
TSF
JMP .-1
CLA
JMP I PCHAR
Now, if you want MARK parity, the TAD (40 should be a TAD (240 instead.
Easy as one, two, three...
I'll leave it as an exercise to implement case switching (you need to
reserve one character for this, popular choice is '@').
Klemens Krause
Jun 25, 2012, 3:57:38 AM6/25/12
to
Rob Doyle wrote:
...
It ignores everything with bit 7 set, with the exeption of 0200 (hex 80)
which is leader, trailer. So if you inadvertandly put a paper tape in
the tape reader with text on it, without bit 7 set and you don't start
the assembler / compiler / texteditor at 0200, but the bin loader at
7700 or 7600 there is a big chance to overload your memory with garbage.
This distinction of text and binary is also usefull for a human, even
he can't read ASCII-text directly from papertape.
This also allows to intermix text, for example writeups for a program
an the program itself, without to have skipping the text.
Later, when paper tape came out of use, this distinction wasn't important
any longer. And most OS/8 oriented software stripped the 7th bit of or
supplemented it, because the PAL-8 assemmbler sets it too. If you want
to make a compare of an incoming character with a literal, the assembler
generates the 7th bit:
TAD ("A
will load 0301 (C1 = 41 + 80) in the AC.
It is possible, that later users which modified system programs like
DIRECT.SV, didn't obey these rules.
Keep in mind that the sources for OS/8 were public. Everyone could
change them and you have no warranty that you got an orignal version.
> I will strip the MSB in the UART. If I ever need to muck with parity, I
> can fix that up in the UART as well.
If you strip the MSB of, many old programs, for example the maindecs, and
if I remember right the RK-formatter won't work. Also PIP will be unable
to transfer .BN-files correctly.
You should strip the UART to 8-bits and no parity.
Klemens
...
>> Teletypes are commonly 7 bits mark parity. Some early DEC software
>> (DMS) only works correctly receiving that. The teletype didn't care
....
>> (DMS) only works correctly receiving that. The teletype didn't care
>> set the terminal to pdp-8 direction to set the 8th bit and strip it
>> for display.
>
> Very strange. The prompt has the MSB set. The directory of the disk
> drive does not.
>
The original reason for that behaviour is the paper tape bin loader:
>> for display.
>
> Very strange. The prompt has the MSB set. The directory of the disk
> drive does not.
>
It ignores everything with bit 7 set, with the exeption of 0200 (hex 80)
which is leader, trailer. So if you inadvertandly put a paper tape in
the tape reader with text on it, without bit 7 set and you don't start
the assembler / compiler / texteditor at 0200, but the bin loader at
7700 or 7600 there is a big chance to overload your memory with garbage.
This distinction of text and binary is also usefull for a human, even
he can't read ASCII-text directly from papertape.
This also allows to intermix text, for example writeups for a program
an the program itself, without to have skipping the text.
Later, when paper tape came out of use, this distinction wasn't important
any longer. And most OS/8 oriented software stripped the 7th bit of or
supplemented it, because the PAL-8 assemmbler sets it too. If you want
to make a compare of an incoming character with a literal, the assembler
generates the 7th bit:
TAD ("A
will load 0301 (C1 = 41 + 80) in the AC.
It is possible, that later users which modified system programs like
DIRECT.SV, didn't obey these rules.
Keep in mind that the sources for OS/8 were public. Everyone could
change them and you have no warranty that you got an orignal version.
> I will strip the MSB in the UART. If I ever need to muck with parity, I
> can fix that up in the UART as well.
if I remember right the RK-formatter won't work. Also PIP will be unable
to transfer .BN-files correctly.
You should strip the UART to 8-bits and no parity.
Klemens
Johnny Billquist
Jun 25, 2012, 5:28:33 AM6/25/12
to
you have any sources for this? Also, that would relate only to input.
We're talking output as well here.
I totally agree with you that it's a bad solution to strip the msb though.
Johnny
Klemens Krause
Jun 25, 2012, 7:19:22 AM6/25/12
to
Johnny Billquist wrote:
> On 2012-06-25 09:57, Klemens Krause wrote:
>> Rob Doyle wrote:
...
> On 2012-06-25 09:57, Klemens Krause wrote:
>> Rob Doyle wrote:
...
> I've never heard any explanation related to the bin loader before. Do
> you have any sources for this? Also, that would relate only to input.
No, sorry. Eventually we have to look in the docu for PDP-5 or even PDP-1?
> you have any sources for this? Also, that would relate only to input.
It's the same question than: "why do cars in continental europe drive
on the right side of the street?" Perhaps because Napoleon ordered it 200
years ago?
Anyway, the bit-7 rule was broken later by the "modern" bin loaders:
Both, bit 7 and bit 6 set, indicate to the loader, that the field address
for storing data in core with more than 4K of memory is set. But this
doesn't harm if text with all bit 7 set is fed to bin loader.
> We're talking output as well here.
A. Punching text in offline mode on the console teletype of my -8, punches
bit 7 = 1.
B. Entering a text from my terminal in my self written text editor, and
punching this text out on the teletype, has bit 7 set to 0.
But the prompt from OS/8 is
0215 / <CR>
0212 / <LF>
0256 / .
C. Loading this text with bit 7 = 0 from the tapereader of the teletype
in the old lineoriented texteditor EDIT works fine.
D. Punching out this text from EDIT on the teletype shows bit 7 = 1.
So the rule is:
Serial lines have to be 8 bit transparent.
Software waiting for text entry should set bit 7 from the serial line to 1.
Software putting out text also should set bit 7 to 1.
Text devices printing or displaying text should ignore bit 7, devices
punching data or text must not ignore bit 7.
But as I wrote, these rules weren't consistent applied by DEC itself:
PIP10, RKLFMT and DTFMT, at least older versions of them want the bit 7
set to 1.
> I totally agree with you that it's a bad solution to strip the msb though.
it should be set on input.
Klemens
Johnny Billquist
Jun 25, 2012, 7:38:58 AM6/25/12
to
> Software waiting for text entry should set bit 7 from the serial line to 1.
to the program. If it want to force mark parity, or if it wants to strip
off parity, if it wants to check if the parity is correct or not, and so
on is pretty much up to the software.
> Software putting out text also should set bit 7 to 1.
should.
> Text devices printing or displaying text should ignore bit 7, devices
> punching data or text must not ignore bit 7.
printing or displaying text should probably actually *check* the parity,
and not just ignore it. :-)
Punchers are normally expected to be 8 bit clean.
> But as I wrote, these rules weren't consistent applied by DEC itself:
> PIP10, RKLFMT and DTFMT, at least older versions of them want the bit 7
> set to 1.
Thus, bit 7 is always 1.
That is documented somewhere, I seem to remember. But I don't have any
reference offhand. I'll browse around later today to see if I can find
references for it.
Klemens Krause
Jun 25, 2012, 8:45:44 AM6/25/12
to
Johnny Billquist wrote:
> On 2012-06-25 13:19, Klemens Krause wrote:
...
> On 2012-06-25 13:19, Klemens Krause wrote:
>> Software waiting for text entry should set bit 7 from the serial line
>> to 1.
>
> You mean when they read data? I would say that that would be totally up
> to the program. If it want to force mark parity, or if it wants to strip
*
This looks like the command line decoder from OS/8, but it isn't, its hard-
coded and wants an entry with bit 7 set. There are other programs with this
behaviour. Naturally if you write your own software it doesn't matter if
you strip bit 7 off or if you set it to 1. But if you want to be stylish
than it is more authentic to set bit 7 to 1, espicially if you're using
PAL.
> off parity, if it wants to check if the parity is correct or not, and so
> on is pretty much up to the software.
>
detecting.
> Well, technically, since we're talking about the parity here, devices
> printing or displaying text should probably actually *check* the parity,
> and not just ignore it. :-)
to be odd or even. Parity mark or space is not of any use. .BN-files use
a block check and KERMIT also.
>
> Punchers are normally expected to be 8 bit clean.
>
the bit 7 really does. Also paper tape reader have to be 8 bit clean.
>> But as I wrote, these rules weren't consistent applied by DEC itself:
>> PIP10, RKLFMT and DTFMT, at least older versions of them want the bit 7
>> set to 1.
>
> Like I said before. Back then, the standard was to use MARK parity...
> Thus, bit 7 is always 1.
parity MARK. Newer or patched software ignors parity, but you cannot trust
on that.
For example our terminals are connected via a terminalserver with different
computers. If we strap our terminal to set parity to MARK constantly and
then try to login to a unix machine or to a CP/M-system we run into trouble.
Klemens
Johnny Billquist
Jun 25, 2012, 10:17:18 AM6/25/12
to
On 2012-06-25 14:45, Klemens Krause wrote:
> Johnny Billquist wrote:
>> On 2012-06-25 13:19, Klemens Krause wrote:
> ...
>
>>> Software waiting for text entry should set bit 7 from the serial line
>>> to 1.
>>
>> You mean when they read data? I would say that that would be totally
>> up to the program. If it want to force mark parity, or if it wants to
>> strip
> No, I mean text. For example PIP10. You start it, and it answers with a
> *
> This looks like the command line decoder from OS/8, but it isn't, its hard-
> coded and wants an entry with bit 7 set. There are other programs with this
> behaviour. Naturally if you write your own software it doesn't matter if
> you strip bit 7 off or if you set it to 1. But if you want to be stylish
> than it is more authentic to set bit 7 to 1, espicially if you're using
> PAL.
Oh! Are you talking about the terminal doing the transmission then? If
> Johnny Billquist wrote:
>> On 2012-06-25 13:19, Klemens Krause wrote:
> ...
>
>>> Software waiting for text entry should set bit 7 from the serial line
>>> to 1.
>>
>> You mean when they read data? I would say that that would be totally
>> up to the program. If it want to force mark parity, or if it wants to
>> strip
> No, I mean text. For example PIP10. You start it, and it answers with a
> *
> This looks like the command line decoder from OS/8, but it isn't, its hard-
> coded and wants an entry with bit 7 set. There are other programs with this
> behaviour. Naturally if you write your own software it doesn't matter if
> you strip bit 7 off or if you set it to 1. But if you want to be stylish
> than it is more authentic to set bit 7 to 1, espicially if you're using
> PAL.
so, then yes, you want to use MARK parity on the terminal.
(And yes, now that you mention it I remember that PIP10 has its own
command decoder stuff.)
>> off parity, if it wants to check if the parity is correct or not, and
>> so on is pretty much up to the software.
>>
> I never saw software on my PDP-8 which used parity checking for error
> detecting.
data could do that if it wanted to. In a way, you could say that PIP10 do...
>> Well, technically, since we're talking about the parity here, devices
>> printing or displaying text should probably actually *check* the
>> parity, and not just ignore it. :-)
> The term "parity" is used in a wrong way: To useful check parity, it has
> to be odd or even. Parity mark or space is not of any use. .BN-files use
> a block check and KERMIT also.
any errors, it is commonly referred to as mark parity.
And while I agree that mark or space parity is of little use, it can be
regarded as at least some bit of information.
>> Punchers are normally expected to be 8 bit clean.
>>
> Yes. This was the reason, why I had to PUNCH my texts out, to see what
> the bit 7 really does. Also paper tape reader have to be 8 bit clean.
for the reader and punch, even if you use the reader/punch of the
console ASR33.
>>> But as I wrote, these rules weren't consistent applied by DEC itself:
>>> PIP10, RKLFMT and DTFMT, at least older versions of them want the bit 7
>>> set to 1.
>>
>> Like I said before. Back then, the standard was to use MARK parity...
>> Thus, bit 7 is always 1.
> Yes, and that is a problem. If you have a terminal which cannot set to
> parity MARK. Newer or patched software ignors parity, but you cannot trust
> on that.
> For example our terminals are connected via a terminalserver with different
> computers. If we strap our terminal to set parity to MARK constantly and
> then try to login to a unix machine or to a CP/M-system we run into
> trouble.
settings. It is over optimistic to think that the same settings should
work anywhere.
And I just checked the ASR35 manuals, and it does indeed force mark
parity on its transmissions, and expect it on receives.
There was a separate option you could get, that implemented even parity
checking and generation as well, but not everyone had that.
So DEC equipment basically had to do MARK parity as well, as the ASR33
and ASR35 were the standard terminals for these systems back in the day.
Johnny
Rob Doyle
Jun 25, 2012, 5:09:02 PM6/25/12
to
I've taken this excellent advice and removed the 'MSB workarounds'
in the TTY UARTs. Everything is back to 8-bit clean.
I forgot that there might have been reasons to bin load over the TTY
port. I have a separate port for the paper tape reader which was
always 8-bit clean.
I will note that PUTTY does support Mark Parity while "Tera Term" does
not - I just configured "Tera Term" for 7 bits and an extra stop bit.
Off hand, I can't see how a UART could detect the difference between
7 data bits, mark parity, 1 stop bit and 7 data bits, no parity and 2
stop bits...
This all seems like a odd abuse of a parity bit
Rob
Klemens Krause
Jun 26, 2012, 4:50:58 AM6/26/12
to
Johnny Billquist wrote:
> On 2012-06-25 14:45, Klemens Krause wrote:
>> Johnny Billquist wrote:
....
> On 2012-06-25 14:45, Klemens Krause wrote:
>> Johnny Billquist wrote:
>> For example our terminals are connected via a terminalserver with
>> different
...
>> different
>
> For different systems, you need to set your terminals to different
> settings. It is over optimistic to think that the same settings should
> work anywhere.
Before we got our terminalservers it was possible to set most computers
> For different systems, you need to set your terminals to different
> settings. It is over optimistic to think that the same settings should
> work anywhere.
and terminals to 9600bd, 8bit, no parity. This worked with nearly every
device. At that time I had a field with plugs and I made connections between
computers and terminals by inserting patch cablse.
Now we have terminalservers which may convert baud rates, bit numbers and
parity on the fly. It is even possible to connect the teletype via tcp and
telnet to any computer in the internet.
>
> And I just checked the ASR35 manuals, and it does indeed force mark
> parity on its transmissions, and expect it on receives.
The ASR-33 was the first TTY that used ASCII. The older machines used
baudot code. When teletype shipped the ASR-33 to the computer manufacturers
the put the "parity"-bit to mark, and DEC and other firms took this as
given fact?
> There was a separate option you could get, that implemented even parity
> checking and generation as well, but not everyone had that.
>
> So DEC equipment basically had to do MARK parity as well, as the ASR33
our grand-grand-...grandfathers to do that.
Klemens
Johnny Billquist
Jun 26, 2012, 5:08:58 AM6/26/12
to
On 2012-06-25 23:09, Rob Doyle wrote:
>
> I will note that PUTTY does support Mark Parity while "Tera Term" does
> not - I just configured "Tera Term" for 7 bits and an extra stop bit.
> Off hand, I can't see how a UART could detect the difference between
> 7 data bits, mark parity, 1 stop bit and 7 data bits, no parity and 2
> stop bits...
It will be absolutely the same. :-)
>
> I will note that PUTTY does support Mark Parity while "Tera Term" does
> not - I just configured "Tera Term" for 7 bits and an extra stop bit.
> Off hand, I can't see how a UART could detect the difference between
> 7 data bits, mark parity, 1 stop bit and 7 data bits, no parity and 2
> stop bits...
I note, however, that the ASR35 is actually 7 bits, mark parity, and two
stop bits... Now try doing that... ;-)
> This all seems like a odd abuse of a parity bit
Johnny
Johnny Billquist
Jun 26, 2012, 5:12:39 AM6/26/12
to
On 2012-06-26 10:50, Klemens Krause wrote:
> Johnny Billquist wrote:
>>
>> And I just checked the ASR35 manuals, and it does indeed force mark
>> parity on its transmissions, and expect it on receives.
> Perhaps this is the real reason for bit 7 set on PDP-8 texts?
I would say so, yes. (I think I already did, in fact... :-) )
> Johnny Billquist wrote:
>>
>> And I just checked the ASR35 manuals, and it does indeed force mark
>> parity on its transmissions, and expect it on receives.
> Perhaps this is the real reason for bit 7 set on PDP-8 texts?
> The ASR-33 was the first TTY that used ASCII. The older machines used
> baudot code. When teletype shipped the ASR-33 to the computer manufacturers
> the put the "parity"-bit to mark, and DEC and other firms took this as
> given fact?
>> There was a separate option you could get, that implemented even
>> parity checking and generation as well, but not everyone had that.
>>
>> So DEC equipment basically had to do MARK parity as well, as the ASR33
> Exactly. We drive on the right side of the street, because Napoleon ordered
> our grand-grand-...grandfathers to do that.
countries drive on the left side... And so on.
But indeed, it all boils down to conventions that then turn into rules
and regulations. We use ASCII because...?
Johnny
Klemens Krause
Jun 26, 2012, 5:17:48 AM6/26/12
to
Rob Doyle wrote:
> On 6/25/2012 7:17 AM, Johnny Billquist wrote:
> > On 2012-06-25 14:45, Klemens Krause wrote:
>
...
> On 6/25/2012 7:17 AM, Johnny Billquist wrote:
> > On 2012-06-25 14:45, Klemens Krause wrote:
>
> OK. I think I get it...
>
...
>
> I forgot that there might have been reasons to bin load over the TTY
> port. I have a separate port for the paper tape reader which was
> always 8-bit clean.
>
>
...
> port. I have a separate port for the paper tape reader which was
> always 8-bit clean.
>
>
> Off hand, I can't see how a UART could detect the difference between
> 7 data bits, mark parity, 1 stop bit and 7 data bits, no parity and 2
> stop bits...
>
Indeed, a USART can't detect every situation automatically. And if an
> 7 data bits, mark parity, 1 stop bit and 7 data bits, no parity and 2
> stop bits...
>
USART detects for example a parity error and sets a bit in a status register,
it's to the software to look at this bit and make an adequate reaction.
> This all seems like a odd abuse of a parity bit
speed up them by only transmitting 5 data bits. In every case you need also
a start bit for synchronisation, and the old mechanical equipment needed two
stop-bits to bring the "distributor" back to its start position. Electronic
equipment doesn't need two stop bits. But to be backward compatible most
USARTs can be set to two stop bits and further, they can be set to 8 data
bits and two stop bits, a combination that was never really used.
At the beginning teletypes were used to make e-mail over telephone lines.
In this application it was important for the receiver to see if there were
transmission errors, especially if they transmitted numerical informartion.
Later when the teletypes were adopted as I/O-devices for computers,
there was no long distance, so probably transmission errors became seldom and
manufacturers made things simpler and cheaper by omitting the even/odd-parity-
stuff. Imagine: teletypes are full mechanical devices with the exeption of
some contacts and magnetic coils. Because the timing in the machine is fix,
they had to fill the timing slot for the formerly parity bit with either mark
or space.
Klemens
Johnny Billquist
Jun 26, 2012, 5:24:35 AM6/26/12
to
On 2012-06-26 11:17, Klemens Krause wrote:
> Rob Doyle wrote:
>
> Rob Doyle wrote:
>
>> This all seems like a odd abuse of a parity bit
> There are historical reasons: If you have slow transmission lines you can
> speed up them by only transmitting 5 data bits. In every case you need also
> a start bit for synchronisation, and the old mechanical equipment needed
> two
> stop-bits to bring the "distributor" back to its start position. Electronic
> equipment doesn't need two stop bits. But to be backward compatible most
> USARTs can be set to two stop bits and further, they can be set to 8 data
> bits and two stop bits, a combination that was never really used.
>
> At the beginning teletypes were used to make e-mail over telephone lines.
> In this application it was important for the receiver to see if there were
> transmission errors, especially if they transmitted numerical informartion.
> Later when the teletypes were adopted as I/O-devices for computers,
> there was no long distance, so probably transmission errors became
> seldom and
> manufacturers made things simpler and cheaper by omitting the
> even/odd-parity-
> stuff. Imagine: teletypes are full mechanical devices with the exeption of
> some contacts and magnetic coils. Because the timing in the machine is fix,
> they had to fill the timing slot for the formerly parity bit with either
> mark
> or space.
Yes. The ASR33 and ASR35 are mechanical. It's a bit hard to imagine, but
> There are historical reasons: If you have slow transmission lines you can
> speed up them by only transmitting 5 data bits. In every case you need also
> a start bit for synchronisation, and the old mechanical equipment needed
> two
> stop-bits to bring the "distributor" back to its start position. Electronic
> equipment doesn't need two stop bits. But to be backward compatible most
> USARTs can be set to two stop bits and further, they can be set to 8 data
> bits and two stop bits, a combination that was never really used.
>
> At the beginning teletypes were used to make e-mail over telephone lines.
> In this application it was important for the receiver to see if there were
> transmission errors, especially if they transmitted numerical informartion.
> Later when the teletypes were adopted as I/O-devices for computers,
> there was no long distance, so probably transmission errors became
> seldom and
> manufacturers made things simpler and cheaper by omitting the
> even/odd-parity-
> stuff. Imagine: teletypes are full mechanical devices with the exeption of
> some contacts and magnetic coils. Because the timing in the machine is fix,
> they had to fill the timing slot for the formerly parity bit with either
> mark
> or space.
really. The sending of the serial data is accomplished by mechanical
means. As such, changing the number of bits being sent is not trivial.
So it always transmits 11 bits (1 start, 7 data, 1 parity, 2 stop). If
you don't have a parity generator option, the parity bit is always mark.
Johnny
Klemens Krause
Jun 26, 2012, 5:21:41 AM6/26/12
to
Johnny Billquist wrote:
...
now in our time EBCDIC.
WRITE(3,300)
300 FORMAT(12H HELLO WORLD)
Klemens
...
> But indeed, it all boils down to conventions that then turn into rules
> and regulations. We use ASCII because...?
>
While IBM still uses its old punch card code, called hollerith-code, or
> and regulations. We use ASCII because...?
>
now in our time EBCDIC.
WRITE(3,300)
300 FORMAT(12H HELLO WORLD)
Klemens
Johnny Billquist
Jun 26, 2012, 6:19:23 AM6/26/12
to
called) as just an old name for what we today call strings. The encoding
of the strings does not change the fact that they are Hollerith constants.
That above pair of lines of FORTRAN works just as well on a PDP-8
running OS/8 (and thus ASCII) as on some IBM system that uses EBCDIC.
But yes, IBM have used EBCDIC for a long time. Longer than ASCII have
been around, if you count the predecessors that lead up to EBCDIC.
Johnny
glen herrmannsfeldt
Jun 26, 2012, 7:29:25 AM6/26/12
to
Johnny Billquist <b...@softjar.se> wrote:
(snip)
using some ASR higher than 33, and at 300 baud.
It is usual to run two stop bits at 110 baud (ASR33), but not
usual for 300 baud.
Also, I thought even some ASR33 could generate parity, and
definitely anything electronic should be able to do it.
I wouldn't be surprised if it allowed one to select mark,
but it should also allow for even or odd parity.
-- glen
(snip)
> It will be absolutely the same. :-)
> I note, however, that the ASR35 is actually 7 bits, mark parity, and two
> stop bits... Now try doing that... ;-)
I thought I remembered the ASR35. At least I spent one summer
> I note, however, that the ASR35 is actually 7 bits, mark parity, and two
> stop bits... Now try doing that... ;-)
using some ASR higher than 33, and at 300 baud.
It is usual to run two stop bits at 110 baud (ASR33), but not
usual for 300 baud.
Also, I thought even some ASR33 could generate parity, and
definitely anything electronic should be able to do it.
I wouldn't be surprised if it allowed one to select mark,
but it should also allow for even or odd parity.
-- glen
glen herrmannsfeldt
Jun 26, 2012, 7:37:05 AM6/26/12
to
Johnny Billquist <b...@softjar.se> wrote:
(snip, someone wrote)
BCDIC is a six bit code used with the 36 bit machines.
Also, the punch codes changed between the BCDIC 026 and the
EBCDIC 029 punch for some characters.
> That above pair of lines of FORTRAN works just as well on a PDP-8
> running OS/8 (and thus ASCII) as on some IBM system that uses EBCDIC.
> But yes, IBM have used EBCDIC for a long time. Longer than ASCII have
> been around, if you count the predecessors that lead up to EBCDIC.
EBCDIC goes back to S/360, close to the time of ASCII.
At the time S/360 was designed, IBM had thought about an 8 bit
version of ASCII (which isn't just ASCII with one bit added).
For S/360, there is a PSW bit that causes a few instructions to
generate different results, but that bit went away with S/370.
As the bit can only be set in supervisor mode, IBM wasn't very
worried about anyone using it. (At least not running IBM OSs.)
-- glen
(snip, someone wrote)
>> WRITE(3,300)
>> 300 FORMAT(12H HELLO WORLD)
> Hollerith is not the same as EBCDIC. Hollerith constants (as they are
> called) as just an old name for what we today call strings. The encoding
> of the strings does not change the fact that they are Hollerith constants.
Yes. Before EBCDIC there was BCDIC, often shortened to BCD.
>> 300 FORMAT(12H HELLO WORLD)
> Hollerith is not the same as EBCDIC. Hollerith constants (as they are
> called) as just an old name for what we today call strings. The encoding
> of the strings does not change the fact that they are Hollerith constants.
BCDIC is a six bit code used with the 36 bit machines.
Also, the punch codes changed between the BCDIC 026 and the
EBCDIC 029 punch for some characters.
> That above pair of lines of FORTRAN works just as well on a PDP-8
> running OS/8 (and thus ASCII) as on some IBM system that uses EBCDIC.
> But yes, IBM have used EBCDIC for a long time. Longer than ASCII have
> been around, if you count the predecessors that lead up to EBCDIC.
At the time S/360 was designed, IBM had thought about an 8 bit
version of ASCII (which isn't just ASCII with one bit added).
For S/360, there is a PSW bit that causes a few instructions to
generate different results, but that bit went away with S/370.
As the bit can only be set in supervisor mode, IBM wasn't very
worried about anyone using it. (At least not running IBM OSs.)
-- glen
Klemens Krause
Jun 26, 2012, 8:16:30 AM6/26/12
to
Johnny Billquist wrote:
> On 2012-06-26 11:21, Klemens Krause wrote:
>> Johnny Billquist wrote:
...
>>
> On 2012-06-26 11:21, Klemens Krause wrote:
>> Johnny Billquist wrote:
...
>>
>> WRITE(3,300)
>> 300 FORMAT(12H HELLO WORLD)
>
> Hollerith is not the same as EBCDIC. Hollerith constants (as they are
Today it is not. But in the 1950ies when FORTRAN came up, it was.
>> 300 FORMAT(12H HELLO WORLD)
>
> Hollerith is not the same as EBCDIC. Hollerith constants (as they are
Hollerith had only upper case letters and so on. But the important thing
in my example is the "12H". And here the H means indeed "HOLLERITH".
At that time there was no ASCII.
> called) as just an old name for what we today call strings. The encoding
...
> But yes, IBM have used EBCDIC for a long time. Longer than ASCII have
> been around, if you count the predecessors that lead up to EBCDIC.
Some yeards ago, I found a test print behind a public printer for account
> been around, if you count the predecessors that lead up to EBCDIC.
statements in my bank office. The 9-grouping of the letters A-I, J-R, S-Z
shows the same grouping as that on punched cards.
Today EBCDIC has also lower case letters and other special charcaters. But
the nucleus is still the old punched card code: 4 Bits for the digits and
2 bits for the zone.
I don't know, if there were other named coding schemes before 1963, when
ASCII was defined first times.
Hollerith, Baudot (exactly CCITT-II), IBM-selectric? Pictures of computing
centres before 1965 often show Friden Flexwriters. For example the PDP-1.
I just had a look in the PDP-1 handbook on bitsavers and saw:
Characters A-I are coded 61-71, J-R are coded 41-51 and S-Z are coded
22-31. Thus this is a Hollerith derivate. ;-)
Klemens
Johnny Billquist
Jun 26, 2012, 8:45:47 AM6/26/12
to
On 2012-06-26 14:16, Klemens Krause wrote:
> Johnny Billquist wrote:
>> On 2012-06-26 11:21, Klemens Krause wrote:
>>> Johnny Billquist wrote:
> ...
>>>
>>> WRITE(3,300)
>>> 300 FORMAT(12H HELLO WORLD)
>>
>> Hollerith is not the same as EBCDIC. Hollerith constants (as they are
> Today it is not. But in the 1950ies when FORTRAN came up, it was.
> Hollerith had only upper case letters and so on. But the important thing
> in my example is the "12H". And here the H means indeed "HOLLERITH".
> At that time there was no ASCII.
Yes, 12H means a 12 letter Hollerith constant. It does not say anything
> Johnny Billquist wrote:
>> On 2012-06-26 11:21, Klemens Krause wrote:
>>> Johnny Billquist wrote:
> ...
>>>
>>> WRITE(3,300)
>>> 300 FORMAT(12H HELLO WORLD)
>>
>> Hollerith is not the same as EBCDIC. Hollerith constants (as they are
> Today it is not. But in the 1950ies when FORTRAN came up, it was.
> Hollerith had only upper case letters and so on. But the important thing
> in my example is the "12H". And here the H means indeed "HOLLERITH".
> At that time there was no ASCII.
about how this constant is encoded.
Look up Hollerith constant in Wikipedia.
>> called) as just an old name for what we today call strings. The encoding
> Originally it ment the encoding.
constants specify the length).
>
> ...
>> But yes, IBM have used EBCDIC for a long time. Longer than ASCII have
>> been around, if you count the predecessors that lead up to EBCDIC.
> Some yeards ago, I found a test print behind a public printer for account
> statements in my bank office. The 9-grouping of the letters A-I, J-R, S-Z
> shows the same grouping as that on punched cards.
> Today EBCDIC has also lower case letters and other special charcaters. But
> the nucleus is still the old punched card code: 4 Bits for the digits and
> 2 bits for the zone.
from the start. (That's what the 'E' stands for - extended.)
> I don't know, if there were other named coding schemes before 1963, when
> ASCII was defined first times.
> Hollerith, Baudot (exactly CCITT-II), IBM-selectric? Pictures of computing
> centres before 1965 often show Friden Flexwriters. For example the PDP-1.
> I just had a look in the PDP-1 handbook on bitsavers and saw:
> Characters A-I are coded 61-71, J-R are coded 41-51 and S-Z are coded
> 22-31. Thus this is a Hollerith derivate. ;-)
EBCDIC is contemporary with ASCII. But EBCDIC is just an evolution of
BCDIC, which in turn is just an evolution of BCD. It definitely precede
ASCII.
Of course, we have the Baudot-code, which is way older as well.
Don't know which, if any peripherals that might have been used on a
PDP-1, and therefore might have decided what coding scheme might have
been considered normal.
Johnny
Johnny Billquist
Jun 26, 2012, 8:49:03 AM6/26/12
to
On 2012-06-26 13:29, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip)
>> It will be absolutely the same. :-)
>> I note, however, that the ASR35 is actually 7 bits, mark parity, and two
>> stop bits... Now try doing that... ;-)
>
> I thought I remembered the ASR35. At least I spent one summer
> using some ASR higher than 33, and at 300 baud.
>
> It is usual to run two stop bits at 110 baud (ASR33), but not
> usual for 300 baud.
Not even sure you can run an ASR33 or ASR35 at 300 baud. The manual only
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip)
>> It will be absolutely the same. :-)
>> I note, however, that the ASR35 is actually 7 bits, mark parity, and two
>> stop bits... Now try doing that... ;-)
>
> I thought I remembered the ASR35. At least I spent one summer
> using some ASR higher than 33, and at 300 baud.
>
> It is usual to run two stop bits at 110 baud (ASR33), but not
> usual for 300 baud.
talks about 110 baud.
> Also, I thought even some ASR33 could generate parity, and
> definitely anything electronic should be able to do it.
> I wouldn't be surprised if it allowed one to select mark,
> but it should also allow for even or odd parity.
"Electronic"...? Well, by some definition, yes. However, it is
electromechanical...
The option added the ability to do even parity. No chance of odd... Sorry.
Johnny
Klemens Krause
Jun 26, 2012, 10:10:06 AM6/26/12
to
Johnny Billquist wrote:
> On 2012-06-26 13:29, glen herrmannsfeldt wrote:
>> Johnny Billquist <b...@softjar.se> wrote:
...
> On 2012-06-26 13:29, glen herrmannsfeldt wrote:
>> Johnny Billquist <b...@softjar.se> wrote:
>
> Not even sure you can run an ASR33 or ASR35 at 300 baud. The manual only
> talks about 110 baud.
>
ASR33 can definetly only run 110 baud. As much as I know, the main difference
> Not even sure you can run an ASR33 or ASR35 at 300 baud. The manual only
> talks about 110 baud.
>
between ASR33 and ASR35 was, that ASR35 could punch, without printing.
And according to the technical manual there is 1 start bit, 8 data bits and
1 stop bit. The 8th data bit is either used as real parity bit or set to
mark or space.
>> Also, I thought even some ASR33 could generate parity, and
>> definitely anything electronic should be able to do it.
>> I wouldn't be surprised if it allowed one to select mark,
>> but it should also allow for even or odd parity.
available which can produce parity.
And if you don't have this keyboard, user can change between parity mark
and parity space by strapping.
>
> Some could generate parity, I would assume (just as with the ASR35).
> "Electronic"...? Well, by some definition, yes. However, it is
> electromechanical...
Parity is generated in the keyboard. (Teletype Bulletin 310B Vol 1,
Sect. 574-121-100TC, pages 7-11)
> The option added the ability to do even parity. No chance of odd... Sorry.
even parity option in your ASR33, you put an inverter in the parity line and
you get odd parity.
Serialisation of the parallel output of the keyboard is done with a rotating
switch, the distributor.
Klemens
Klemens Krause
Jun 26, 2012, 10:14:20 AM6/26/12
to
Johnny Billquist wrote:
> On 2012-06-26 14:16, Klemens Krause wrote:
...
> On 2012-06-26 14:16, Klemens Krause wrote:
>
> Are you confusing Hollerith with BCDIC?
> EBCDIC is contemporary with ASCII. But EBCDIC is just an evolution of
> BCDIC, which in turn is just an evolution of BCD. It definitely precede
> ASCII.
Ok, perhaps I confused BCDIC with EBCDIC. BCD is for me : Binary Coded Decimal,
> Are you confusing Hollerith with BCDIC?
> EBCDIC is contemporary with ASCII. But EBCDIC is just an evolution of
> BCDIC, which in turn is just an evolution of BCD. It definitely precede
> ASCII.
a 4-bit code to encode decimal digits in electronic desktop calculators, for
example the i4004.
> Of course, we have the Baudot-code, which is way older as well.
>
> Don't know which, if any peripherals that might have been used on a
> PDP-1, and therefore might have decided what coding scheme might have
> been considered normal.
the museum, all with different codes. Encoding could evidently defined by
users.
Klemens
glen herrmannsfeldt
Jun 26, 2012, 1:39:19 PM6/26/12
to
Johnny Billquist <b...@softjar.se> wrote:
(snip, I wrote)
I only remember that it was an odd number after ASR33,
and that I never saw one before or after that.
(That was 33 years ago).
-- glen
(snip, I wrote)
>> I thought I remembered the ASR35. At least I spent one summer
>> using some ASR higher than 33, and at 300 baud.
>> It is usual to run two stop bits at 110 baud (ASR33), but not
>> usual for 300 baud.
> Not even sure you can run an ASR33 or ASR35 at 300 baud.
> The manual only talks about 110 baud.
I will have to find some pictures. Maybe it was ASR37.
>> using some ASR higher than 33, and at 300 baud.
>> It is usual to run two stop bits at 110 baud (ASR33), but not
>> usual for 300 baud.
> Not even sure you can run an ASR33 or ASR35 at 300 baud.
> The manual only talks about 110 baud.
I only remember that it was an odd number after ASR33,
and that I never saw one before or after that.
(That was 33 years ago).
-- glen
glen herrmannsfeldt
Jun 26, 2012, 2:39:47 PM6/26/12
to
Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
(snip, someone wrote)
code used by the 704 and such was either BCDIC or BCD.
>> But yes, IBM have used EBCDIC for a long time. Longer than ASCII have
>> been around, if you count the predecessors that lead up to EBCDIC.
> Some yeards ago, I found a test print behind a public printer
> for account statements in my bank office. The 9-grouping of the
> letters A-I, J-R, S-Z shows the same grouping as that on punched cards.
> Today EBCDIC has also lower case letters and other special charcaters.
> But the nucleus is still the old punched card code: 4 Bits for
> the digits and 2 bits for the zone.
For EBCDIC it is four bits for zone. It is interesting how the 256
codes are mapped onto punched cards. The first rule is at most one
punch in rows 1-7. That leaves eight combinations for those rows,
and 32 for rows 12, 11, 0, 8, 9, for 256 combinations.
The mapping is defined such that overpunching works properly.
In the days before computers, and in the BCDIC days, it was
at least slightly usual to punch the sign over one of the digits.
In the BCDIC (026 punch) days, the top rows were plus and minus.
(I barely remember this, but I did use 026 punches.)
(Before computers, there were different card processing machines.
One being the card sorter which would examine the punch in a
selected column, and then send the card into one of 12 bins
based on the punch and a selector switch. The beginnings of
the radix sort.)
The EBCDIC codes are arranged such that you can punch a sign
over a digit, and the sign effects the zone (four most significant
bits) and the digit the least significant bits. The S/360 PACK
and UNPACK instructions then move the zone to/from the low
nybble of a BCD value. A punch in the 11 row over the least
significant digit will generate an appropriate zone for a
negative BCD value. A punch in the 12 row, or no zone punch,
will generate a positive BCD value.
> I don't know, if there were other named coding schemes
> before 1963, when ASCII was defined first times.
There were coding schemes, but they weren't especially standardizes.
I believe the system used by Fortran (and scientific computing)
was different from the COBOL (and commercial computing) system.
Even the codes on magnetic (seven track even parity) were different
from those in memory. (You can't write all bits zero in even
parity on tape with NRZI track coding.)
> Hollerith, Baudot (exactly CCITT-II), IBM-selectric?
The selectric print mechanism was used in the 2741 terminal,
which is not EBCDIC but has its own code based on positiions
on the type ball.
> Pictures of computing centres before 1965 often show Friden
> Flexwriters. For example the PDP-1.
> I just had a look in the PDP-1 handbook on bitsavers and saw:
> Characters A-I are coded 61-71, J-R are coded 41-51 and S-Z are coded
> 22-31. Thus this is a Hollerith derivate. ;-)
-- glen
(snip, someone wrote)
>> Hollerith is not the same as EBCDIC. Hollerith constants (as they are
> Today it is not. But in the 1950ies when FORTRAN came up, it was.
> Hollerith had only upper case letters and so on. But the important thing
> in my example is the "12H". And here the H means indeed "HOLLERITH".
> At that time there was no ASCII.
>> called) as just an old name for what we today call strings.
>> The encoding Originally it ment the encoding.
The punch codes might have been named after him. The internal
> Today it is not. But in the 1950ies when FORTRAN came up, it was.
> Hollerith had only upper case letters and so on. But the important thing
> in my example is the "12H". And here the H means indeed "HOLLERITH".
> At that time there was no ASCII.
>> called) as just an old name for what we today call strings.
>> The encoding Originally it ment the encoding.
code used by the 704 and such was either BCDIC or BCD.
>> But yes, IBM have used EBCDIC for a long time. Longer than ASCII have
>> been around, if you count the predecessors that lead up to EBCDIC.
> Some yeards ago, I found a test print behind a public printer
> for account statements in my bank office. The 9-grouping of the
> letters A-I, J-R, S-Z shows the same grouping as that on punched cards.
> Today EBCDIC has also lower case letters and other special charcaters.
> But the nucleus is still the old punched card code: 4 Bits for
> the digits and 2 bits for the zone.
codes are mapped onto punched cards. The first rule is at most one
punch in rows 1-7. That leaves eight combinations for those rows,
and 32 for rows 12, 11, 0, 8, 9, for 256 combinations.
The mapping is defined such that overpunching works properly.
In the days before computers, and in the BCDIC days, it was
at least slightly usual to punch the sign over one of the digits.
In the BCDIC (026 punch) days, the top rows were plus and minus.
(I barely remember this, but I did use 026 punches.)
(Before computers, there were different card processing machines.
One being the card sorter which would examine the punch in a
selected column, and then send the card into one of 12 bins
based on the punch and a selector switch. The beginnings of
the radix sort.)
The EBCDIC codes are arranged such that you can punch a sign
over a digit, and the sign effects the zone (four most significant
bits) and the digit the least significant bits. The S/360 PACK
and UNPACK instructions then move the zone to/from the low
nybble of a BCD value. A punch in the 11 row over the least
significant digit will generate an appropriate zone for a
negative BCD value. A punch in the 12 row, or no zone punch,
will generate a positive BCD value.
> I don't know, if there were other named coding schemes
> before 1963, when ASCII was defined first times.
I believe the system used by Fortran (and scientific computing)
was different from the COBOL (and commercial computing) system.
Even the codes on magnetic (seven track even parity) were different
from those in memory. (You can't write all bits zero in even
parity on tape with NRZI track coding.)
> Hollerith, Baudot (exactly CCITT-II), IBM-selectric?
which is not EBCDIC but has its own code based on positiions
on the type ball.
> Pictures of computing centres before 1965 often show Friden
> Flexwriters. For example the PDP-1.
> I just had a look in the PDP-1 handbook on bitsavers and saw:
> Characters A-I are coded 61-71, J-R are coded 41-51 and S-Z are coded
> 22-31. Thus this is a Hollerith derivate. ;-)
glen herrmannsfeldt
Jun 26, 2012, 2:42:35 PM6/26/12
to
Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
(snip)
the usual description of the code is BCD. It is a six bit
code such that the low four bits correspond to the usual
coding for decimal digits. Sometime later the name BCDIC
was used.
-- glen
(snip)
> Ok, perhaps I confused BCDIC with EBCDIC. BCD is for me :
> Binary Coded Decimal, a 4-bit code to encode decimal digits
> in electronic desktop calculators, for example the i4004.
It should be, but if you read the IBM 704 Fortran manual,
> Binary Coded Decimal, a 4-bit code to encode decimal digits
> in electronic desktop calculators, for example the i4004.
the usual description of the code is BCD. It is a six bit
code such that the low four bits correspond to the usual
coding for decimal digits. Sometime later the name BCDIC
was used.
-- glen
van...@vsta.org
Jun 26, 2012, 3:09:15 PM6/26/12
to
Johnny Billquist <b...@softjar.se> wrote:
> Not even sure you can run an ASR33 or ASR35 at 300 baud. The manual only
> talks about 110 baud.
No way. That's what we had ADM-3's for. I can't tell you how tickled we were
> Not even sure you can run an ASR33 or ASR35 at 300 baud. The manual only
> talks about 110 baud.
when the 3a came along and you could *move the cursor*. :->
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Klemens Krause
Jun 27, 2012, 4:32:41 AM6/27/12
to
...
It doesn't make sense to run a mechanical printer with higher
baud rates: A teletype can print a maximum of 10 characters per
second, an IBM 72 (selectric) can print 15 cps, and a flexowriter
can print 12 cps. Speed is limited by the mechanical parts.
110 baud and 10 cps meet perfectly. If you would tune such a
machine for 300 baud you will get a data overrun.
We have a teletype ASR 43. It is electronic (needle printer),
and can work with either 110 or 300 baud, and it can generate
even parity. (Both option directly switchable on the keyboard).
Klemens
>> Not even sure you can run an ASR33 or ASR35 at 300 baud.
>> The manual only talks about 110 baud.
>
...
>> The manual only talks about 110 baud.
>
It doesn't make sense to run a mechanical printer with higher
baud rates: A teletype can print a maximum of 10 characters per
second, an IBM 72 (selectric) can print 15 cps, and a flexowriter
can print 12 cps. Speed is limited by the mechanical parts.
110 baud and 10 cps meet perfectly. If you would tune such a
machine for 300 baud you will get a data overrun.
We have a teletype ASR 43. It is electronic (needle printer),
and can work with either 110 or 300 baud, and it can generate
even parity. (Both option directly switchable on the keyboard).
Klemens
Klemens Krause
Jun 27, 2012, 4:54:00 AM6/27/12
to
>> ... BCD is for me :
PDP-8, which has a BSW order, which swaps the two 6-bit bytes
of the accumulator.
> coding for decimal digits. Sometime later the name BCDIC
> was used.
And the upper 2 bits coded the zone bits. So it was a projection
of the punched card code which was a 2 of 12 encoding in a 2 + 4
binary coding.
These commonly used 6 bit codes lead to words of 12, 18, 24, 36 and
48 bits. DEC had another 6 bit code, which was derived from ASCII.
When I started FORTRAN programming in 1977 on a ICL 1900 machine,
there were two types of card punchs in the computing centre. And
we had to put a control card (26 or 29) after the job cards, to
tell the machine which code was used. I believe the letters IBM
were avoided since there were "compatible" card punchs.
Klemens
>> Binary Coded Decimal, a 4-bit code to encode decimal digits
>> in electronic desktop calculators, for example the i4004.
>
> It should be, but if you read the IBM 704 Fortran manual,
> the usual description of the code is BCD. It is a six bit
> code such that the low four bits correspond to the usual
Yes, names change. At that time a byte had 6 bits. Until the
>> in electronic desktop calculators, for example the i4004.
>
> It should be, but if you read the IBM 704 Fortran manual,
> the usual description of the code is BCD. It is a six bit
> code such that the low four bits correspond to the usual
PDP-8, which has a BSW order, which swaps the two 6-bit bytes
of the accumulator.
> coding for decimal digits. Sometime later the name BCDIC
> was used.
of the punched card code which was a 2 of 12 encoding in a 2 + 4
binary coding.
These commonly used 6 bit codes lead to words of 12, 18, 24, 36 and
48 bits. DEC had another 6 bit code, which was derived from ASCII.
When I started FORTRAN programming in 1977 on a ICL 1900 machine,
there were two types of card punchs in the computing centre. And
we had to put a control card (26 or 29) after the job cards, to
tell the machine which code was used. I believe the letters IBM
were avoided since there were "compatible" card punchs.
Klemens
glen herrmannsfeldt
Jun 27, 2012, 6:43:14 AM6/27/12
to
Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
(previously snipped discussion of a terminal I used years ago)
> We have a teletype ASR 43. It is electronic (needle printer),
> and can work with either 110 or 300 baud, and it can generate
> even parity. (Both option directly switchable on the keyboard).
Maybe it was the ASR 43. Needle printers sounds about right.
Pretty quiet but not a thermal printer.
-- glen
(previously snipped discussion of a terminal I used years ago)
> We have a teletype ASR 43. It is electronic (needle printer),
> and can work with either 110 or 300 baud, and it can generate
> even parity. (Both option directly switchable on the keyboard).
Pretty quiet but not a thermal printer.
-- glen
Johnny Billquist
Jun 29, 2012, 10:50:16 AM6/29/12
to
On 2012-06-26 16:10, Klemens Krause wrote:
> Johnny Billquist wrote:
>> On 2012-06-26 13:29, glen herrmannsfeldt wrote:
>>> Johnny Billquist <b...@softjar.se> wrote:
> ...
>>
>> Not even sure you can run an ASR33 or ASR35 at 300 baud. The manual
>> only talks about 110 baud.
>>
> ASR33 can definetly only run 110 baud. As much as I know, the main
> difference
> between ASR33 and ASR35 was, that ASR35 could punch, without printing.
> And according to the technical manual there is 1 start bit, 8 data bits and
> 1 stop bit. The 8th data bit is either used as real parity bit or set to
> mark or space.
What manual are you looking at in that case. I'm reading the ASR35
> Johnny Billquist wrote:
>> On 2012-06-26 13:29, glen herrmannsfeldt wrote:
>>> Johnny Billquist <b...@softjar.se> wrote:
> ...
>>
>> Not even sure you can run an ASR33 or ASR35 at 300 baud. The manual
>> only talks about 110 baud.
>>
> ASR33 can definetly only run 110 baud. As much as I know, the main
> difference
> between ASR33 and ASR35 was, that ASR35 could punch, without printing.
> And according to the technical manual there is 1 start bit, 8 data bits and
> 1 stop bit. The 8th data bit is either used as real parity bit or set to
> mark or space.
manual, and it clearly states that there are two stop bits (and I'm
talking about transmission here). Technical Manual Model 35, Volume 1.
Page 24 (or actually page 8 of the section "35 typing unit").
Also, about the parity and start/stop bits, the manual says the following:
"The eight bit is always marking, unless the set is equipped to provide
an even parity output. With even parity, the eight bit may be either
marking or spacing in order to always provide an even number of marking
pulses for each combination. The intelligence bits are preceded by a
start bit (always spacing) and are followed by two stop bits (always
marking)."
>>> Also, I thought even some ASR33 could generate parity, and
>>> definitely anything electronic should be able to do it.
>>> I wouldn't be surprised if it allowed one to select mark,
>>> but it should also allow for even or odd parity.
> I had a look in our ASR33 option list: They write, that there is a keyboard
> available which can produce parity.
> And if you don't have this keyboard, user can change between parity mark
> and parity space by strapping.
>> Some could generate parity, I would assume (just as with the ASR35).
>> "Electronic"...? Well, by some definition, yes. However, it is
>> electromechanical...
> Yes electromechanical. Every key closes or opens one or more contacts.
There are no contacts. The parts around the keyboard are fully
mechanical. (Which is why you also almost break your fingers if you type
too fast, since the keys are mechanically locked when the transmitted is
busy.)
When you press a key on the ASR35 (and the ASR33), it moves, though a
number of levers, through a code lever, a number of code bars. The code
lever encodes the key typed, and the code bars makes this code visible
to a motor that "sweeps" over the code bars, and in turn generates marks
or spaces in the transmission based on the position of the code bars.
(This is the electrical part...)
(There is a little bit more mehcanics between the code bars and the
actual transmission, but this is the principle of the whole thing.)
Electromechanical really means "a lot of mechanical"...
> Parity is generated in the keyboard. (Teletype Bulletin 310B Vol 1,
> Sect. 574-121-100TC, pages 7-11)
just change.
When you have the parity option installed on the ASR35, the parity is
generated by the code bars, just like all the other bits. So it's
totally mechanical as well. To make life even more interesting, the
SHIFT key and the CONTROL key both affect parity, so the keyboard
mechanically inverts the parity bit in case the SHIFT or CONTROL key is
depressed. In addition, the SHIFT key inverts bit 5 mechanically, while
the CONTROL key mechanically inhibits the the code bar for bit 7 to move.
Isn't all this fun? I wonder if the people who designed all this went
mad afterwards, or if they were secretly swiss clock makers?
>> The option added the ability to do even parity. No chance of odd...
>> Sorry.
> As I saw in the manual, the keyboard has electrical output. So if you
> have the
> even parity option in your ASR33, you put an inverter in the parity line
> and
> you get odd parity.
> Serialisation of the parallel output of the keyboard is done with a
> rotating
> switch, the distributor.
This does not sound like an ASR33, and it definitely is not an ASR35.
What you describe is way more electrical than how these terminals work.
Just as an FYI, the ASR35 manual I'm reading can be found at
http://www.bitsavers.org/pdf/teletype/281B_Mod35_TechVol1_Apr73.pdf
And the keyboard workings, including diagrams and pictures are at page
123 and forward. Especially fun is to look at the diagrams on pages 129
(showing the linkage from key to code lever) and 132 (showing code lever
to code bar)
Johnny
Klemens Krause
Jun 29, 2012, 12:49:05 PM6/29/12
to
Johnny Billquist wrote:
> On 2012-06-26 16:10, Klemens Krause wrote:
>> Johnny Billquist wrote:
....
> On 2012-06-26 16:10, Klemens Krause wrote:
>> Johnny Billquist wrote:
>
> What manual are you looking at in that case. I'm reading the ASR35
> manual, and it clearly states that there are two stop bits (and I'm
O.k., your right. ASR33 has two stop bits two. I have no information
> What manual are you looking at in that case. I'm reading the ASR35
> manual, and it clearly states that there are two stop bits (and I'm
about ASR35.
....
> Also, about the parity and start/stop bits, the manual says the following:
> "The eight bit is always marking, unless the set is equipped to provide
> an even parity output. With even parity, the eight bit may be either
On the last pages there is a selection guide with the different options
available. There is a option "Even Parity Keyboard" and an option
"8th bit always Mark or Space (Customer activated option)"
>> Yes electromechanical. Every key closes or opens one or more contacts.
>
> What??? No!!!
> There are no contacts. The parts around the keyboard are fully
> mechanical. (Which is why you also almost break your fingers if you type
the keyboard are contacts which give a parallel output which is feed to
the distributor, which makes the serialization. Naturally there is no
electronic, for example a diode encoder in the keyboard. Have a look to
page 11, ISS2, Section 574-121-100TC of the "technical manual bull 310B,
Vol.1) and to page 5/6 in section 574-122-100TC of the same manual.
> or spaces in the transmission based on the position of the code bars.
> (This is the electrical part...)
> Electromechanical really means "a lot of mechanical"...
>
>> Parity is generated in the keyboard. (Teletype Bulletin 310B Vol 1,
>> Sect. 574-121-100TC, pages 7-11)
>
> Right. It's also encoded mechanically. Which is why it's not easy to
> just change.
You have to get the new keyboard, unplug the old and plugin the new. ;-)
...
>
> I don't know which manual you are reading. Could you provide a link?
> This does not sound like an ASR33, and it definitely is not an ASR35.
> What you describe is way more electrical than how these terminals work.
>
Oh sorry, in the moment I saw that there are only few documents about
> I don't know which manual you are reading. Could you provide a link?
> This does not sound like an ASR33, and it definitely is not an ASR35.
> What you describe is way more electrical than how these terminals work.
>
ASR33 on bitsavers. I used the original paper documents Bull. 1184B,
Bull 310B and Bull Vol.1 and Vol.2.
I'll scan them and the teletype catalog on monday and put them on our
ftp-server.
Klemens
David Gesswein
Jun 30, 2012, 8:20:35 AM6/30/12
to
In article <jskma2$i74$1...@inf2.informatik.uni-stuttgart.de>,
http://www.pdp8online.com/pdp8cgi/query_docs/query.pl?Search=asr
Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
>Oh sorry, in the moment I saw that there are only few documents about
>ASR33 on bitsavers. I used the original paper documents Bull. 1184B,
>Bull 310B and Bull Vol.1 and Vol.2.
>I'll scan them and the teletype catalog on monday and put them on our
>ftp-server.
>
Copies here
>Oh sorry, in the moment I saw that there are only few documents about
>ASR33 on bitsavers. I used the original paper documents Bull. 1184B,
>Bull 310B and Bull Vol.1 and Vol.2.
>I'll scan them and the teletype catalog on monday and put them on our
>ftp-server.
>
http://www.pdp8online.com/pdp8cgi/query_docs/query.pl?Search=asr
Johnny Billquist
Jul 1, 2012, 1:28:43 PM7/1/12
to
On 2012-06-29 18:49, Klemens Krause wrote:
> Johnny Billquist wrote:
>> On 2012-06-26 16:10, Klemens Krause wrote:
>>> Johnny Billquist wrote:
> ....
>>
>> What manual are you looking at in that case. I'm reading the ASR35
>> manual, and it clearly states that there are two stop bits (and I'm
> O.k., your right. ASR33 has two stop bits two. I have no information
> about ASR35.
> ....
Unfortunately I didn't find much on the ASR33 at a brief glance on
> Johnny Billquist wrote:
>> On 2012-06-26 16:10, Klemens Krause wrote:
>>> Johnny Billquist wrote:
> ....
>>
>> What manual are you looking at in that case. I'm reading the ASR35
>> manual, and it clearly states that there are two stop bits (and I'm
> O.k., your right. ASR33 has two stop bits two. I have no information
> about ASR35.
> ....
bitsavers. Didn't search anywhere else, but if anything, the ASR35 was
just an improved version of the ASR33, as far as my memory can recall.
There weren't any major differences. But as always, I might be wrong... :-)
>> Also, about the parity and start/stop bits, the manual says the
>> following:
>> "The eight bit is always marking, unless the set is equipped to
>> provide an even parity output. With even parity, the eight bit may be
>> either
>
> I have the "catalog teletype model 33" from 1972. #M33DT5K762
> On the last pages there is a selection guide with the different options
> available. There is a option "Even Parity Keyboard" and an option
> "8th bit always Mark or Space (Customer activated option)"
as inversion is required if you have any parity generation.
If so, then just always force the parity to inverse should do the space
parity easily enough. :-)
>>> Yes electromechanical. Every key closes or opens one or more contacts.
>>
>> What??? No!!!
>> There are no contacts. The parts around the keyboard are fully
>> mechanical. (Which is why you also almost break your fingers if you type
> Naturally there are contacts. The encoding is done mechanically, but inside
> the keyboard are contacts which give a parallel output which is feed to
> the distributor, which makes the serialization. Naturally there is no
> electronic, for example a diode encoder in the keyboard. Have a look to
> page 11, ISS2, Section 574-121-100TC of the "technical manual bull 310B,
> Vol.1) and to page 5/6 in section 574-122-100TC of the same manual.
by every key... :-)
It's not even located at the key itself.
But you said "Every key closes or opens one or more contacts.", which
seems rather different than the actual construction.
>> or spaces in the transmission based on the position of the code bars.
>> (This is the electrical part...)
> For the ASR33 this is wrong. Perhaps this is valid for the ASR35.
does not seem to want to play...
But I have a very hard time believing that the ASR33 would do this
differently than the AS35, and even harder to believe that it would be
more electrical in the construction than the ASR35.
>> Electromechanical really means "a lot of mechanical"...
>>
> naturally. And some contacts.
Unless you count the contact that closes and opens as it pass over the
code bars to determine if it's transmitting a space or a mark.
That would make it two contacts. One that starts the distributor, and
one that reads the code bar, and thus generates the serial data.
>>> Parity is generated in the keyboard. (Teletype Bulletin 310B Vol 1,
>>> Sect. 574-121-100TC, pages 7-11)
>>
>> Right. It's also encoded mechanically. Which is why it's not easy to
>> just change.
> But output of the mechanical encoders is electrically. Change is easy:
> You have to get the new keyboard, unplug the old and plugin the new. ;-)
having a different set of code levers, which cause a different pattern
to be indicated on the code bars.
Changing on the existing keyboard on the other hand... No thanks.
>> I don't know which manual you are reading. Could you provide a link?
>> This does not sound like an ASR33, and it definitely is not an ASR35.
>> What you describe is way more electrical than how these terminals work.
>>
> Oh sorry, in the moment I saw that there are only few documents about
> ASR33 on bitsavers. I used the original paper documents Bull. 1184B,
> Bull 310B and Bull Vol.1 and Vol.2.
> I'll scan them and the teletype catalog on monday and put them on our
> ftp-server.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist
Jul 1, 2012, 1:35:17 PM7/1/12
to
On 2012-06-27 10:54, Klemens Krause wrote:
> glen herrmannsfeldt wrote:
>> Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
>>
>> (snip)
>>> ... BCD is for me : Binary Coded Decimal, a 4-bit code to encode
>>> decimal digits in electronic desktop calculators, for example the i4004.
>>
>> It should be, but if you read the IBM 704 Fortran manual,
>> the usual description of the code is BCD. It is a six bit
>> code such that the low four bits correspond to the usual
> Yes, names change. At that time a byte had 6 bits. Until the
> PDP-8, which has a BSW order, which swaps the two 6-bit bytes
> of the accumulator.
A proper machine have a variable byte length. :-)
> glen herrmannsfeldt wrote:
>> Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
>>
>> (snip)
>>> ... BCD is for me : Binary Coded Decimal, a 4-bit code to encode
>>> decimal digits in electronic desktop calculators, for example the i4004.
>>
>> It should be, but if you read the IBM 704 Fortran manual,
>> the usual description of the code is BCD. It is a six bit
>> code such that the low four bits correspond to the usual
> Yes, names change. At that time a byte had 6 bits. Until the
> PDP-8, which has a BSW order, which swaps the two 6-bit bytes
> of the accumulator.
(Hello PDP-10)
However, I also usually read BCD as Binary Coded Digit, and assumes it's
a 4 bit code. BCDIC is 6 bits. EBCDIC is 8 bits. But I might have just
missed some interpretation of BCD as being 6 bits. I never was much into
IBM computing...
But Hollerith is still just a different name for a string. A Hollerith
string can be encoded in both ASCII and EBCDIC. It don't matter. It's a
Hollerith constant either way.
(Simply put, 5HHELLO is a Hollerith constant. You can encode the
"5HHELLO" in any coding scheme you want, it will still express a string
constant of "HELLO". Newer FORTRAN compilers allowed using quotes
instead of the old H-notation, but it's still strings.)
>> coding for decimal digits. Sometime later the name BCDIC
>> was used.
> And the upper 2 bits coded the zone bits. So it was a projection
> of the punched card code which was a 2 of 12 encoding in a 2 + 4
> binary coding.
> These commonly used 6 bit codes lead to words of 12, 18, 24, 36 and
> 48 bits. DEC had another 6 bit code, which was derived from ASCII.
the two high bits. Uppercase only, along with all the punctuations.
glen herrmannsfeldt
Jul 1, 2012, 6:41:06 PM7/1/12
to
Johnny Billquist <b...@softjar.se> wrote:
(snip, regarding BCD, I wrote)
>>> It should be, but if you read the IBM 704 Fortran manual,
>>> the usual description of the code is BCD. It is a six bit
>>> code such that the low four bits correspond to the usual
>> Yes, names change. At that time a byte had 6 bits. Until the
>> PDP-8, which has a BSW order, which swaps the two 6-bit bytes
>> of the accumulator.
> A proper machine have a variable byte length. :-)
> (Hello PDP-10)
> However, I also usually read BCD as Binary Coded Digit, and
> assumes it's a 4 bit code. BCDIC is 6 bits. EBCDIC is 8 bits.
I don't have copies of any other 704 manuals, but in the Fortran
manual it is just called BCD and is 6 bits.
> But I might have just missed some interpretation of BCD as
> being 6 bits. I never was much into IBM computing...
Yes, I don't know the history leading up to that point.
> But Hollerith is still just a different name for a string.
> A Hollerith string can be encoded in both ASCII and EBCDIC.
> It don't matter. It's a Hollerith constant either way.
That is true in Fortran. It might be that earlier the card
code was named after him.
> (Simply put, 5HHELLO is a Hollerith constant. You can encode the
> "5HHELLO" in any coding scheme you want, it will still express
> a string constant of "HELLO". Newer FORTRAN compilers allowed
> using quotes instead of the old H-notation, but it's still strings.)
At least as early as the OS/360 compilers, and maybe Fortran IV
on the 7090. (The predecessor to OS/360 Fortran.)
(snip)
-- glen
(snip, regarding BCD, I wrote)
>>> It should be, but if you read the IBM 704 Fortran manual,
>>> the usual description of the code is BCD. It is a six bit
>>> code such that the low four bits correspond to the usual
>> Yes, names change. At that time a byte had 6 bits. Until the
>> PDP-8, which has a BSW order, which swaps the two 6-bit bytes
>> of the accumulator.
> A proper machine have a variable byte length. :-)
> (Hello PDP-10)
> However, I also usually read BCD as Binary Coded Digit, and
> assumes it's a 4 bit code. BCDIC is 6 bits. EBCDIC is 8 bits.
manual it is just called BCD and is 6 bits.
> But I might have just missed some interpretation of BCD as
> being 6 bits. I never was much into IBM computing...
> But Hollerith is still just a different name for a string.
> A Hollerith string can be encoded in both ASCII and EBCDIC.
> It don't matter. It's a Hollerith constant either way.
code was named after him.
> (Simply put, 5HHELLO is a Hollerith constant. You can encode the
> "5HHELLO" in any coding scheme you want, it will still express
> a string constant of "HELLO". Newer FORTRAN compilers allowed
> using quotes instead of the old H-notation, but it's still strings.)
on the 7090. (The predecessor to OS/360 Fortran.)
(snip)
>> These commonly used 6 bit codes lead to words of 12, 18, 24, 36 and
>> 48 bits. DEC had another 6 bit code, which was derived from ASCII.
> SIXBIT? Yes, that is also fun. It's simply ASCII, where you strip off
> the two high bits. Uppercase only, along with all the punctuations.
Well, strip on only one bit if you believe ASCII is a 7 bit code.
>> 48 bits. DEC had another 6 bit code, which was derived from ASCII.
> SIXBIT? Yes, that is also fun. It's simply ASCII, where you strip off
> the two high bits. Uppercase only, along with all the punctuations.
-- glen
Johnny Billquist
Jul 1, 2012, 8:08:40 PM7/1/12
to
On 2012-07-02 00:41, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip, regarding BCD, I wrote)
>
>>>> It should be, but if you read the IBM 704 Fortran manual,
>>>> the usual description of the code is BCD. It is a six bit
>>>> code such that the low four bits correspond to the usual
>
>>> Yes, names change. At that time a byte had 6 bits. Until the
>>> PDP-8, which has a BSW order, which swaps the two 6-bit bytes
>>> of the accumulator.
>
>> A proper machine have a variable byte length. :-)
>> (Hello PDP-10)
>
>> However, I also usually read BCD as Binary Coded Digit, and
>> assumes it's a 4 bit code. BCDIC is 6 bits. EBCDIC is 8 bits.
>
> I don't have copies of any other 704 manuals, but in the Fortran
> manual it is just called BCD and is 6 bits.
Ah. Ok. I've just not been exposed to IBM it would seem. :-)
> Johnny Billquist <b...@softjar.se> wrote:
>
> (snip, regarding BCD, I wrote)
>
>>>> It should be, but if you read the IBM 704 Fortran manual,
>>>> the usual description of the code is BCD. It is a six bit
>>>> code such that the low four bits correspond to the usual
>
>>> Yes, names change. At that time a byte had 6 bits. Until the
>>> PDP-8, which has a BSW order, which swaps the two 6-bit bytes
>>> of the accumulator.
>
>> A proper machine have a variable byte length. :-)
>> (Hello PDP-10)
>
>> However, I also usually read BCD as Binary Coded Digit, and
>> assumes it's a 4 bit code. BCDIC is 6 bits. EBCDIC is 8 bits.
>
> I don't have copies of any other 704 manuals, but in the Fortran
> manual it is just called BCD and is 6 bits.
>>> These commonly used 6 bit codes lead to words of 12, 18, 24, 36 and
>>> 48 bits. DEC had another 6 bit code, which was derived from ASCII.
>
>> SIXBIT? Yes, that is also fun. It's simply ASCII, where you strip off
>> the two high bits. Uppercase only, along with all the punctuations.
>
> Well, strip on only one bit if you believe ASCII is a 7 bit code.
away one bit.
(Old habits about 8 bits for a character die hard...)
Klemens Krause
Jul 2, 2012, 8:03:45 AM7/2/12
to
ftp://ftp.informatik.uni-stuttgart.de/pub/cmTteletype/asr33
I splitted the Bulletin 310B Vol.1 in three parts + an appendix.
I hadn't realized, that one page with the overall function diagramm
is a folded double size sheet, that wasn't scanned correctly by the
automated feeder mechanism.
It is .pdf-page #5 of 310B_Mod33_TechM_Vol1_p2of3_Jun69.pdf
> But you said "Every key closes or opens one or more contacts.", which
> seems rather different than the actual construction.
>
which make the output available in 8-bit code to the distributor. The
8 contacts of tje tape reader are connected in parallel.
>>> Electromechanical really means "a lot of mechanical"...
>>>
>> naturally. And some contacts.
>
> One...
a description, how the keyboard works. On .pdf-page #80 there is the
circuit diagram of the keyboard, which shows that there are even more
contacts, for shift, ctrl and break. And on page #90 ther is a foto of
the numeric-only-keyboard where you can see the contacts. On page #94
it's the same foto for the non-parity keyboard.
> Unless you count the contact that closes and opens as it pass over the
> code bars to determine if it's transmitting a space or a mark.
> That would make it two contacts. One that starts the distributor, and
> one that reads the code bar, and thus generates the serial data.
8 contacts, each for one bit. Shift and control codes are derived by
electrical recoding from the base code. And that all inside the keyboard.
Klemens
Johnny Billquist
Jul 2, 2012, 9:57:14 AM7/2/12
to
On 2012-07-02 14:03, Klemens Krause wrote:
> Johnny Billquist wrote:
>> On 2012-06-29 18:49, Klemens Krause wrote:
> >> I'll scan them and the teletype catalog on monday and put them on our
> >> ftp-server.
> >
> > Please do.
>
> O.k. Some of our documentation can be found on our ftp-server:
> ftp://ftp.informatik.uni-stuttgart.de/pub/cmTteletype/asr33
Thanks. The url was slightly wrong. It's
> Johnny Billquist wrote:
>> On 2012-06-29 18:49, Klemens Krause wrote:
> >> I'll scan them and the teletype catalog on monday and put them on our
> >> ftp-server.
> >
> > Please do.
>
> O.k. Some of our documentation can be found on our ftp-server:
> ftp://ftp.informatik.uni-stuttgart.de/pub/cmTteletype/asr33
ftp://ftp.informatik.uni-stuttgart.de/pub/cm/teletype/asr33
> I splitted the Bulletin 310B Vol.1 in three parts + an appendix.
> I hadn't realized, that one page with the overall function diagramm
> is a folded double size sheet, that wasn't scanned correctly by the
> automated feeder mechanism.
> It is .pdf-page #5 of 310B_Mod33_TechM_Vol1_p2of3_Jun69.pdf
to 80. (Oh, I noticed further down that you have...)
>> But you said "Every key closes or opens one or more contacts.", which
>> seems rather different than the actual construction.
>>
> Especially in this overallview you can see that the keyboard has 8
> contacts,
> which make the output available in 8-bit code to the distributor. The
> 8 contacts of tje tape reader are connected in parallel.
differences between the ASR33 and ASR35 is causing some confusion. Or
I'm just reading the manuals wrong...
The ASR33 have the same mechanical construction as the ASR35. You have a
lever by the key. This manipulates two code bars (front and rear), which
results in two T-levers being actuated. There are several sets of these,
for a total of 8 pairs of codebars, and thus 8 pairs of T-levers.
The T-levers creates the code mechanically, for which key is depressed.
However, I think that at this point, the ASR33 differs some from the
ASR35, in that there are a bunch of contacts actuated by the T-levers.
The actual code to transmit is then generated from these contacts, in
combination with some additional contacts for special keys.
Anyway, I probably misunderstood you saying that there was 8 contacts
per key. There are a bit more than 8 contacts in total for they
keyboard, but it's somewhere in that range, yes...
>>>> Electromechanical really means "a lot of mechanical"...
>>>>
>>> naturally. And some contacts.
>>
>> One...
>
> On .pdf-page #76 of 310B_Mod33_TechM_Vol1_p1of3_Jun69.pdf you can read
> a description, how the keyboard works. On .pdf-page #80 there is the
> circuit diagram of the keyboard, which shows that there are even more
> contacts, for shift, ctrl and break. And on page #90 ther is a foto of
> the numeric-only-keyboard where you can see the contacts. On page #94
> it's the same foto for the non-parity keyboard.
>> Unless you count the contact that closes and opens as it pass over the
>> code bars to determine if it's transmitting a space or a mark.
>> That would make it two contacts. One that starts the distributor, and
>> one that reads the code bar, and thus generates the serial data.
>
> Encoding is done mechanically. But the "mechanical"-code closes and opens
> 8 contacts, each for one bit. Shift and control codes are derived by
> electrical recoding from the base code. And that all inside the keyboard.
differences between the ASR33 and ASR35.
Johnny
Klemens Krause
Jul 2, 2012, 12:00:32 PM7/2/12
to
Johnny Billquist wrote:
> On 2012-07-02 14:03, Klemens Krause wrote:
....
> On 2012-07-02 14:03, Klemens Krause wrote:
Oh great, we agree!
:-)
cjl
Mar 7, 2013, 1:39:39 AM3/7/13
to
1) The use of the mark parity in PDP-8 programming is a SOFTWARE CONVENTION and only is meaningful when looking at punched paper-tapes. the HARDWARE could care less.
If you use the BIN and RIM loaders, these conventions matter, but only there.
2) Foolishly, in OS/8 where on one level a good usage is the "3 for 2" format per se, binary files are actually images of paper-tapes with tiny leaders and trailers with the mark bit set. This is patently absurd and quite inefficient.
In P?S/8, there is a loading-oriented format that is approx. 6/7 as efficient as core-image 12-bit binary; it was designed by Richard Lary himself, but was effectively overruled by dimwitted DEC management. [I will eventually be releasing a paper on this entire story and what could have been done about it, and what I will be doing about it in a parallel universe still being created.]
In P?S/8 when actual paper-tape comes into play, peripheral utilities convert the data to the appropriate tape format and physically create the tapes. There is a one-to-one correspondence between BIN and this format, and RIM is a trival conversion from there. Otherwise, paper-tape and all of its silly conventions are not present.
3) there was a famous "shootout" at DEC where P?S/8 running on DECtapes loaded binary files FASTER than OS/8 running on some RK05 packs. The overhead is that profound. But it didn't have to be that way. [You'll have to wait until I finish the whole story; sorry to merely whet your appetite.]
4) Sixbit text is inherently upper-case and if that's all you need, trivial to unpack and be used as such.
5) the " operator in PAL indeed sets the mark parity bit as defined. that's why there is so much code such as "A&177 in use to get rid of it. If this were starting over, I would do it the other way so that "A was already seven bit and in the rare circumstance that you actually needed it, use "A!200 [which works in the current definition, only redundantly to my hypothetical notion.
6) There are also ASCII \FOO\ to create the equivalent of "F;"O;"O in some assemblers; also some support ASCIIZ to force a zero terminator after the list. The considerations about 7 bit vs mark bit set also apply here; not all assemblers have this.
7) Some assemblers have the TEXTZ pseudo-op to force a 0 half-word terminator on the string, some do not.
8) PAL8 and P?S/8 PAL have an option to turn off/on a trailing full-word of 0000 should the half-word not happen. Kermit-12 for example demands this be turned off and documents the assembler switches in both programs to make the code function. PAL10 does not support this important option and thus cannot assemble quite a few programs. Since TEXTZ exists in many of these programs, the default of TEXT ought to be reversed, but that's a minor issue of defaults' you need both cases and PAL10 cannot do it.
9) SIXBIT is each character is formed the ascii char &77. But in some assemblers the SIXBIT directive doesn't do that, the TEXT directive does in the PDP-8 world. The point is that the high-order of the six bits is inverted one system to the other. In one system, it is easier to convert a string to printable 7 bit, but it is harder to create it in the first place. In the other, the roles are reversed and aggregated together are about the same overhead. But beware of conventions on different machines being different.
P?S/8 PAL actually supports the SIXBIT directive as well as the TEXT directives. This might help someone coming in from another system expecting it to be "backwards".
10) TEXT is not limited to upper-case only. Look at my code in Kermit-12 where upper/lower case messages are stored in space-saving 6-bit TEXT strings. The reason is that it supports a case-shift character and I chose ^ as the character you cannot print. [An alternate implementation could be to make a convention where two of them means to print one of them, but I didn't think I need it there.] The main advantage is that most messages stick mostly with one case, and likely lower-case. Thus, the overhead of switching is localized and minimal; 7 bit messages always waste space, or you have to concoct 3-for-2 strings to come close. However, there are no standard assembler directives to even do that. [I will consider adding something once much more code is written.] It also reserves % to not be printable [see above about an alternative] which stands for CR/LF in a multiple line message string, the design mission.
A small factoid: P?S/8 BIN utility supports punching binary on paper-tapes in what can be called BIN_OR_RIM format. BIN format demands only an origin setting when needed; RIM format demands an origin setting for each loaded word; some have written source code with origin states imbedded. That's the format I am describing; since it overall is BIN, you do get a final checksum and compatibility with BIN, but because there are the mandatory origin settings, RIM also likes it. In the P?S/8 BIN utility, the origin settings are added without having to create the source code to create it. The checksum at the end maintains the dual compatibility. [Note: either/or format must avoid FIELD settings!]
0 new messages