Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Chuck Guzis]

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

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Eric Smith]

On Sat, Dec 17, 2016 at 2:59 PM, Chuck Guzis  wrote:

> What perplexed me is that the address of  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.

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Chuck Guzis]

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

RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Rich Alderson]

From: Lars Brinkhoff
Sent: Wednesday, December 14, 2016 3:54 AM

> Noel Chiappa wrote:

>>> 9-track tapes on the PDP-10 used one of the following encodings:

>> What about 7-track, any idea? I would assume 6 x 6-bit tape frames per
>> 36-bit word, but that's just a guess.

> A reasonable guess, and one I'd make too.  But I don't know either.

According to the monitor calls manuals for both Tops-10 and TOPS-20, as
well as the manual specifically on tape labels etc., that's a very good
guess, and a correct one.

> Supposedly, many ITS backups were made to 7-track tapes.  That became a
> problem when the old tape drives started to fail, and available new tape
> drives were only 9-track.

The same issue occurred at SAIL for the early WAITS backups prior to the
introduction of a KL-10 into the system (which grew from a PDP-6 to a
PDP-10/PDP-6 to a KL-10/KA-10/166, then shrank to a KL-10/KA-10 down to
a KL-10 only).  The KL-10 had TU-78 drives on an RH20.

AIUI, the older backup tapes were refrangled onto new 9-track media before
the KA-10 and its drives were retired.

Rich


Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Lars Brinkhoff]

Noel Chiappa wrote:
> > 9-track tapes on the PDP-10 used one of the following encodings:
>
> What about 7-track, any idea? I would assume 6 x 6-bit tape frames per
> 36-bit word, but that's just a guess.

A reasonable guess, and one I'd make too.  But I don't know either.

Supposedly, many ITS backups were made to 7-track tapes.  That became a
problem when the old tape drives started to fail, and available new tape
drives were only 9-track.

RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Rich Alderson]

From: Eric Smith
Sent: Saturday, December 10, 2016 6:38 PM

> On Fri, Dec 9, 2016 at 12:47 PM, Rich Alderson 
> 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:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Eric Smith]

On Fri, Dec 9, 2016 at 12:47 PM, Rich Alderson 
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.

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Phil Budne]

> 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:
;251ADD 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:
;3369 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.

RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Rich Alderson]

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

_HHH
_EEE
_LLL
_LLL
_OOO
_www
_ooo
_rrr
_lll
_ddd

In memory, this takes 3 words:

_HHH_EEE_LLL_LLL
_OOO_www_ooo_rrr
_lll_ddd

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:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Jon Elson]

On 12/08/2016 07:08 PM, dwight wrote:

Not meaning to throw things to far off but on my

NC4000 machine( 16 bit ), I found ByteSwap useful enough that I had it

hard wired.

I have an old computer that was intended to do FFTs. It has a

complete bit order swap, MSB to LSB, instruction.


Yup, this is to implement the "butterfly" mirroring of the addresses for 
the FFT.


Jon

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Chuck Guzis]

On 12/09/2016 07:02 AM, Paul Koning wrote:

> Rather than "can't make up their mind", a good reason to have
> selectable endian processors is that the best choice may depend on
> the application.  So for embedded systems in particular, it's good to
> be able to pick which you want.

My quip was an attempt at levity.

One interesting aspect of the later ARM (e.g. Cortex M3) are the
"reverse" instructions:

REV reverses the byte order in a 32-bit words.  Thus, ABCD becomes DCBA.

REV16 reverses the byte order in each halfword of a 32 bit word, ABCD
becomes BADC.

REVSH reverses the byte order in the low-order halfword and sign extends
to 32 bits.  Thus ABCD becomes SSDC (with S symbolizing the extended
sign bit)

RBIT reverses the bit order in a 32 bit word.

So lots of choices for those who feel that variety is the spice of life.

--Chuck

RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Phil Budne]

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

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[dwight]

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-boun...@classiccmp.org> on behalf of jim stephens 
<james.w.steph...@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 <ccl...@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

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Paul Koning]

> On Dec 9, 2016, at 1:25 AM, Chuck Guzis  wrote:
> 
> On 12/08/2016 08:46 PM, Cameron Kaiser wrote:
 I have an old computer that was intended to do FFTs. It has a 
 complete bit order swap, MSB to LSB, instruction.
>>> 
>>> Well, there's the PowerPC "endian" mode (settable in the MSR)--but
>>> it's just "sort of"--the little-endian mode simply XORs the lower 3
>>> bits of the address with 111 (i.e. "flips them").
>> 
>> Or you could use the PowerPC byte-swapped instructions (lwbrx, etc.)
> 
> Forgot to mention the ARM CPUs/MCUs.  Supports both, for people who
> can't make up their mind.

Rather than "can't make up their mind", a good reason to have selectable endian 
processors is that the best choice may depend on the application.  So for 
embedded systems in particular, it's good to be able to pick which you want.

paul

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Lars Brinkhoff]

Rich Alderson  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:
> HHHEEELLOOO_wwwooorrrlllddd_
>
> Core Dump:  High Density:   SIXBIT: (7 track)
> HHHEHHHEHH
> EELLEELLHE
> EE
> LL
> OOO_OOO_OO
> wwwowwwoO_
> oorroorrww
> rlllrlllwo
> ddd_oo
> ddd_rrrlll
> dd
> d_

Let's add ANSI-ASCII:

.HHH
.EEE
.LLL
.LLL
_OOO
.www
.ooo
.rrr
.lll
_ddd

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.

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[jim stephens]

On Thu, Dec 8, 2016 at 9:51 AM, Chuck Guzis  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

RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Rich Alderson]

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

Core Dump:  High Density:   SIXBIT: (7 track)
HHHEHHHEHH
EELLEELLHE
EE
LL
OOO_OOO_OO
wwwowwwoO_
oorroorrww
rlllrlllwo
ddd_oo
ddd_rrrlll
dd
d_

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:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Cameron Kaiser]

> > I have an old computer that was intended to do FFTs. It has a
> > complete bit order swap, MSB to LSB, instruction.
> 
> Well, there's the PowerPC "endian" mode (settable in the MSR)--but it's
> just "sort of"--the little-endian mode simply XORs the lower 3 bits of
> the address with 111 (i.e. "flips them").

Or you could use the PowerPC byte-swapped instructions (lwbrx, etc.)

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Maybe this world is another planet's hell. -- Aldous Huxley 

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Chuck Guzis]

On 12/08/2016 05:08 PM, dwight wrote:
> Not meaning to throw things to far off but on my
> 
> NC4000 machine( 16 bit ), I found ByteSwap useful enough that I had it
> 
> hard wired.
> 
> I have an old computer that was intended to do FFTs. It has a
> 
> complete bit order swap, MSB to LSB, instruction.

Well, there's the PowerPC "endian" mode (settable in the MSR)--but it's
just "sort of"--the little-endian mode simply XORs the lower 3 bits of
the address with 111 (i.e. "flips them").

--Chuck

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[dwight]

Not meaning to throw things to far off but on my

NC4000 machine( 16 bit ), I found ByteSwap useful enough that I had it

hard wired.

I have an old computer that was intended to do FFTs. It has a

complete bit order swap, MSB to LSB, instruction.

All interesting.

Dwight



From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Noel Chiappa 
<j...@mercury.lcs.mit.edu>
Sent: Thursday, December 8, 2016 1:30:48 PM
To: cctalk@classiccmp.org
Cc: j...@mercury.lcs.mit.edu
Subject: Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

> From: Rich Alderson

> 9-track tapes on the PDP-10 used one of the following encodings:

What about 7-track, any idea? I would assume 6 x 6-bit tape frames per 36-bit
word, but that's just a guess.

Noel

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Noel Chiappa]

> From: Rich Alderson

> 9-track tapes on the PDP-10 used one of the following encodings:

What about 7-track, any idea? I would assume 6 x 6-bit tape frames per 36-bit
word, but that's just a guess.

Noel

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Chuck Guzis]

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

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[jim stephens]

On 12/7/2016 10:42 PM, Chuck Guzis wrote:

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

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Chuck Guzis]

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

RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Rich Alderson]

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:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

RE: RE: Base 64 posts to the list

[Rich Alderson]

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:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Lars Brinkhoff]

Charles Anthony wrote:
> 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.

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

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Mouse]

>>> Middle-endian FTW
>> That makes me wonder: was there any hardware that used an endianness
>> such that conversion didn't loop with period 2?
> 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?

Yes.  As I said in the very next paragraph,

> Conversion between PDP11-endian (0x87654321 stored as 0x65 0x87 0x21
> 0x43) and [...]

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Mouse]

>> Or how about architectures not using a word length that's an
>> integral number of bytes?
> 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.  (The era of 36-bit machines was before "byte" had
drifted to its current synonymity with "octet".)

Byte sex is really an issue of conversion between numbers and their
serializations.  For example, it does not make sense to speak of the
number 2271560481 (0x87654321) having an endianness in its own right;
endianness becomes a meaningful concept only when a number is made up
of smaller units with some kind of ordering among themselves.  Most
commonly these are memory-addressing units, with the order being
increasing address order, but the terminology can also be used when,
for exmaple, discussing serializing bits onto a bit-serial transmission
medium, with the order being transmission order (eg, when sending
characters over a serial line).

To address the comment, I don't know enough about any of the 36-bit
machines to know whether they had sub-36-bit-word addressing or any
such, which would be necessary for concepts such as endianness to make
sense.  I think at least one early (by modern standards) machine
supported addressing memory as if it were an array of bits, extracting
an arbitrary block of those bits not longer than a machine word; if
true, that addressing order would induce an endianness

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Charles Anthony]

On Mon, Dec 5, 2016 at 11:14 AM, Dave Wade <dave.g4...@gmail.com> wrote:

> > -Original Message-
> > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of David
> > Bridgham
> > Sent: 05 December 2016 18:37
> > To: General Discussion: On-Topic and Off-Topic Posts
> > <cctalk@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:
> >
> > > Or how about architectures not using a word length that's an integral
> > > number of bytes?
> >
> > You mean like any 36-bit machine?
>
> 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
4 padding bits scattered through the word).

>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

RE: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Dave Wade]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of David
> Bridgham
> Sent: 05 December 2016 18:37
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk@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:
> 
> > Or how about architectures not using a word length that's an integral
> > number of bytes?
> 
> You mean like any 36-bit machine?

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

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[David Bridgham]

On 12/05/2016 11:51 AM, Mouse wrote:
>> Middle-endian FTW
> That makes me wonder: was there any hardware that used an endianness
> such that conversion didn't loop with period 2?

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?

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[David Bridgham]

On 12/05/2016 12:17 PM, Chuck Guzis wrote:

> Or how about architectures not using a word length that's an integral
> number of bytes?

You mean like any 36-bit machine?

Re: Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Chuck Guzis]

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

Odd "endianness" [was Re: RE: Base 64 posts to the list]

[Mouse]

>> Little-endian!!!
> Middle-endian FTW

That makes me wonder: was there any hardware that used an endianness
such that conversion didn't loop with period 2?

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?

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: RE: Base 64 posts to the list

[Liam Proven]

On 5 December 2016 at 15:35, Cameron Kaiser  wrote:
> emacs sucks!

I agree. So does Vi.

> *waits patiently*

There, does that help? :-)

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Talk/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053

Re: RE: Base 64 posts to the list

[Diane Bruce]

On Mon, Dec 05, 2016 at 07:36:19AM -0800, Charles Anthony wrote:
> On Mon, Dec 5, 2016 at 6:35 AM, Cameron Kaiser  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?
> >
> > emacs sucks!
> >
> > *waits patiently*
> >
> > --
> >
> 
> Little-endian!!!

Middle-endian FTW


> ]
> -- Charles
> 

-- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: RE: Base 64 posts to the list

[Charles Anthony]

On Mon, Dec 5, 2016 at 6:35 AM, Cameron Kaiser  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?
>
> emacs sucks!
>
> *waits patiently*
>
> --
>

Little-endian!!!
]
-- Charles

Re: RE: Base 64 posts to the list

[Cameron Kaiser]

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

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Marry me and I'll never look at another horse! -- Groucho Marx -

Re: RE: Base 64 posts to the list

[Ian S. King]

On Sun, Dec 4, 2016 at 12:10 PM, Jonas Otter  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 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: RE: Base 64 posts to the list

[Jonas Otter]

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.