2 Dec
2016
2 Dec
'16
5:29 p.m.
I'm not sure if it would make a difference but in your membership options to the list
you can choose the format of the messages and how you'd like to receive them. I know
my settings are plain text but I haven't played with the others to know if they have
an option like that.
The only time I've seen base 64 coded stuff are spam pop-ups trying to bypass
plaintext filters. Interesting to hear there's some legitimate usage happening.
-------- Original message --------From: jonas at otter.se Date: 12/2/16 4:45 AM
(GMT-06:00) To: cctech at classiccmp.org Subject: Base 64 posts to the list
some list posts have begun appearing in Base 64 format. I read
the list in daily digest mode, and these posts are not converted to
anything sensible
4 Dec
4 Dec
8:10 p.m.
Thanks for the suggestion. My delivery was set to MIME, I have changed
it to plain text. Hopefully that will solve the problem.
On 12/02/2016 06:29 PM, Sam O'nella wrote:
I'm not sure if it would make a difference but in
your membership options to the list you can choose the format of the messages and how
you'd like to receive them. I know my settings are plain text but I haven't played
with the others to know if they have an option like that.
The only time I've seen base 64 coded stuff are spam pop-ups trying to bypass
plaintext filters. Interesting to hear there's some legitimate usage happening.
8:39 p.m.
On Sun, Dec 4, 2016 at 12:10 PM, Jonas Otter <jonas at otter.se> wrote:
Thanks for the suggestion. My delivery was set to
MIME, I have changed it
to plain text. Hopefully that will solve the problem.
What? No format flame war? What's this world coming to?
--
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School <http://ischool.uw.edu>
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens
Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org>
Value Sensitive Design Research Lab <http://vsdesign.org>
University of Washington
There is an old Vulcan saying: "Only Nixon could go to China."
5 Dec
5 Dec
2:35 p.m.
Thanks for the
suggestion. My delivery was set to MIME, I have changed it
to plain text. Hopefully that will solve the problem.
What? No format flame war? What's this world coming to? 
3:36 p.m.
On Mon, Dec 5, 2016 at 6:35 AM, Cameron Kaiser <spectre at floodgap.com> wrote:
emacs sucks!
*waits patiently*
--
Little-endian!!!
]
-- Charles
> Thanks
for the suggestion. My delivery was set to MIME, I have changed
it
to plain
text. Hopefully that will solve the problem.
What? No format flame war? What's this world coming to? 
4:03 p.m.
On Mon, Dec 05, 2016 at 07:36:19AM -0800, Charles Anthony wrote:
On Mon, Dec 5, 2016 at 6:35 AM, Cameron Kaiser
<spectre at floodgap.com> wrote:
emacs sucks!
*waits patiently*
--
Little-endian!!!
Middle-endian FTW!!!!
>
Thanks for the suggestion. My delivery was set to MIME, I have changed
it
to plain
text. Hopefully that will solve the problem.
What? No format flame war? What's this world coming to? ]
-- Charles
-- Diane
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
4:51 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Little-endian!!!
Middle-endian FTW!!!! 
5:17 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 08:51 AM, Mouse wrote:
Little- and big-endian do this; conversion between them is
byteswapping, which is self-inverse. Conversion between
PDP11-endian (0x87654321 stored as 0x65 0x87 0x21 0x43) and either
big- or little-endian is also self-inverse. Is there any hardware
for which conversion between its native storage format and any of
these three is not self-inverse? To put it another way, and rather
more loosely, is there one for which htonl and ntohl are actually
different operations?
Decimal machines, such as the 1620 and 1401? Of course, these aren't
word-oriented machines either, but variable-length systems. Conversion
between either of those and your VAX is not simply a matter of
byte-swapping.
Or how about architectures not using a word length that's an integral
number of bytes?
--Chuck
7:14 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of David
Bridgham
Sent: 05 December 2016 18:37
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 12:17 PM, Chuck Guzis wrote:
Honeywell L66 & DPS8 used to have 36 bit words which originally contained 6
x 6-bit characters.
When they extended the machines to work with ASCII they put 4 x 9-bit
characters which I seem to
remember they called 9-bit bytes..
Dave
Or how about architectures not using a word
length that's an integral
number of bytes?
You mean like any 36-bit machine?
8:10 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Mon, Dec 5, 2016 at 11:14 AM, Dave Wade <dave.g4ugm at gmail.com> wrote:
4
padding bits scattered through the word).
-----Original
Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of David
Bridgham
Sent: 05 December 2016 18:37
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 12:17 PM, Chuck Guzis wrote:
Honeywell L66 & DPS8 used to have 36 bit words which originally contained 6
x 6-bit characters.
When they extended the machines to work with ASCII they put 4 x 9-bit
characters which I seem to
remember they called 9-bit bytes..
Yes; the Extended Instruction set handles 4*9bit, 6*6bit, 8*4bit (with the Or how about architectures not using a word
length that's an integral
number of bytes?
You mean like any 36-bit machine? From memory:
PDP-10: 36 bit word, 5*7bit characters.
PDP-15: 18 bit word, but it was so long ago, I don't remember....
CDC 6000: 60 bit word, 10 six bit characters.
PDP11 "middle endian" see "NUXI problem:
http://www.catb.org/jargon/html/M/middle-endian.html
PDP11 RADIX-50 3 characters packed into a 16 bit word; each character in a
0:39 set.
Back to Der Mouse question re: non-symmetrical mapping....
hton and ntoh are not meant has generalized data conversion; they are
intended as network data packet field conversion; the domain of ntohl is a
32bit unsigned integer; the range is a host object larger enough to contain
all possible values.
For hosts that are base 2 and have word sizes that divide 32bits evenly,
the functions would typically be identity or bit rearrangement, and the
htonl and ntohl functions would be symmetric -- I suspect that a good
mathematician could 'prove' that cycle length is always 2 given the
constraints.
Cases like 36 bits words mean that htonl is "lossy"; it throws away bits
and and ntohl pads the result with 0s -- they are not symmetrical, thus the
answer to the order-2 cycle question is 'not applicable'
-- Charles
9:09 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Charles Anthony wrote:
As Charles wrote, the PDP-10 commonly uses 7-bit bytes for ASCII text,
but that's only part of the truth. The architecture is quite byte size
agnostic. There are instructions to operate on any byte size from 1 to
36 bits, at any position inside a word. (Well, a later extension to the
architecture restricted this a bit.)
PDP-10: 36 bit word, 5*7bit characters.
Mouse wrote:
You mean like
any 36-bit machine?
No, they usually either ran as 6 6-bit bytes or 4 9-bit bytes,
from
what I understand.
6 Dec
6 Dec
2:14 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 01:09 PM, Lars Brinkhoff wrote:
As Charles wrote, the PDP-10 commonly uses 7-bit bytes
for ASCII
text, but that's only part of the truth. The architecture is quite
byte size agnostic. There are instructions to operate on any byte
size from 1 to 36 bits, at any position inside a word. (Well, a
later extension to the architecture restricted this a bit.)
I've seen PDP-10 9-track tapes done two ways--one character per frame
and then 4 frames (36 bits) with 5 7-bit characters and the sign bit
left over.
--Chuck
7 Dec
7 Dec
8:46 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Chuck Guzis
Sent: Monday, December 05, 2016 6:15 PM
On 12/05/2016 01:09 PM, Lars Brinkhoff wrote:
> As Charles wrote, the PDP-10 commonly uses 7-bit
bytes for ASCII
> text, but that's only part of the truth. The architecture is quite
> byte size agnostic. There are instructions to operate on any byte
> size from 1 to 36 bits, at any position inside a word. (Well, a
> later extension to the architecture restricted this a bit.)
The restriction Lars mentions only applies to what are referred to as
One-Word Global Byte Pointers (OWGBPs), which encode the divisions of
a 36-bit word into 6, 7, 8, 9, or 18 bit bytes into a 6-bit value in
the high-order bits of a word with a 30-bit address filling the rest.
There are also Two-Word Global Byte Pointers (which I've never seen
abbreviated) which carry the standard "any size byte at any position"
in the first word, with a zero address in the right half, and the
30-bit extended address (with 0's in the 6 high-order bits) in the
second.
I've seen PDP-10 9-track tapes done two ways--one
character per frame
and then 4 frames (36 bits) with 5 7-bit characters and the sign bit
left over.
Neither of those is entirely accurate. 9-track tapes on the PDP-10 used
one of the following encodings:
1. Core-Dump: 4 frames of 8 bits, 5th frame with 4 leading 0's (or 0100
on one type of controller) and the last 4 bits.
2. Industry-Compatible: 4 frames of 8 bits, and ignore the low order 4.
3. ANSI-ASCII: 4 frames of 7 bits padded with a leading 0, 5th frame with
low order bit (B35) followed by the remaining 7 bits. In this case,
B35 is usually 0, but in the case of line-numbered files B35 = 1 is
the indicator that the 5 ASCII digits are a line number (and the
parity bit is set incorrectly on the tape).
4. High-Density: 4 frames of 8 bits, 5th frame has low order 4 bits of
the 1st word in its high order bits + high order 4 bits of the 2nd
word in its low order bits, then 4 frames of 8 bits finishing up the
2nd word.
I've been dealing with PDP-10 tapes for 40 years now.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
8 Dec
8 Dec
6:42 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/07/2016 12:46 PM, Rich Alderson wrote:
Neither of those is entirely accurate. 9-track tapes
on the PDP-10
used one of the following encodings:
The last time that I had to deal with PDP-10 tapes, admittedly also 40
years ago was essentially core-dump format. 5 7-bit characters per
word, with one bit unused; words packed end-to-end; i.e. 9 frames for 2
PDP 10 words.
It was the "Adventure" game, smuggled to me by a DEC field engineer.
Translating to CDC display code and then dealing with the differences in
FORTRAN made the work interesting. The thing spread like wildfire
throughout the CDC corporate system and was ardently hunted and purged
by COMSOURCE administrators.
--Chuck
7:03 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/7/2016 10:42 PM, Chuck Guzis wrote:
On 12/07/2016 12:46 PM, Rich Alderson wrote:
The Multics version I saw came from a Fortran version taken from a
PDP10. If I'm not mistaken it was directly from the timeshare system
they used in Billerica,Ma where Don Woods worked. After some massaging
it was unleashed on Multics. Most of Honeywell was wiped out by copies
on various machines for quite some time (2 or 3 months?) before people
quit risking getting into trouble to play it anyway.
There were two files, the main fortran file, and the table file with the
cave encoding. I suspect anyone who got a copy of the latter, and read
the former wrote a program to print out a very useful cheat sheet. If
you had that, you could solve all of the puzzles from data in the table,
and you only had to worry about the problems associated with random
behavior.
The PDP-10 source did have a schedule feature to allow the game to only
be played during certain hours, but in the copy we were running that was
bypassed to allow it to run 24 / 7.
thanks
Jim
Neither of those is entirely accurate. 9-track
tapes on the PDP-10
used one of the following encodings:
The last time that I had to deal with PDP-10
tapes, admittedly also 40
years ago was essentially core-dump format. 5 7-bit characters per
word, with one bit unused; words packed end-to-end; i.e. 9 frames for 2
PDP 10 words.
It was the "Adventure" game, smuggled to me by a DEC field engineer.
Translating to CDC display code and then dealing with the differences in
FORTRAN made the work interesting. The thing spread like wildfire
throughout the CDC corporate system and was ardently hunted and purged
by COMSOURCE administrators.
--Chuck
5:51 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/07/2016 11:03 PM, jim stephens wrote:
The Multics version I saw came from a Fortran version
taken from a
PDP10. If I'm not mistaken it was directly from the timeshare
system they used in Billerica,Ma where Don Woods worked. After some
massaging it was unleashed on Multics. Most of Honeywell was wiped
out by copies on various machines for quite some time (2 or 3
months?) before people quit risking getting into trouble to play it
anyway.
There were two files, the main fortran file, and the table file with
the cave encoding. I suspect anyone who got a copy of the latter,
and read the former wrote a program to print out a very useful cheat
sheet. If you had that, you could solve all of the puzzles from data
in the table, and you only had to worry about the problems associated
with random behavior.
The PDP-10 source did have a schedule feature to allow the game to
only be played during certain hours, but in the copy we were running
that was bypassed to allow it to run 24 / 7.
That sounds right. I also remember the process in the PDP10 version
involved saving the entire core image of the game. While I didn't make
a cheat sheet from the travel tables, a couple of friends did.
ADVENTure turned out to be a huge black hole for employees' time. I
never owned up to being the ne'er do well who introduced it--it could
have turned into a big obstacle in my career had the facts been known.
I loosed the source on the landscape like a bunch of locusts--my name
never appeared anywhere in the CDC adaptation.
But I never took to the game very much. I've never been one for
computer games and wheile Adventure was interesting, I grew
disinterested after about a week. I knew people who'd sit at the 6600
operator's console playing Chess 3.0 for hours in the middle of the
night, but the idea of playing against a machine held no fascination.
That has proved to be the pattern ever since for computer games. When I
wrote SIMCGA for the Hercules-Graphics-equipped PC, publishers would
send me games to try out. None of them did a thing for me other than
make some money.
I must have the wrong mindset. Does computer chess hold any interest
today? Or is the matter of machine-over-human pretty much a fait accompli?
--Chuck
9 Dec
9 Dec
6:48 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Thu, Dec 8, 2016 at 9:51 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 12/07/2016 11:03 PM, jim stephens wrote:
I must have the wrong mindset. Does computer chess hold any interest
today? Or is the matter of machine-over-human pretty much a fait accompli?
--Chuck
I'll run thru some moves with any new chess program I find. I'm so rusty
and try such oddball moves in messing with them that I lose too much of the
time.
I first had a copy of Sargon for the Apple 2 eons ago, and it was
impressive for the time. Also useful for doing study of positions and the
like too.
I really like Adventure and got totally geeked out meeting Don Woods @ VCF
West (thanks guys who put on VCF West again)
Thanks
Jim
3:28 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Chuck
I was just trying to squeeze Peter Jennings code for the KIM-1 into a single
1K worth of EPROM that would self load. There was enough space if I didn't
include the opening moves. I wanted to use the empty space in my KIM-1 debug board EPROM.
Some of the test use so little space. I finally split it into
two blocks. So once one gets their KIM-1 working again, they can play MicroChess.
I've not tried to play it yet. I have to pull out my chess board.
So, some interest in Chess playing. I have my KIM-1 working on my prototype
6532 to 6530 adapter.
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of jim stephens
<james.w.stephens at gmail.com>
Sent: Thursday, December 8, 2016 10:48:05 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Thu, Dec 8, 2016 at 9:51 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 12/07/2016 11:03 PM, jim stephens wrote:
I must have the wrong mindset. Does computer chess hold any interest
today? Or is the matter of machine-over-human pretty much a fait accompli?
--Chuck
I'll run thru some moves with any new chess program I find. I'm so rusty
and try such oddball moves in messing with them that I lose too much of the
time.
I first had a copy of Sargon for the Apple 2 eons ago, and it was
impressive for the time. Also useful for doing study of positions and the
like too.
I really like Adventure and got totally geeked out meeting Don Woods @ VCF
West (thanks guys who put on VCF West again)
Thanks
Jim
4:24 p.m.
New subject: Microchess, Nanochess, etc - Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 2016-12-09 10:28 AM, dwight wrote:
Chuck
I was just trying to squeeze Peter Jennings code for the KIM-1 into a single
1K worth of EPROM that would self load. There was enough space if I didn't
include the opening moves. I wanted to use the empty space in my KIM-1 debug board EPROM.
Some of the test use so little space. I finally split it into
two blocks. So once one gets their KIM-1 working again, they can play MicroChess.
I've not tried to play it yet. I have to pull out my chess board.
So, some interest in Chess playing. I have my KIM-1 working on my prototype
6532 to 6530 adapter.
Dwight
If you're into tiny chess programs, ?scar Toledo G. (@nanochess) has
written a few, including a 1K JavaScript chess, and a 481 byte x86 version.
http://nanochess.org/chess.html
--Toby
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of jim stephens
<james.w.stephens at gmail.com>
Sent: Thursday, December 8, 2016 10:48:05 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Thu, Dec 8, 2016 at 9:51 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 12/07/2016 11:03 PM, jim stephens wrote:
I must have the wrong mindset. Does computer chess hold any interest
today? Or is the matter of machine-over-human pretty much a fait accompli?
--Chuck
I'll run thru some moves with any new chess program I find. I'm so rusty
and try such oddball moves in messing with them that I lose too much of the
time.
I first had a copy of Sargon for the Apple 2 eons ago, and it was
impressive for the time. Also useful for doing study of positions and the
like too.
I really like Adventure and got totally geeked out meeting Don Woods @ VCF
West (thanks guys who put on VCF West again)
Thanks
Jim
17 Dec
17 Dec
9:59 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Here's a tickler for the list...
I've used bit-addressable machines, where individual bits were directly
addressed without regard to their position within a byte or word. E.g.,
a system with 48 bit addresses, where the lower 3 bits of an address
specified the bit within a byte; the next 3 specified the address of a
byte within a (64 bit) word, and so on. Bit vectors were an important
part of the architecture.
What perplexed me is that the address of 0000 0 0 specified the first
bit in byte 0 of word 0, but that same bit was the *high order* bit in
the corresponding byte and word. It would seem to make more sense
reversing the significance of bits in a byte and bytes in a word such
that the lowest-numbered addresses corresponded to the least-significant
bits in a word or byte.
Call it "extreme little endianess". Does anyone know of such an
architecture?
--Chuck
18 Dec
18 Dec
1:50 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Sat, Dec 17, 2016 at 2:59 PM, Chuck Guzis <cclist at sydex.com> wrote:
What perplexed me is that the address of 0000 0 0
specified the first
bit in byte 0 of word 0, but that same bit was the *high order* bit in
the corresponding byte and word. It would seem to make more sense
reversing the significance of bits in a byte and bytes in a word such
that the lowest-numbered addresses corresponded to the least-significant
bits in a word or byte.
Call it "extreme little endianess". Does anyone know of such an
architecture?
The IBM 7030 "Stretch" was bit-addressable for integer operations, but not
for floating point or instructions. It used typical IBM big-endian bit
numbering, with bit 0 being the most significant bit.
The TI TMS34010 and TMS34020 graphics processors were bit-addressable,
though instructions had to be 16-bit aligned. The TMS34010 and the default
mode of the TMS34020 were little-endian, with bit 0 being the least
significant bit. The TMS34020 has configurable support for big-endian
memory addressing.
4:41 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/17/2016 05:50 PM, Eric Smith wrote:
The TI TMS34010 and TMS34020 graphics processors were
bit-addressable, though instructions had to be 16-bit aligned. The
TMS34010 and the default mode of the TMS34020 were little-endian,
with bit 0 being the least significant bit. The TMS34020 has
configurable support for big-endian memory addressing.
I'd forgotten about the TIGA chips, thanks.
--Chuck
8 Dec
8 Dec
8:55 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Chuck Guzis
Sent: Wednesday, December 07, 2016 10:43 PM
On 12/07/2016 12:46 PM, Rich Alderson wrote:
> Neither of those is entirely accurate. 9-track
tapes on the PDP-10
> used one of the following encodings:
The last time that I had to deal with PDP-10 tapes,
admittedly also 40
years ago was essentially core-dump format. 5 7-bit characters per
word, with one bit unused; words packed end-to-end; i.e. 9 frames for 2
PDP 10 words.
That sounds more like high density format, if there were 9 frames for 2
words (i.e., 72 bits total). Core dump format would require 10 frames.
The 5 characters per word is irrelevant to a discussion of tape, whether
9- or 7-track: That's how ASCII text was represented in memory, on disk,
on DECtape, or on any other word-oriented medium. Representing the bits
in an ASCII character by the character itself (to make divisions on the
tape more clear), this appears diagrammatically as follows:
Text: HELLOworld
Memory:
HHHHHHHEEEEEEELLLLLLLLLLLLLLOOOOOOO_wwwwwwwooooooorrrrrrrlllllllddddddd_
Core Dump: High Density: SIXBIT: (7 track)
HHHHHHHE HHHHHHHE HHHHHH
EEEEEELL EEEEEELL HEEEEE
LLLLLLLL LLLLLLLL EELLLL
LLLLOOOO LLLLOOOO LLLLLL
....OOO_ OOO_wwww LLLLOO
wwwwwwwo wwwooooo OOOOO_
oooooorr oorrrrrr wwwwww
rrrrrlll rlllllll wooooo
lllldddd ddddddd_ oorrrr
....ddd_ rrrlll
lllldd
ddddd_
where _ represents the unused bit 35 in the word and . represents the
don't-care bits inserted by the tape controller/formatter for core dump.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
9 Dec
9 Dec
7:49 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Rich Alderson <RichA at livingcomputers.org> writes:
The 5 characters per word is irrelevant to a
discussion of tape, whether
9- or 7-track: That's how ASCII text was represented in memory, on disk,
on DECtape, or on any other word-oriented medium. Representing the bits
in an ASCII character by the character itself (to make divisions on the
tape more clear), this appears diagrammatically as follows:
Text: HELLOworld
Memory:
HHHHHHHEEEEEEELLLLLLLLLLLLLLOOOOOOO_wwwwwwwooooooorrrrrrrlllllllddddddd_
Core Dump: High Density: SIXBIT: (7 track)
HHHHHHHE HHHHHHHE HHHHHH
EEEEEELL EEEEEELL HEEEEE
LLLLLLLL LLLLLLLL EELLLL
LLLLOOOO LLLLOOOO LLLLLL
....OOO_ OOO_wwww LLLLOO
wwwwwwwo wwwooooo OOOOO_
oooooorr oorrrrrr wwwwww
rrrrrlll rlllllll wooooo
lllldddd ddddddd_ oorrrr
....ddd_ rrrlll
lllldd
ddddd_
Let's add ANSI-ASCII:
.HHHHHHH
.EEEEEEE
.LLLLLLL
.LLLLLLL
_OOOOOOO
.wwwwwww
.ooooooo
.rrrrrrr
.lllllll
_ddddddd
The nice property with this format is that ASCII text in 36-bit words
comes out as ASCII text in octets, while also preserving binary 36-bit
data.
8 Dec
8 Dec
10:20 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Rich Alderson wrote:
From: Chuck Guzis
Sent: Monday, December 05, 2016 6:15 PM
I know nothing about physical magtapes. I have seen this comment about
the MIT ITS machines:
I've seen PDP-10 9-track tapes done two
ways--one character per frame
and then 4 frames (36 bits) with 5 7-bit characters and the sign bit
left over.
Neither of those is entirely accurate. 9-track tapes on the PDP-10
[...] DM had the only 9-track tape drive; the other machines
had 7-track
tapes, as befit 36-bit machines.
So I suppose many ITS tapes would have stored six frames per word.
9 Dec
9 Dec
6:43 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Rich Alderson wrote:
There are also Two-Word Global Byte Pointers (which
I've never seen
abbreviated) which carry the standard "any size byte at any position"
Maybe they were just Global Byte Pointers? OWG's were a late
addition. I was a member of the FORTRAN-10/20 v10 project to make it
generate/run code in extended addressing... It's tempting to look at
the compiler and FOROTS to see what terms we used a the time...
Neither of those is entirely accurate. 9-track tapes
on the PDP-10 used
one of the following encodings:
8-bit characters became more important near the end of PDP-10 software
development. ISTR TOPS-10 getting new 8-bit I/O modes, but I have a
vague recollection that translation between 36-bit words and mag tape
frames was handled by the "tape formatter" hardware, which means that
writing two words with 8 bit bytes in way that was easily legible on
8-bit byte oriented hardware ("high density mode" was only "legible"
for the even words).
phil
7:47 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Phil Budne
Sent: Friday, December 09, 2016 10:44 AM
Rich Alderson wrote:
> There are also Two-Word Global Byte Pointers
(which I've never seen
> abbreviated) which carry the standard "any size byte at any position"
Maybe they were just Global Byte Pointers? OWG's
were a late
addition. I was a member of the FORTRAN-10/20 v10 project to make it
generate/run code in extended addressing... It's tempting to look at
the compiler and FOROTS to see what terms we used a the time...
Both One-Word and Two-Word Global Byte Pointers were added at the same
time as extended addressing, according to the HRM. Simple "Global Byte
Pointer" would have been inherently ambiguous.
OWGBPs were a way not to increase the memory footprint of a program when
moving it into a non-zero section,[1] at the expense of some microcode.
In theory, a binary could be patched for use in a non-zero section without
a recompile, as long as it was using 6-, 7-, 8-, 9-, or 18-bit bytes.
> Neither of those is entirely accurate. 9-track
tapes on the PDP-10 used
> one of the following encodings:
8-bit characters became more important near the end of
PDP-10 software
development. ISTR TOPS-10 getting new 8-bit I/O modes, but I have a
vague recollection that translation between 36-bit words and mag tape
frames was handled by the "tape formatter" hardware, which means that
writing two words with 8 bit bytes in way that was easily legible on
8-bit byte oriented hardware ("high density mode" was only "legible"
for the even words).
Yes, all the translations are handled in the formatter, which is part of
the tape controller. To continue the example, in Industry-Compatible
format, where the ASCII characters have been moved into 8-bit bytes in
36-bt words, on 9-track tape we have "HELLOworld" as
_HHHHHHH
_EEEEEEE
_LLLLLLL
_LLLLLLL
_OOOOOOO
_wwwwwww
_ooooooo
_rrrrrrr
_lllllll
_ddddddd
In memory, this takes 3 words:
_HHHHHHH_EEEEEEE_LLLLLLL_LLLLLLL....
_OOOOOOO_wwwwwww_ooooooo_rrrrrrr....
_lllllll_ddddddd________________....
Rich
[1] For non-PDP10 programmers: The original architecture of the PDP-6 and
PDP-10 used an 18-bit (256KW) address space. The KI-10 processor added
a 22-bit pager and a concept of sections to the hardware. When the
address space was expanded to 30 bits (1MW) on the KL-10 processor (in
anticipation of the KC-10 a/k/a "Jupiter"), it was done by retaining
18-bit local addressing and adding a 12-bit section number to provide
global addresses. Section 0 is special, working like the older 256KW
memory space; non-zero sections can reference all of memory, with an
18-bit address in a non-zero section being section local and a 30-bit
address referencing anything except section 0.
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
10 Dec
10 Dec
2:36 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Both One-Word and Two-Word Global Byte Pointers were
added at the same
time as extended addressing, according to the HRM. Simple "Global Byte
Pointer" would have been inherently ambiguous.
OWG's were added to the KL ucode later:
;251 ADD CODE FOR ONE WORD GLOBAL BYTE POINTERS.
; TOOK OUT EDITS 243 AND 250 TO GET ENOUGH SPACE IN CRAM
; FOR THIS EDIT. OWGBP WITH EXTEND INSTRUCTIONS WILL NOT
; RETURN A OWGBP. THEY WILL RETURN A TWO WORD GLOBAL BP.
I can't tell off hand if there was a TOPS-20 release that supported
extended addressing earlier than UCODE version 251.
Hey! here's a ref to TWG's in the UCODE history:
;336 9 Aug 83--Back off 330 for a bit, since TOPS-10 7.02 must be tested
; and OWGs in section 0 fail for string instructions (they get converted
; to TWGs, which are illegal in section 0). For now, we will maintain
; both sources.
Maybe I'm conflating things with the legalization of OWGs in section zero
(the low 256KW of address space that behaved like a non-extended machine)
The KI-10 processor added
a 22-bit pager and a concept of sections to the hardware.
Are you sure? KI (aka TOPS-10) paging may have extended the physical
address space, but not the virtual address space (still limited to 18 bits).
In the end TOPS-10 used "KL" paging: DECnet had to live in a non-zero
section in the monitor (in 7.02?), and user-mode extended address was
finally added later.
11 Dec
11 Dec
2:38 a.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On Fri, Dec 9, 2016 at 12:47 PM, Rich Alderson <RichA at livingcomputers.org>
wrote:
[1] For non-PDP10 programmers: The original
architecture of the PDP-6 and
PDP-10 used an 18-bit (256KW) address space. The KI-10 processor added
a 22-bit pager and a concept of sections to the hardware.
As you say, the KI10 had 22-bit physical memory addressing, almost
identical to the "KI paging" of the later Model A KL10. There were two
PTEs per 36-bit word in the page table, with the five of the 18 bits being
the APWSX properties, and the remaining 13 being a physical page number.
The 13-bit physical page number was concatenated with the offset into the
512-word page (low 9 bits of the virtual address) to get the 22-bit
physical address.
However, the KI10 did not have any "sections". Sections were introduced
with the Extended ("Model B", "KL paging") KL10.
14 Dec
14 Dec
midnight
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
From: Eric Smith
Sent: Saturday, December 10, 2016 6:38 PM
On Fri, Dec 9, 2016 at 12:47 PM, Rich Alderson
<RichA at livingcomputers.org>
wrote:
> [1] For non-PDP10 programmers: The original
architecture of the PDP-6
> and PDP-10 used an 18-bit (256KW) address space. The KI-10
> processor added a 22-bit pager and a concept of sections to the
> hardware.
As you say, the KI10 had 22-bit physical memory
addressing, almost
identical to the "KI paging" of the later Model A KL10. There were two
PTEs per 36-bit word in the page table, with the five of the 18 bits
being the APWSX properties, and the remaining 13 being a physical page
number. The 13-bit physical page number was concatenated with the
offset into the 512-word page (low 9 bits of the virtual address) to
get the 22-bit physical address.
However, the KI10 did not have any
"sections". Sections were introduced
with the Extended ("Model B", "KL paging") KL10.
I knew that was wrong just as soon as I had hit "Send", but I also knew
that I could count on one of the PDP-10 subgroup to fix that.
Thanks!
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
5 Dec
5 Dec
8:13 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 10:37 AM, David Bridgham wrote:
On 12/05/2016 12:17 PM, Chuck Guzis wrote:
Or any 12 or 60 bit machine.
--Chuck
Or how about architectures not using a word
length that's an
integral number of bytes?
You mean like any 36-bit machine?
8:50 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Or how about
architectures not using a word length that's an
integral number of bytes?
You mean like any 36-bit machine? 
6:38 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
On 12/05/2016 11:51 AM, Mouse wrote:
Not quite the same thing but weren't longwords on the PDP-11
little-endian for the bytes within the word but big-endian for words
within the longword?
Middle-endian
FTW!!!!
That makes me wonder: was there any hardware that used an endianness
such that conversion didn't loop with period 2?
8:52 p.m.
New subject: Odd "endianness" [was Re: RE: Base 64 posts to the list]
Middle-endian FTW!!!!
That makes me wonder: was
there any hardware that used an endianness
such that conversion didn't loop with period 2? Conversion between PDP11-endian (0x87654321 stored as
0x65 0x87 0x21
0x43) and [...]
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
4:05 p.m.
On 5 December 2016 at 15:35, Cameron Kaiser <spectre at floodgap.com> wrote:
emacs sucks!
I agree. So does Vi.
*waits patiently*
There, does that help? :-)
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? Google Mail/Talk/Plus: lproven at gmail.com
Twitter/Facebook/Flickr: lproven ? Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 ? ?R/WhatsApp/Telegram/Signal: +420 702 829 053
7 Dec
7 Dec
8:18 p.m.
From: Cameron Kaiser
Sent: Monday, December 05, 2016 6:35 AM
>> Thanks for the suggestion. My delivery was set
to MIME, I have changed it
>> to plain text. Hopefully that will solve the problem.
> What? No format flame war? What's this world
coming to?
emacs sucks!
*waits patiently*
Well, sure, if you load the suckit.el library, but that's optional. It's
faster if you load the compiled suckit.elc instead.
I prefer the compiled TECO variant BITEME.:EJ, of course!
;-)
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
8 Dec
8 Dec
6:37 a.m.
New subject: EMACS folly
Rich Alderson wrote:
Well, sure, if you load the suckit.el library, but
that's optional. It's
faster if you load the compiled suckit.elc instead.
I prefer the compiled TECO variant BITEME.:EJ, of course!
Loaded into GNU Emacs? ;-)
Hey, do you have any VAXen over there? How about getting an early Emacs
running on those? I turned the Internet inside out to find Gosling
Emacs, BTL Emacs, and GNU Emacs 15 and 17, and and it would be a shame
if the source code was just sitting idle.
Or how about TECO EMACS? Only not on the PDP family you'd expect, but
the 16-bit flavor.
9:07 p.m.
New subject: EMACS folly
Hi, Lars,
I actually met someone once who tried to implement an interpreter for TECO code
in Emacs Lisp, in order to load EMACS.:EJ and run it, just for the hack value.
I don't know whether he ever completed the project. :-)
We have a VAX-11/780-5 (a 780 field upgraded to a 785) running VMS 7.3. It's
hard to get to because some botnet is constantly pounding on it with 10 connections
per second, trying to break in. It makes the LOGIN program time out on passwords.
If you would like to try bringing those up, use the account request form on our
web site and send me a note to let me know to look for the request. I have not
been opening new accounts because of the frustration inherent in trying to log in.
I think I'm remembering the name correctly: Pete Siemsen wrote a new PDP-11 TECO
back in the late 1980s which he presented at the DECUS Fall Symposia in Anaheim
(so 1988, I think). After his talk, a couple of us suggested that he try adding
the MIT TECO features to his program, and he said he'd give it a try. I don't
know what ever came of that.
Rich
Rich Alderson
Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Ave S
Seattle, WA 98134
Cell: (206) 465-2916
Desk: (206) 342-2239
http://www.LivingComputers.org/
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Lars Brinkhoff
Sent: Wednesday, December 07, 2016 10:37 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: EMACS folly
Rich Alderson wrote:
Well, sure, if you load the suckit.el library, but
that's optional. It's
faster if you load the compiled suckit.elc instead.
I prefer the compiled TECO variant BITEME.:EJ, of course!
Loaded into GNU Emacs? ;-)
Hey, do you have any VAXen over there? How about getting an early Emacs
running on those? I turned the Internet inside out to find Gosling
Emacs, BTL Emacs, and GNU Emacs 15 and 17, and and it would be a shame
if the source code was just sitting idle.
Or how about TECO EMACS? Only not on the PDP family you'd expect, but
the 16-bit flavor.
9 Dec
9 Dec
7:24 a.m.
New subject: EMACS folly
Rich Alderson wrote:
I'll let someone else do the VMS stuff. DECUSLIB has a copy of GNU
Emacs 15, possibly the very first public release.
Some day, if a free time slot appears, I'd like to try to get the early
Unix Emacsen running in their natural Berkeley habitat. I'd probably
run a VAX emulator for that.
I was hinting a the very real EMACS-11 by Fred Fish. Here's a
net.sources post from 1984, and a tarball from Pete Siemsen:
https://groups.google.com/forum/message/raw?msg=net.sources/qBRfbEjrGV8/3t3…
http://ftp.funet.fi/pub/unix/editors/teco/emacs11.tar.Z
Again, I'd love to see this running, but I'm starved for time right now.
(Aren't we all?)
Hey, do you
have any VAXen over there? How about getting an early
Emacs running on those?
We have a VAX-11/780-5 (a 780 field upgraded to a 785) running VMS Or how about
TECO EMACS? Only not on the PDP family you'd expect,
but the 16-bit flavor.
Pete Siemsen wrote a new PDP-11 TECO [...] a couple of us suggested
that he try adding the MIT TECO features to his program, and he said
he'd give it a try.
14 Dec
14 Dec
9:55 a.m.
New subject: EMACS folly
<snip>
<snip>
I finally got around to looking at this before archiving it, and found
that the shar file gets checksum errors when
I run it with bash. Not sure what the problem is, but the files seemed
to be clear (not total garbage). I also tried
sh, which I don't think is any different than bash anymore. The script
warns not to use csh.
Also in the second one Pete put in the phone numbers for both he and the
original author. Very thoughtful. :-)
I was kind of hoping for a full emac executable, but then again probably
wouldn't be room for that on an 11 of
a smaller size.
thanks
Jim
jws at jws2:~/cnas/projects/emacs/tmp$ bash raw
Extracting README:
Extracting bldemacs.tec:
bldemacs.tec: Checksum error. Is: 13790, should be: 58310.
Extracting emacs.doc:
Extracting emacs.src:
emacs.src: Checksum error. Is: 57446, should be: 43403.
Extracting emacs.txt:
Extracting emacs11.tec:
emacs11.tec: Checksum error. Is: 32418, should be: 48995.
Extracting vaxbld.tec:
vaxbld.tec: Checksum error. Is: 34617, should be: 47133.
ALL DONE BUNKY!
2932
days inactive
2948
days old
40 comments
19 participants
participants (19)
-
barythrin＠gmail.com -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
dab＠froghouse.org -
dave.g4ugm＠gmail.com -
db＠db.net -
dkelvey＠hotmail.com -
isking＠uw.edu -
james.w.stephens＠gmail.com -
jonas＠otter.se -
jwsmail＠jwsss.com -
lars＠nocrew.org -
lproven＠gmail.com -
mouse＠Rodents-Montreal.ORG -
phil＠ultimate.com -
RichA＠livingcomputers.org -
spacewar＠gmail.com -
spectre＠floodgap.com -
toby＠telegraphics.com.au