Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Safer programming languages (and walking :-) ), was: Re: 8-bit characters

44 views
Skip to first unread message

Rich Alderson

unread,
May 27, 2022, 9:50:18 PM5/27/22
to
Moving the discussion to alt.folklore.computers, because it's gone way beyond
the interest levels at comp.os.vms by now, I'm sure.

gah4 <ga...@u.washington.edu> writes:

> On Thursday, May 26, 2022 at 2:54:31 PM UTC-7, Rich Alderson wrote:

> (snip)

>>> Looking at an actual IBM manual, it seems that the 64 opcodes map to
>>> the 64 characters in the character set, and those characters are used
>>> to represent them. That is, base 64.

>>> Some others might represent those in octal, but yes I don't see IBM doing
>>> it.

>> Yeah, it wasn't called "base 64". It was called "BCD", and they were simply
>> treated as alphanumerics and special characters.

>> The B bit corresponds to the 11 zone punch on a card, the A bit to the 0
>> zone punch, and BA corresponds to the 12 zone punch.

>> All 0's is the SPACE character; the "0" character is the 8+2 bits.

> The 704 uses a 48 character version of BCD, though I didn't match
> up the character codes. The documentation of opcodes uses octal.

The 704 is completely irrelevant to the previous discussion, since it is a word
addressed (36 bits/word) scientific computer, where the 14xx family are
character addressed business computers. The only thing they have in common is
the name of the manufacturer.

> I didn't see actual assembler output for either one, but in the instruction
> tables the BCD character is used as the numeric opcode for the 1401,
> where others would put the octal (or later hexadecimal) opcode.

Yeah, that's what I said.

> Now, since the 704 only has 48 characters in its BCD, not enough for
> all the opcodes, maybe that isn't so surprising.

>> NB: The card codes on the "96 column cards" used by the System/3 are the
>> same as the 14xx BCD representation in memory.

> It seems that System/3 cards can be either six bit BCD, or 8 bit EBCDIC. In
> the latter case, the extra two rows of punches go above, where the printed
> text goes. I am not sure how the two codes work together.

Interesting. I only encountered the System/3 in passing, and used to have a
small stack of the cards with the numerically ordered punches. That's how I
learned about the correspondence.

> I do remember knowing, not so many years ago, that there was a System/3 card
> read/punch for the 360/20, but never saw one.

> The 704 has some strange features with its character code. Among others, they
> used even parity tape (must have seemed like a good idea) where you can't
> write the character with all bits zero. (No transitions means no clock.)

The 1401 also used 7-bit even parity NRZ tape, IIRC. We didn't have tapes on
our machine, just a 1402 reader/punch and a pair of 1311 disk drives.

> I didn't look to see what the 1401 ALU generates for its decimal output,
> but I presume the 8-2 code.

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Quadibloc

unread,
Jun 7, 2022, 1:49:36 AM6/7/22
to
On Friday, May 27, 2022 at 7:50:18 PM UTC-6, Rich Alderson wrote:
> gah4 <ga...@u.washington.edu> writes:

> > The 704 has some strange features with its character code. Among others, they
> > used even parity tape (must have seemed like a good idea) where you can't
> > write the character with all bits zero. (No transitions means no clock.)
>
> The 1401 also used 7-bit even parity NRZ tape, IIRC.

Which is, of course, why BCD included the "substitute blank" character which
could be written on a tape everywhere where a space would have been called
for.

But I do think that choosing even parity instead of odd parity as the default,
so that such expedients are necessary, is not just strange, but an obvious
mistake.

However, it does mean that blank areas of the tape aren't counted as an
error... since with odd parity, there are codes with just one 1 bit, which could
then look like blank tape with a single error. So that's probably why even
parity was used - in order that the error detection property of a parity
bit would fully work in practice. The price of having only 63 usable codes
was seen as reasonable because the tapes tended to be used for character
data and not binary data.

John Savard

Quadibloc

unread,
Jun 7, 2022, 2:26:55 AM6/7/22
to
Given that there's a reason for even parity and substitute blank... now that
I've thought of it, as I have a page on my web site

http://www.quadibloc.com/comp/tapeint.htm

dealing with magnetic tape recording on computers, I edited it now to
add this new information there!

John Savard

Quadibloc

unread,
Jun 7, 2022, 5:09:45 AM6/7/22
to
On Tuesday, June 7, 2022 at 12:26:55 AM UTC-6, Quadibloc wrote:

> Given that there's a reason for even parity and substitute blank... now that
> I've thought of it, as I have a page on my web site
>
> http://www.quadibloc.com/comp/tapeint.htm
>
> dealing with magnetic tape recording on computers, I edited it now to
> add this new information there!

And I've made an additional correction - since the zone bits of characters
are modified for magnetic tape, substitute blank substitutes for the zero,
not the space.

John Savard

Quadibloc

unread,
Jun 7, 2022, 5:18:30 AM6/7/22
to
On Tuesday, June 7, 2022 at 3:09:45 AM UTC-6, Quadibloc wrote:

> And I've made an additional correction - since the zone bits of characters
> are modified for magnetic tape, substitute blank substitutes for the zero,
> not the space.

...also, from looking things up, I now see the reason for using even parity
for character data.
Using odd parity is simple enough, one just has to add characters to the
record format to clearly distinguish between where the record with its
data is, and where the blank gaps between records are.
But not having to do that, by using even parity, simplifies the design of
auxilliary equipment like card-to-tape units.

John Savard
0 new messages