XPost: alt.sys.pdp8

In article <[email protected]>,
Bob Eager <[email protected]> wrote:

On Mon, 04 Apr 2016 13:01:50 +0200, Morten Reistad wrote:

In article <[email protected]>, Christian
Corti <[email protected]> wrote:

Dylan McNamee <[email protected]> wrote:

That is a great thread - thanks for the pointer! It seems that this is >>>> mostly an artifact of papertape and 6-bit ASCII, both

of which (mostly) went away after the PDP-8.

No and no.
First, ASCII is seven bits (octal 0-177). Second, it has nothing to do >>>with papertape or Teletypes. DEC simply defined the parity bit to be
mark (i.e. always 1), since the serial interface is 8 bits fixed.

They were not alone in doing this. Prime computer also had the MSB set
in all of their ASCII. Saving a few cents worth of hardware in the
serial ports and/or some cycles processing them. But leading to decades
of incompatibility.

ISTR having the same thing on a Honeywell DDP-516.

ISTR that the earliest Primes (up to the 400, ISTR) were embrace-and-extend versions of the DDP-5xx architecture. Later versions had compatibility-mode (R-mode?) that ran DDP-516 code.

Crossposted to comp.sys.prime, and followup-to set there.

-- mrr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 04 Apr 2016 16:15:38 +0200, Morten Reistad wrote:

In article <[email protected]>,
Bob Eager <[email protected]> wrote:

On Mon, 04 Apr 2016 13:01:50 +0200, Morten Reistad wrote:

In article <[email protected]>,
Christian Corti <[email protected]> wrote:

Dylan McNamee <[email protected]> wrote:

That is a great thread - thanks for the pointer! It seems that this
is mostly an artifact of papertape and 6-bit ASCII, both

of which (mostly) went away after the PDP-8.

No and no.
First, ASCII is seven bits (octal 0-177). Second, it has nothing to do >>>>with papertape or Teletypes. DEC simply defined the parity bit to be >>>>mark (i.e. always 1), since the serial interface is 8 bits fixed.

They were not alone in doing this. Prime computer also had the MSB set
in all of their ASCII. Saving a few cents worth of hardware in the
serial ports and/or some cycles processing them. But leading to
decades of incompatibility.

ISTR having the same thing on a Honeywell DDP-516.

ISTR that the earliest Primes (up to the 400, ISTR) were
embrace-and-extend versions of the DDP-5xx architecture. Later versions
had compatibility-mode (R-mode?) that ran DDP-516 code.

Crossposted to comp.sys.prime, and followup-to set there.

I didn't know that. My final year undergraduate project was modifying the
CPU on a DDP-516, to add/modify some instructions...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ISTR that the earliest Primes (up to the 400, ISTR) were embrace-and-extend versions of the DDP-5xx architecture. Later versions had compatibility-mode (R-mode?) that ran DDP-516 code.

Prime called the x16 mode S mode. As far as I know, it existed
until the end. Even the 100 and 200 had R-mode, though, the "embrace
and extend".

The P300 added virtual memory.

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Dennis Boone <[email protected]> wrote:

ISTR that the earliest Primes (up to the 400, ISTR) were embrace-and-extend versions of the DDP-5xx architecture. Later versions had compatibility-mode (R-mode?) that ran DDP-516 code.

Prime called the x16 mode S mode. As far as I know, it existed
until the end. Even the 100 and 200 had R-mode, though, the "embrace
and extend".

The P300 added virtual memory.

They sure had a lot of processor modes, S, R, I, V and IX. This puts even
a '486 and an ARM8 (with 64, 32 and 24 bit modes plus thumb2) to shame.

-- mrr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, April 4, 2016 at 10:18:33 PM UTC-4, Morten Reistad wrote:

In article <[email protected]>,
Dennis Boone <[email protected]> wrote:

ISTR that the earliest Primes (up to the 400, ISTR) were embrace-and-extend
versions of the DDP-5xx architecture. Later versions had compatibility-mode
(R-mode?) that ran DDP-516 code.

Prime called the x16 mode S mode. As far as I know, it existed
until the end. Even the 100 and 200 had R-mode, though, the "embrace
and extend".

The P300 added virtual memory.

They sure had a lot of processor modes, S, R, I, V and IX. This puts even
a '486 and an ARM8 (with 64, 32 and 24 bit modes plus thumb2) to shame.

-- mrr

And within each processor mode are multiple addressing schemes indicated in a different way in each mode:

- sector 0 relative
- program counter relative
- preindexed by index register
- postindexed by index register
- optional indirect
- base register relative (4 varieties)
- field address register relative
- general register relative
- gr indexed

Fun!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Jim Wilcoxson <[email protected]> wrote:

On Monday, April 4, 2016 at 10:18:33 PM UTC-4, Morten Reistad wrote:

In article <[email protected]>,
Dennis Boone <[email protected]> wrote:

ISTR that the earliest Primes (up to the 400, ISTR) were embrace-and-extend
versions of the DDP-5xx architecture. Later versions had compatibility-mode
(R-mode?) that ran DDP-516 code.

Prime called the x16 mode S mode. As far as I know, it existed
until the end. Even the 100 and 200 had R-mode, though, the "embrace
and extend".

The P300 added virtual memory.

They sure had a lot of processor modes, S, R, I, V and IX. This puts even
a '486 and an ARM8 (with 64, 32 and 24 bit modes plus thumb2) to shame.

-- mrr

And within each processor mode are multiple addressing schemes indicated in a different way in each mode:

- sector 0 relative
- program counter relative
- preindexed by index register
- postindexed by index register
- optional indirect
- base register relative (4 varieties)
- field address register relative
- general register relative
- gr indexed

I discovered this in october 1984 when I read the processor and PMA
manuals for Primos 19.3; while upgrading to 19.4.

That was when I decided that I'll stick to procedural languages, after
doing assembly programming for nearly a decade. First the 6502, then the
PDP10, then the Z80, a little PDP11s, and then the Prime. After a few
weeks with PMA I went for FTN, PLP, SPL and all the other Prime-specific
stuff.

-- mrr

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, 6 April 2016 00:04:45 UTC+10, Morten Reistad wrote:

In article <[email protected]>,
Jim Wilcoxson <[email protected]> wrote:

On Monday, April 4, 2016 at 10:18:33 PM UTC-4, Morten Reistad wrote:

In article <[email protected]>,
Dennis Boone <[email protected]> wrote:

ISTR that the earliest Primes (up to the 400, ISTR) were embrace-and-extend
versions of the DDP-5xx architecture. Later versions had compatibility-mode
(R-mode?) that ran DDP-516 code.

Prime called the x16 mode S mode. As far as I know, it existed
until the end. Even the 100 and 200 had R-mode, though, the "embrace
and extend".

The P300 added virtual memory.

They sure had a lot of processor modes, S, R, I, V and IX. This puts even >> a '486 and an ARM8 (with 64, 32 and 24 bit modes plus thumb2) to shame.

-- mrr

And within each processor mode are multiple addressing schemes indicated in a different way in each mode:

- sector 0 relative
- program counter relative
- preindexed by index register
- postindexed by index register
- optional indirect
- base register relative (4 varieties)
- field address register relative
- general register relative
- gr indexed

I discovered this in october 1984 when I read the processor and PMA
manuals for Primos 19.3; while upgrading to 19.4.

That was when I decided that I'll stick to procedural languages, after
doing assembly programming for nearly a decade. First the 6502, then the PDP10, then the Z80, a little PDP11s, and then the Prime. After a few
weeks with PMA I went for FTN, PLP, SPL and all the other Prime-specific stuff.

-- mrr

Same with me and a few others I think.

I had some IBM S/370 Assembler experience and loved it.
Got a copy of PMA manual and stopped.
Then found FTN was there (I was on a customer site and no PLP/SPL).
The rest is history.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, November 4, 2018 at 9:26:30 PM UTC-5, Greg Field wrote:

On Wednesday, 6 April 2016 00:04:45 UTC+10, Morten Reistad wrote:

In article <[email protected]>,
Jim Wilcoxson <[email protected]> wrote:

On Monday, April 4, 2016 at 10:18:33 PM UTC-4, Morten Reistad wrote:

In article <[email protected]>,
Dennis Boone <[email protected]> wrote:

ISTR that the earliest Primes (up to the 400, ISTR) were embrace-and-extend
versions of the DDP-5xx architecture. Later versions had compatibility-mode
(R-mode?) that ran DDP-516 code.

Prime called the x16 mode S mode. As far as I know, it existed
until the end. Even the 100 and 200 had R-mode, though, the "embrace >> >and extend".

The P300 added virtual memory.

They sure had a lot of processor modes, S, R, I, V and IX. This puts even
a '486 and an ARM8 (with 64, 32 and 24 bit modes plus thumb2) to shame. >>
-- mrr

And within each processor mode are multiple addressing schemes indicated in a different way in each mode:

- sector 0 relative
- program counter relative
- preindexed by index register
- postindexed by index register
- optional indirect
- base register relative (4 varieties)
- field address register relative
- general register relative
- gr indexed

I discovered this in october 1984 when I read the processor and PMA
manuals for Primos 19.3; while upgrading to 19.4.

That was when I decided that I'll stick to procedural languages, after doing assembly programming for nearly a decade. First the 6502, then the PDP10, then the Z80, a little PDP11s, and then the Prime. After a few
weeks with PMA I went for FTN, PLP, SPL and all the other Prime-specific stuff.

-- mrr

Same with me and a few others I think.

I had some IBM S/370 Assembler experience and loved it.
Got a copy of PMA manual and stopped.
Then found FTN was there (I was on a customer site and no PLP/SPL).
The rest is history.

One thing about Prime: their compilers were (I thought) extremely good. It was hard to write PMA that ran faster than FTN, PLP, or SPL, so I think most people avoided the pain of PMA since there was little to gain. It was used inside Primos of course,
for things like clock interrupt handlers that ran 300 times/second, I/O drivers, etc.

The only really good use for it at the application level I think was for small utility library functions that could utilize the shortcall mechanism. For example, I wrote a version of APPLIB in PMA. It was much faster than the standard APPLIB, not so
much because the code was faster, but because it avoided the long-winded PCL (Procedure Call) instruction - the normal way to call a subroutine on the Prime, and used JSXB instead - the traditional "jump and store the return address in a register".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)