Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DEC/PDP-8 Stuff That Never Quite Happened, Part 2
297 views
Skip to first unread message
Bob Vines
May 20, 2012, 8:42:28 PM5/20/12
to
This is Part 2 of the article from CJL.
Bob
---------------------------------------------------------------
[Continued from Part 1]
5) The 1 MB DECmate II XPU board.
The obscure DECmate II XPU option board is a superset of the nearly as
obscure APU board, which consists of 64 KB of memory and a Z80 CPU
chip. All members of this family are interfaced to the 6120 chip at
the heart of all DECmates which performs all of the I/O functions the
Z80 requires.
However, the XPU board also sports an 8086 chip which can run MS-DOS
faster than the original 8088 IBM PC or PC-XT. While not totally PC-
compatible, a release of MS-DOS 2.1 was created for this configuration
which is capable of running a fair number of programs. A goodly
amount of them overlap with the Rainbow such as the precise
implementation of SEDT, which takes advantage of many of the features
found on the DECmate II with XPU and also on the Rainbow such as 132
column mode and the ability to support reverse video screen font.
Sold models can be had with either 256K or 512K. However, the 512K
board is only 1/2 populated. One wonders what technical snags came
about that prevented populating the board further. Due to the way
memory was allocated,it is likely the chips used couldn't be used for
a 768K implementation which is unfortunate. Additionally, a memory
controller needs to turn off memory when the memory address is
allocated for other than storage; apparently the XPU board designers
failed to take these points into account, thus every 512K XPU board
must have half the memory chips left off the board. No MS-DOS
configuration can have the entire [first] 1 MB address space totally
devoted to memory. However, the size of reserved memory would be
especially small since none of it was devoted to memory-mapped
peripherals.
The 64K memory space used as RAM by the Z80 maps 64K of the 1.0 MB
space. MS-DOS operations are implemented as in-memory transactions
carried out [as a middleman] by the Z80, which in turn has the
specifics carried out by the 6120 that has command of all available
peripherals.
Had a proper memory scheme been implemented, the maximum memory
available to MS-DOS would have been 960 KB. With a different memory
chip configuration, 768 KB would have been perfectly reasonable. This
has been done in other 808x-based systems. Perhaps they were confused
with the IBM-PC's upper memory limit of 640 KB which is not actually a
design limit of MS-DOS. [The real limitation is the need to allocate
part of the memory space to various graphics devices, reserved areas
for peripherals, and 64K for a BIOS ROM. None of these applies to the
DECmate II, just the inter-CPU memory map to the Z80 CPU chip.
6) The XPU board for the DECmate III series.
The smaller footprint DECmate III series was marketed with an optional
APU board of its own. The one for the DECmate II is compatible with
the one for the DECmate III with one nitpick exception: CP/M-80 is
created for both machines using a starter diskette that can boot up on
either family of machines [DECmate II versus DECmate III or III+ .]
There are apparently ways to tell the difference between an APU-only
machine and an XPU machine [or at least this diskette creates a
working copy system diskette that bothers to find out].
Thus, if CP/M-80 is created for an APU option board-based machine, the
resulting working copy can run on any APU-based model. However, if
the target is a machine with an XPU board, CP/M-80 will not boot
there. This situation is vice versa for CP/M-80 created for XPU-based
systems. [This is an irrational consideration. CP/M-80 doesn't use
the 8086 chip if it even is there, so why bother to create a needless
compatibility!] [WPS has features that will be available if any of
these modules is present without any otherwise distinction.]
The same aberration applies even if the target is for the DECmate II
or DECmate III+ bootable hard disk CP/M-80 volume. Master Menu is a
collection of utility programs that allows any and all operating
systems to run on any DECmate II or III+ system with a hard-disk [sold
as an option on the DECmate II but integral to the DECmate III+ .]
Master Menu can backup any hard disk volume to a series of diskettes.
The backup can be restored to a different machine. All transfers will
work perfectly except that CP/M-80 bootable volumes will not work if
the APU versus XPU considerations is violated in the analogous manner
to the diskette configurations.
As delivered, the only way to create a DM III+ bootable hard disk
volume is to first create it on a DECmate II with specifically the APU
option. Then master menu can be used to backup and restore the volume
on the hard disk within the DECmate III+ . The reason for this is
that the very same CP/M-80 generator diskette can only create hard
disk volumes using a diskette drive 0, which is not available on a
stock DECmate III+ . However, Master Menu can restore a volume using
diskette 0 that was specifically created on a DECmate II with hard
disk and specifically the APU option board. [Note: The DECmate III+
controller supports two drives, just not in the small chassis as
delivered. By bringing out the drive and power cables, it is possible
to jury-rig a pair of drives which will look to all software as a
complete dual RX50 drive. Thus, if the hardware is configured in this
impromptu fashion, CP/M-80 can be installed as intended.]
Apparently there was an intent to implement a DECmate III series XPU
board to round out the collection. However, it was relatively late in
the marketing life of the DECmates and was never implemented. [Thank
You VAXmate fools who never produced a viable product with a hard disk
at all, yet backstabbed your way into getting the DECmates cancelled
yet you never even had a product. The glorious PDP-8 history at
Digital was ended because of a non-viable attempt at a product that
should not have even been started. Since this is so heinous, it won't
even be otherwise given a place in this document. They simply didn't
do their homework, took literally years to not actually produce the
product, and then when it was attempted, it had to be withdrawn simply
because the plastic chassis didn't provide adequate cooling! Simply
no excuse considering all of the prior generation machines from the
DEC Professional to the Rainbow to the DECmate II and III+ had proper
cooling for the exact same 20 MB Seagate MF disk DEC used in all of
these designs! And this of course over and above the fact that it was
obsolete in the PC world even before it was started.]
7) The "fast" LA36.
This is somewhat of a success story, just not for DEC. The LA36 ran
at a maximum speed of 300 baud/30 CPS to accomplish only one design
goal: To obviate the need for special handling of the wide carriage
LA36 printing terminal design. In earlier designs, it was necessary
to perform special handling for functions such as vertical tab or form-
feed or in some cases just a carriage return when positioned at the
extreme right of the page. No reverse channel support is provided or
needed; it just works.
The reason is that the actual raw printing speed of the LA36 is far
faster than 30 CPS for most printing. If some relatively time-
consuming functions were being performed, the terminal was buffered
sufficiently that virtually any print situation could be handled by
eventually catching up at the raw speed of the printing unit. Thus,
performance was far better than older devices such as the model 35
teletype which required special handling for such as form-feed that
just works perfectly fine on the LA36.
As good as all of this sounds, there is a major flaw in the
reasoning: If the engine of the terminal is so much faster, why is it
printing at only 30 CPS? Why indeed!
On the LA36 control board there is a curious "test socket" which
apparently has control signals that seem to serve no purpose as far as
the stock LA36 is concerned. However, the chief designer created this
socket with an agenda:
a) He left the company after they refused to implement anything any
better; he felt his work was somewhat wasted as a result.
b) He formed his own company to market a replacement board for the
second control board mounted on the rear panel of the LA36. His
replacement board includes an embedded microprocessor and the
resultant board is far smaller than the DEC original that does far
less but takes more space and power. This smaller board is attached
to the rear panel using only a few of the mounting spacers available;
certainly sufficient for proper fastening considerations.
c) As part of the replacement, a provided cable is run between a
similar socket on the replacement board and the "test socket" on the
primary control board within the LA36 chassis. Since the unit will be
driven much harder, a heatsink is attached to the LA36 head in
anticipation of far more heat being produced when the unit prints much
faster, etc.
d) The resultant device is now designated as the DEC-sounding LS120.
While much later DEC released an even better device [not so in some
ways, just in others] called the LA180, it was only a bit faster than
the result achieved here. And it was scandalously more expensive.
e) As with the even newer DEC offering, these terminals needed to be
driven at much faster baud rates. 1200 baud was fully supported, but
hardly taking advantage of the printing speed. It was recommended to
use 2400, 4800 or even 9600 baud to maintain a partially full buffer
at all times until done printing. All DEC terminals from this point
forward used the familiar DC1/DC3 Control-S/Control-Q start-stop
protocol found in all DEC video terminals past the VT05.
Since the buffer was always ahead of the printing capabilities, the
printer always runs at maximum speed until it eventually catches up
[or the printing ceases entirely].
Additionally, the carriage is never wastefully returned as long as
there is something further to do. As necessary, printing occurs while
the head is traveling in reverse. Thus, while a section of print
might be sent as a string of characters followed by CR/LF followed by
similar text, this doesn't describe the actual printing: The first
line might be printed left to right, then the LF is performed followed
by the second line printed in reverse order until the carriage is now
back to the left margin, then the second LF is performed. Both CR
operations are virtually removed.
Since the raw speed of the printing device is about twice what the
LA36 could do, the effective speed is just about 4 times as fast as
the LA36 [not counting the overhead of LF characters]. The operating
system has to support the reverse protocol to be totally successful.
The author modified the OS/8 KL8E handler recast as a device 65/66 [or
40/41] serial printer where the only functionality of the keyboard is
to potentially pause the output by inserting Control-S into the
reverse channel [but not by the on-board microprocessor which would
eventually send Control-Q when the buffer was less than 1/4 full].
The terminal could also be used in P?S/8 as the device 03/04 console
because, unlike OS/8, P?S/8 fully supports the reverse protocol on the
console. [The P?S/8 Logical Console Overlay can be configured to
recognize the reverse protocol on the system line-printer as a
standard option; the default support is for the device 66 printer
which as a parallel device does not use the reverse protocol at all.]
The original LA36 has an exepnsive option to support the APL character
set. This can be used with such as APL-10 which exactly matches the
original IBM/360 implementation that requires IBM 2741 terminals with
APL typeballs applied. And of course the LA36 is a fully implemented
ASCII text terminal as well.
The LS-120 speed-up board comes standard with the APL character set
feature; a dip-switch can be set to defeat it if desired.
Again, a product DEC never marketed, but another company benefited
from doing their thinking for them and profiting by it.
8) The "PDP-16".
No discussion of DEC quirks and follies such as this can be complete
without mentioning the next-generation DEC design for a 16-bit
machine. [It is not clear if it would actually be called the PDP-16
because it was never actually made - by DEC.]
Edson De Castro, chief engineer on the straight PDP-8 project [and
many other successful DEC products] had designed, proposed and had
gotten approval for a 16-bit machine that was arguably a cross between
the PDP-8 and the PDP-15 with a few extra features added, but with a
16-bit word orientation instead of either 12 or 18 bits. It retains
the PDP-8 notion of indirectly referencing memory through locations
0010-0017 causing auto-indexing instead of merely indirect addressing.
[Indirect addressing means using a pointing word without modifying the
pointer. Auto-indexing is the term to describe what happens in the
PDP-8 where the pointer is first updated then used to point to the
operand. This leads to the notion of calling 10-17 octal "registers"
even though they are merely memory locations with a special property.
But this is reminiscent of actual registers as defined in other
machines such as the PDP-15 and of course the -11.]
Many [including the author] have discussed over the years why exactly
what happened in fact did happen. Suffice to say, all of the
following are true:
a) De Castro assembled a design team of about 200 people to implement
the hardware of the new product. [Note: At the time, DEC was just
starting to realize the importance of SOFTWARE to computer design;
perhaps that was not in the proper forefront as it would be at DEC in
all subsequent years.] [No one would argue that Edson De Castro was a
hardware guy.]
b) Some form of celebration of the coming event the next week was
being openly done for all parties invited on a Friday afternoon.
c) By Monday, the entire project was cancelled.
d) The PDP-11 was ingratiated instead despite serious design flaws.
Papers have been written about this. Clearly the design was not fully
vetted. Quirks existed in the design such as performing an ADD
instruction with the operand of exactly 1 does NOT create exactly the
same results as the INCREMENT instruction. [And similarly, the
SUBTRACT instruction with the same operand does not create the same
exact results as the DECREMENT instruction. So much for the "wonders"
of "symmetry".] The instruction set is so inefficient at performing
loops [all methods of counting off loop iterations are equally clumsy]
that an asymmetrical instruction was added that is analogous to the
PDP-8 ISZ operation to more efficiently count off loops. However,
earlier models do not support it, thus hampering software design which
still cannot use the improvement if the earlier models are to be
supported. [I thought this kind of nonsense was only to happen with
the PDP-8/s, but I was mistaken.]
e) Within a short measure of time, Data General Corporation was
formed primarily from the now FORMER DEC personnel of the 200 people
involved. Edson De Castro was the president of the company.
f) Data General was quite successful at making the original design,
now dubbed the Nova. Eventually a 32-bit extension was designed and
the resultant machine was dubbed the Eclipse. The book 'The Soul of a
New Machine' by Tracy Kidder became a best seller in the 1980's that
discusses this later aspect [with only a few sketchy details of what
happened in the time frame from step a) through step d). It is
telling that the Eclipse engineers got a look inside the early VAX
models at a trade show and smiled because they knew that their machine
was technologically superior; DEC was using older logic in the design.
DG's machine was the original home of the WordPerfect program, which
is why PC versions do not exist prior to Version 4.2.
g) DEC lost money to DG on various projects of significant worth such
as an open bid to create a network of small status sensing machines
throughout Disney theme parks such as Disney World Florida. The
project could have easily been implemented by some form of PDP-8, but
DEC presented a needlessly complicated PDP-11-based system. DG easily
won the contract with a much more sensible Nova-based system. [Note:
Richard Lary of DEC participated in the design of the LSI-11 based on
a small collection of chips from Western Digital known as the WD-16.
He also designed what should have been called the LSI-8 but DEC
refused to market it because it would undercut the market for the
LSI-11. Such a machine would have been perfectly adequate for Disney'
needs, and would have easily won over the DG offering which was
actually technologically backward by comparison. But by using the
PDP-11 at the center of their design, it became far too expensive. It
is noteworthy that eventually Disney abandoned this project in favor
of a more appropriate Intel 8080-based still cheaper product.
However, DEC might have gotten that newer contract had they been on
better terms with Intersil, developer of the IM6100 PDP-8-on-a-chip.
Instead they never bid and Intel won out.
Somewhat later, embarrassed by this and other "bad-blood" issues, one
of which involves your author personally, DEC refused to even talk to
Intersil and instead went to second-source provider Harris
Semiconductor. This was the basis for the extremely slow VT78, which
is even slower than the 6100 chip ought to run at. It is not known
exactly why DEC couldn't run their design at full speed [instead only
a bit over 3/4 normal clock speed], but clearly a second-source
manufacturer knows very little about the product design compared to
the design company. Had DEC swallowed its pride, it could have dealt
with Intersil directly and perhaps learned how to make the 6100 chip
run at full speed. Third-party machines at the time available from
Intersil [the "Intercept"] and machine packager Pacific CyberMetrix
[the "PCM12" and "PCM12A" at least one of which was available in kit
form with the above mentioned DSD-210 as a storage option] ran the
chip at the full 4.0 MHz standard CPU speed. The VT78 is so slow that
it has the dubious distinction as being the only machine where OS/8 on
RX01 runs with throughput 13 times as slow as all other DEC 12-bit
models. By fully taking advantage of the superior memory model, P?S/8
prevents the throughput loss on the same configuration. But OS/8
cannot remedy this situation.
Worse still, DEC awarded the contract for the next-generation 6120
chip to Harris without any participation from Intersil. Through a
pure bungling of handling the technical negotiation, design quirks
were allowed to creep in that eventually made the DECmates
incompatible with much PDP-8 software, including OS/8. Kludged and
buggy variants such as OS/278 V2 exist as testimony to these major
mistakes. [However, despite all of this, P?S/8 has conquered even
this needless incompatibility using techniques foreign to OS/8, but it
was a thankless job necessitated only because of this needless and
incompetent decision. Members of the PDP-8 programming group were
aware of the problem, yet it all fell on deaf ears.]
While DEC eventually went under for a variety of reasons [especially
too much management and driving away technical talent while being
manipulated by sales types], it is interesting to see the flawed
reasoning that made some of these quirky products never see the light
of day in users' systems. In part, this little slice of history
points the way to the ultimate end of the company.
Regardless of this, enthusiasts for the machines of the "good old
days" are perhaps at an all-time high. It is largely on account of
this, the author continues his labor of love producing independent
software and of course documenting everything for the future.
____________________________________________________________________________________________________________
cjl
--
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Bob
---------------------------------------------------------------
[Continued from Part 1]
5) The 1 MB DECmate II XPU board.
The obscure DECmate II XPU option board is a superset of the nearly as
obscure APU board, which consists of 64 KB of memory and a Z80 CPU
chip. All members of this family are interfaced to the 6120 chip at
the heart of all DECmates which performs all of the I/O functions the
Z80 requires.
However, the XPU board also sports an 8086 chip which can run MS-DOS
faster than the original 8088 IBM PC or PC-XT. While not totally PC-
compatible, a release of MS-DOS 2.1 was created for this configuration
which is capable of running a fair number of programs. A goodly
amount of them overlap with the Rainbow such as the precise
implementation of SEDT, which takes advantage of many of the features
found on the DECmate II with XPU and also on the Rainbow such as 132
column mode and the ability to support reverse video screen font.
Sold models can be had with either 256K or 512K. However, the 512K
board is only 1/2 populated. One wonders what technical snags came
about that prevented populating the board further. Due to the way
memory was allocated,it is likely the chips used couldn't be used for
a 768K implementation which is unfortunate. Additionally, a memory
controller needs to turn off memory when the memory address is
allocated for other than storage; apparently the XPU board designers
failed to take these points into account, thus every 512K XPU board
must have half the memory chips left off the board. No MS-DOS
configuration can have the entire [first] 1 MB address space totally
devoted to memory. However, the size of reserved memory would be
especially small since none of it was devoted to memory-mapped
peripherals.
The 64K memory space used as RAM by the Z80 maps 64K of the 1.0 MB
space. MS-DOS operations are implemented as in-memory transactions
carried out [as a middleman] by the Z80, which in turn has the
specifics carried out by the 6120 that has command of all available
peripherals.
Had a proper memory scheme been implemented, the maximum memory
available to MS-DOS would have been 960 KB. With a different memory
chip configuration, 768 KB would have been perfectly reasonable. This
has been done in other 808x-based systems. Perhaps they were confused
with the IBM-PC's upper memory limit of 640 KB which is not actually a
design limit of MS-DOS. [The real limitation is the need to allocate
part of the memory space to various graphics devices, reserved areas
for peripherals, and 64K for a BIOS ROM. None of these applies to the
DECmate II, just the inter-CPU memory map to the Z80 CPU chip.
6) The XPU board for the DECmate III series.
The smaller footprint DECmate III series was marketed with an optional
APU board of its own. The one for the DECmate II is compatible with
the one for the DECmate III with one nitpick exception: CP/M-80 is
created for both machines using a starter diskette that can boot up on
either family of machines [DECmate II versus DECmate III or III+ .]
There are apparently ways to tell the difference between an APU-only
machine and an XPU machine [or at least this diskette creates a
working copy system diskette that bothers to find out].
Thus, if CP/M-80 is created for an APU option board-based machine, the
resulting working copy can run on any APU-based model. However, if
the target is a machine with an XPU board, CP/M-80 will not boot
there. This situation is vice versa for CP/M-80 created for XPU-based
systems. [This is an irrational consideration. CP/M-80 doesn't use
the 8086 chip if it even is there, so why bother to create a needless
compatibility!] [WPS has features that will be available if any of
these modules is present without any otherwise distinction.]
The same aberration applies even if the target is for the DECmate II
or DECmate III+ bootable hard disk CP/M-80 volume. Master Menu is a
collection of utility programs that allows any and all operating
systems to run on any DECmate II or III+ system with a hard-disk [sold
as an option on the DECmate II but integral to the DECmate III+ .]
Master Menu can backup any hard disk volume to a series of diskettes.
The backup can be restored to a different machine. All transfers will
work perfectly except that CP/M-80 bootable volumes will not work if
the APU versus XPU considerations is violated in the analogous manner
to the diskette configurations.
As delivered, the only way to create a DM III+ bootable hard disk
volume is to first create it on a DECmate II with specifically the APU
option. Then master menu can be used to backup and restore the volume
on the hard disk within the DECmate III+ . The reason for this is
that the very same CP/M-80 generator diskette can only create hard
disk volumes using a diskette drive 0, which is not available on a
stock DECmate III+ . However, Master Menu can restore a volume using
diskette 0 that was specifically created on a DECmate II with hard
disk and specifically the APU option board. [Note: The DECmate III+
controller supports two drives, just not in the small chassis as
delivered. By bringing out the drive and power cables, it is possible
to jury-rig a pair of drives which will look to all software as a
complete dual RX50 drive. Thus, if the hardware is configured in this
impromptu fashion, CP/M-80 can be installed as intended.]
Apparently there was an intent to implement a DECmate III series XPU
board to round out the collection. However, it was relatively late in
the marketing life of the DECmates and was never implemented. [Thank
You VAXmate fools who never produced a viable product with a hard disk
at all, yet backstabbed your way into getting the DECmates cancelled
yet you never even had a product. The glorious PDP-8 history at
Digital was ended because of a non-viable attempt at a product that
should not have even been started. Since this is so heinous, it won't
even be otherwise given a place in this document. They simply didn't
do their homework, took literally years to not actually produce the
product, and then when it was attempted, it had to be withdrawn simply
because the plastic chassis didn't provide adequate cooling! Simply
no excuse considering all of the prior generation machines from the
DEC Professional to the Rainbow to the DECmate II and III+ had proper
cooling for the exact same 20 MB Seagate MF disk DEC used in all of
these designs! And this of course over and above the fact that it was
obsolete in the PC world even before it was started.]
7) The "fast" LA36.
This is somewhat of a success story, just not for DEC. The LA36 ran
at a maximum speed of 300 baud/30 CPS to accomplish only one design
goal: To obviate the need for special handling of the wide carriage
LA36 printing terminal design. In earlier designs, it was necessary
to perform special handling for functions such as vertical tab or form-
feed or in some cases just a carriage return when positioned at the
extreme right of the page. No reverse channel support is provided or
needed; it just works.
The reason is that the actual raw printing speed of the LA36 is far
faster than 30 CPS for most printing. If some relatively time-
consuming functions were being performed, the terminal was buffered
sufficiently that virtually any print situation could be handled by
eventually catching up at the raw speed of the printing unit. Thus,
performance was far better than older devices such as the model 35
teletype which required special handling for such as form-feed that
just works perfectly fine on the LA36.
As good as all of this sounds, there is a major flaw in the
reasoning: If the engine of the terminal is so much faster, why is it
printing at only 30 CPS? Why indeed!
On the LA36 control board there is a curious "test socket" which
apparently has control signals that seem to serve no purpose as far as
the stock LA36 is concerned. However, the chief designer created this
socket with an agenda:
a) He left the company after they refused to implement anything any
better; he felt his work was somewhat wasted as a result.
b) He formed his own company to market a replacement board for the
second control board mounted on the rear panel of the LA36. His
replacement board includes an embedded microprocessor and the
resultant board is far smaller than the DEC original that does far
less but takes more space and power. This smaller board is attached
to the rear panel using only a few of the mounting spacers available;
certainly sufficient for proper fastening considerations.
c) As part of the replacement, a provided cable is run between a
similar socket on the replacement board and the "test socket" on the
primary control board within the LA36 chassis. Since the unit will be
driven much harder, a heatsink is attached to the LA36 head in
anticipation of far more heat being produced when the unit prints much
faster, etc.
d) The resultant device is now designated as the DEC-sounding LS120.
While much later DEC released an even better device [not so in some
ways, just in others] called the LA180, it was only a bit faster than
the result achieved here. And it was scandalously more expensive.
e) As with the even newer DEC offering, these terminals needed to be
driven at much faster baud rates. 1200 baud was fully supported, but
hardly taking advantage of the printing speed. It was recommended to
use 2400, 4800 or even 9600 baud to maintain a partially full buffer
at all times until done printing. All DEC terminals from this point
forward used the familiar DC1/DC3 Control-S/Control-Q start-stop
protocol found in all DEC video terminals past the VT05.
Since the buffer was always ahead of the printing capabilities, the
printer always runs at maximum speed until it eventually catches up
[or the printing ceases entirely].
Additionally, the carriage is never wastefully returned as long as
there is something further to do. As necessary, printing occurs while
the head is traveling in reverse. Thus, while a section of print
might be sent as a string of characters followed by CR/LF followed by
similar text, this doesn't describe the actual printing: The first
line might be printed left to right, then the LF is performed followed
by the second line printed in reverse order until the carriage is now
back to the left margin, then the second LF is performed. Both CR
operations are virtually removed.
Since the raw speed of the printing device is about twice what the
LA36 could do, the effective speed is just about 4 times as fast as
the LA36 [not counting the overhead of LF characters]. The operating
system has to support the reverse protocol to be totally successful.
The author modified the OS/8 KL8E handler recast as a device 65/66 [or
40/41] serial printer where the only functionality of the keyboard is
to potentially pause the output by inserting Control-S into the
reverse channel [but not by the on-board microprocessor which would
eventually send Control-Q when the buffer was less than 1/4 full].
The terminal could also be used in P?S/8 as the device 03/04 console
because, unlike OS/8, P?S/8 fully supports the reverse protocol on the
console. [The P?S/8 Logical Console Overlay can be configured to
recognize the reverse protocol on the system line-printer as a
standard option; the default support is for the device 66 printer
which as a parallel device does not use the reverse protocol at all.]
The original LA36 has an exepnsive option to support the APL character
set. This can be used with such as APL-10 which exactly matches the
original IBM/360 implementation that requires IBM 2741 terminals with
APL typeballs applied. And of course the LA36 is a fully implemented
ASCII text terminal as well.
The LS-120 speed-up board comes standard with the APL character set
feature; a dip-switch can be set to defeat it if desired.
Again, a product DEC never marketed, but another company benefited
from doing their thinking for them and profiting by it.
8) The "PDP-16".
No discussion of DEC quirks and follies such as this can be complete
without mentioning the next-generation DEC design for a 16-bit
machine. [It is not clear if it would actually be called the PDP-16
because it was never actually made - by DEC.]
Edson De Castro, chief engineer on the straight PDP-8 project [and
many other successful DEC products] had designed, proposed and had
gotten approval for a 16-bit machine that was arguably a cross between
the PDP-8 and the PDP-15 with a few extra features added, but with a
16-bit word orientation instead of either 12 or 18 bits. It retains
the PDP-8 notion of indirectly referencing memory through locations
0010-0017 causing auto-indexing instead of merely indirect addressing.
[Indirect addressing means using a pointing word without modifying the
pointer. Auto-indexing is the term to describe what happens in the
PDP-8 where the pointer is first updated then used to point to the
operand. This leads to the notion of calling 10-17 octal "registers"
even though they are merely memory locations with a special property.
But this is reminiscent of actual registers as defined in other
machines such as the PDP-15 and of course the -11.]
Many [including the author] have discussed over the years why exactly
what happened in fact did happen. Suffice to say, all of the
following are true:
a) De Castro assembled a design team of about 200 people to implement
the hardware of the new product. [Note: At the time, DEC was just
starting to realize the importance of SOFTWARE to computer design;
perhaps that was not in the proper forefront as it would be at DEC in
all subsequent years.] [No one would argue that Edson De Castro was a
hardware guy.]
b) Some form of celebration of the coming event the next week was
being openly done for all parties invited on a Friday afternoon.
c) By Monday, the entire project was cancelled.
d) The PDP-11 was ingratiated instead despite serious design flaws.
Papers have been written about this. Clearly the design was not fully
vetted. Quirks existed in the design such as performing an ADD
instruction with the operand of exactly 1 does NOT create exactly the
same results as the INCREMENT instruction. [And similarly, the
SUBTRACT instruction with the same operand does not create the same
exact results as the DECREMENT instruction. So much for the "wonders"
of "symmetry".] The instruction set is so inefficient at performing
loops [all methods of counting off loop iterations are equally clumsy]
that an asymmetrical instruction was added that is analogous to the
PDP-8 ISZ operation to more efficiently count off loops. However,
earlier models do not support it, thus hampering software design which
still cannot use the improvement if the earlier models are to be
supported. [I thought this kind of nonsense was only to happen with
the PDP-8/s, but I was mistaken.]
e) Within a short measure of time, Data General Corporation was
formed primarily from the now FORMER DEC personnel of the 200 people
involved. Edson De Castro was the president of the company.
f) Data General was quite successful at making the original design,
now dubbed the Nova. Eventually a 32-bit extension was designed and
the resultant machine was dubbed the Eclipse. The book 'The Soul of a
New Machine' by Tracy Kidder became a best seller in the 1980's that
discusses this later aspect [with only a few sketchy details of what
happened in the time frame from step a) through step d). It is
telling that the Eclipse engineers got a look inside the early VAX
models at a trade show and smiled because they knew that their machine
was technologically superior; DEC was using older logic in the design.
DG's machine was the original home of the WordPerfect program, which
is why PC versions do not exist prior to Version 4.2.
g) DEC lost money to DG on various projects of significant worth such
as an open bid to create a network of small status sensing machines
throughout Disney theme parks such as Disney World Florida. The
project could have easily been implemented by some form of PDP-8, but
DEC presented a needlessly complicated PDP-11-based system. DG easily
won the contract with a much more sensible Nova-based system. [Note:
Richard Lary of DEC participated in the design of the LSI-11 based on
a small collection of chips from Western Digital known as the WD-16.
He also designed what should have been called the LSI-8 but DEC
refused to market it because it would undercut the market for the
LSI-11. Such a machine would have been perfectly adequate for Disney'
needs, and would have easily won over the DG offering which was
actually technologically backward by comparison. But by using the
PDP-11 at the center of their design, it became far too expensive. It
is noteworthy that eventually Disney abandoned this project in favor
of a more appropriate Intel 8080-based still cheaper product.
However, DEC might have gotten that newer contract had they been on
better terms with Intersil, developer of the IM6100 PDP-8-on-a-chip.
Instead they never bid and Intel won out.
Somewhat later, embarrassed by this and other "bad-blood" issues, one
of which involves your author personally, DEC refused to even talk to
Intersil and instead went to second-source provider Harris
Semiconductor. This was the basis for the extremely slow VT78, which
is even slower than the 6100 chip ought to run at. It is not known
exactly why DEC couldn't run their design at full speed [instead only
a bit over 3/4 normal clock speed], but clearly a second-source
manufacturer knows very little about the product design compared to
the design company. Had DEC swallowed its pride, it could have dealt
with Intersil directly and perhaps learned how to make the 6100 chip
run at full speed. Third-party machines at the time available from
Intersil [the "Intercept"] and machine packager Pacific CyberMetrix
[the "PCM12" and "PCM12A" at least one of which was available in kit
form with the above mentioned DSD-210 as a storage option] ran the
chip at the full 4.0 MHz standard CPU speed. The VT78 is so slow that
it has the dubious distinction as being the only machine where OS/8 on
RX01 runs with throughput 13 times as slow as all other DEC 12-bit
models. By fully taking advantage of the superior memory model, P?S/8
prevents the throughput loss on the same configuration. But OS/8
cannot remedy this situation.
Worse still, DEC awarded the contract for the next-generation 6120
chip to Harris without any participation from Intersil. Through a
pure bungling of handling the technical negotiation, design quirks
were allowed to creep in that eventually made the DECmates
incompatible with much PDP-8 software, including OS/8. Kludged and
buggy variants such as OS/278 V2 exist as testimony to these major
mistakes. [However, despite all of this, P?S/8 has conquered even
this needless incompatibility using techniques foreign to OS/8, but it
was a thankless job necessitated only because of this needless and
incompetent decision. Members of the PDP-8 programming group were
aware of the problem, yet it all fell on deaf ears.]
While DEC eventually went under for a variety of reasons [especially
too much management and driving away technical talent while being
manipulated by sales types], it is interesting to see the flawed
reasoning that made some of these quirky products never see the light
of day in users' systems. In part, this little slice of history
points the way to the ultimate end of the company.
Regardless of this, enthusiasts for the machines of the "good old
days" are perhaps at an all-time high. It is largely on account of
this, the author continues his labor of love producing independent
software and of course documenting everything for the future.
____________________________________________________________________________________________________________
cjl
--
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Al Kossow
May 21, 2012, 9:01:38 AM5/21/12
to
On 5/20/12 5:42 PM, Bob Vines wrote:
> 8) The "PDP-16".
>
> No discussion of DEC quirks and follies such as this can be complete
> without mentioning the next-generation DEC design for a 16-bit
> machine. [It is not clear if it would actually be called the PDP-16
> because it was never actually made - by DEC.]
>
The entire series of "PDP-X" memos:
> 8) The "PDP-16".
>
> No discussion of DEC quirks and follies such as this can be complete
> without mentioning the next-generation DEC design for a 16-bit
> machine. [It is not clear if it would actually be called the PDP-16
> because it was never actually made - by DEC.]
>
http://bitsavers.org/pdf/dec/pdp-x/
Bob Supnik's paper on it
http://simh.trailing-edge.com/docs/pdpx.pdf
Johnny Billquist
May 21, 2012, 11:57:55 AM5/21/12
to
DeCastro was involved in, and which got "replaced" by the PDP-11.
Also, while on that leg, I think DEC did the right decision in going
with the PDP-11 and not the PDP-X. And I think history proves them
right. While the Nova was successful, the PDP-11 was even more successful.
And it's not true that it is horrible to do loops on. While SOB is a
nice addition, a DEC followed by a branch works just as fine, and costs
only one more word. Nor is the difference between INC and ADD 1 an
accident. To think so show that you have not properly understood the
machine. My one critizism of the basic architecture is the fact that
branch offsets are expressed in bytes, which is stupid since all
addresses have to be even anyway, so that is one wasted bit that could
have been used to double the distance a branch could have taken.
The PDP-16 did actually exist, and is a totally different machine. Not
sure if cjl knows that...
Johnny
glen herrmannsfeldt
May 21, 2012, 2:19:36 PM5/21/12
to
Johnny Billquist <b...@softjar.se> wrote:
(snip)
I did work some with the Eclipse, and I remember it as 16 bits.
Among others, in Eclipse Fortran INTEGER is 16 bits, which would
be rare for a 32 bit machine. (As a previous post claimed.)
-- glen
(snip)
> Well, the PDP-X was (unless my memory fails me) the 16-bitter that
> DeCastro was involved in, and which got "replaced" by the PDP-11.
> Also, while on that leg, I think DEC did the right decision in going
> with the PDP-11 and not the PDP-X. And I think history proves them
> right. While the Nova was successful, the PDP-11 was even more successful.
I thought the Nova was the eight bit machine, and Eclipse 16 bit.
> DeCastro was involved in, and which got "replaced" by the PDP-11.
> Also, while on that leg, I think DEC did the right decision in going
> with the PDP-11 and not the PDP-X. And I think history proves them
> right. While the Nova was successful, the PDP-11 was even more successful.
I did work some with the Eclipse, and I remember it as 16 bits.
Among others, in Eclipse Fortran INTEGER is 16 bits, which would
be rare for a 32 bit machine. (As a previous post claimed.)
-- glen
Richard
May 21, 2012, 4:38:40 PM5/21/12
to
[Please do not mail me a copy of your followup]
glen herrmannsfeldt <g...@ugcs.caltech.edu> spake the secret code
<jpe0vo$as2$2...@speranza.aioe.org> thusly:
>Johnny Billquist <b...@softjar.se> wrote:
>
>(snip)
>> Well, the PDP-X was (unless my memory fails me) the 16-bitter that
>> DeCastro was involved in, and which got "replaced" by the PDP-11.
>
>> Also, while on that leg, I think DEC did the right decision in going
>> with the PDP-11 and not the PDP-X. And I think history proves them
>> right. While the Nova was successful, the PDP-11 was even more successful.
>
>I thought the Nova was the eight bit machine, and Eclipse 16 bit.
<http://en.wikipedia.org/wiki/Data_General_Nova>
<http://en.wikipedia.org/wiki/Data_General_Eclipse>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
glen herrmannsfeldt <g...@ugcs.caltech.edu> spake the secret code
<jpe0vo$as2$2...@speranza.aioe.org> thusly:
>Johnny Billquist <b...@softjar.se> wrote:
>
>(snip)
>> Well, the PDP-X was (unless my memory fails me) the 16-bitter that
>> DeCastro was involved in, and which got "replaced" by the PDP-11.
>
>> Also, while on that leg, I think DEC did the right decision in going
>> with the PDP-11 and not the PDP-X. And I think history proves them
>> right. While the Nova was successful, the PDP-11 was even more successful.
>
>I thought the Nova was the eight bit machine, and Eclipse 16 bit.
<http://en.wikipedia.org/wiki/Data_General_Eclipse>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Richard
May 21, 2012, 4:38:52 PM5/21/12
to
[Please do not mail me a copy of your followup]
Bob Vines <bobvi...@gmail.com> spake the secret code
<4f0a895d-2251-4706...@i19g2000yqn.googlegroups.com> thusly:
>This is Part 2 of the article from CJL.
Johnny Billquist
May 21, 2012, 6:31:41 PM5/21/12
to
machine, but later got a 32-bit version as well.
The Nova looks like a slightly grown PDP-8.
Johnny
Johnny Billquist
May 21, 2012, 8:09:04 PM5/21/12
to
On 2012-05-21 13:38, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Bob Vines<bobvi...@gmail.com> spake the secret code
> <4f0a895d-2251-4706...@i19g2000yqn.googlegroups.com> thusly:
>
>> This is Part 2 of the article from CJL.
>
> What is "CJL"?
Charles J Lasner. Author of PS?8. Been working in and around PDP-8s
> [Please do not mail me a copy of your followup]
>
> Bob Vines<bobvi...@gmail.com> spake the secret code
> <4f0a895d-2251-4706...@i19g2000yqn.googlegroups.com> thusly:
>
>> This is Part 2 of the article from CJL.
>
> What is "CJL"?
longer than most of us (if not all).
Johnny
Richard
May 21, 2012, 8:11:07 PM5/21/12
to
[Please do not mail me a copy of your followup]
Johnny Billquist <b...@softjar.se> spake the secret code
<jpelf0$s8f$1...@Iltempo.Update.UU.SE> thusly:
I thought it was an acronym for some kind of computer journal.
glen herrmannsfeldt
May 21, 2012, 9:19:33 PM5/21/12
to
Johnny Billquist <b...@softjar.se> wrote:
(snip, I wrote)
It seems that the Nova is 16 bits, but in compute power not so
powerful as other 16 bit machines.
> The Eclipse started out as a different 16-bit machine,
It was summer 1979 when I used one. I believe it was pretty
new at the time.
> but later got a 32-bit version as well.
Just like the PDP-11 --> VAX/11.
-- glen
(snip, I wrote)
>> I did work some with the Eclipse, and I remember it as 16 bits.
>> Among others, in Eclipse Fortran INTEGER is 16 bits, which would
>> be rare for a 32 bit machine. (As a previous post claimed.)
> The Nova is a 16 machine.
I think I was remembering comparisons of MicroNova to the 8080.
>> Among others, in Eclipse Fortran INTEGER is 16 bits, which would
>> be rare for a 32 bit machine. (As a previous post claimed.)
> The Nova is a 16 machine.
It seems that the Nova is 16 bits, but in compute power not so
powerful as other 16 bit machines.
> The Eclipse started out as a different 16-bit machine,
new at the time.
> but later got a 32-bit version as well.
-- glen
Johnny Billquist
May 22, 2012, 1:25:43 AM5/22/12
to
On 2012-05-21 18:19, glen herrmannsfeldt wrote:
> Johnny Billquist<b...@softjar.se> wrote:
>
> (snip, I wrote)
>>> I did work some with the Eclipse, and I remember it as 16 bits.
>>> Among others, in Eclipse Fortran INTEGER is 16 bits, which would
>>> be rare for a 32 bit machine. (As a previous post claimed.)
> Johnny Billquist<b...@softjar.se> wrote:
>
> (snip, I wrote)
>>> I did work some with the Eclipse, and I remember it as 16 bits.
>>> Among others, in Eclipse Fortran INTEGER is 16 bits, which would
>>> be rare for a 32 bit machine. (As a previous post claimed.)
>> The Eclipse started out as a different 16-bit machine,
>
> It was summer 1979 when I used one. I believe it was pretty
> new at the time.
I think it would have been, yes.
>
> It was summer 1979 when I used one. I believe it was pretty
> new at the time.
>> but later got a 32-bit version as well.
>
> Just like the PDP-11 --> VAX/11.
did. (Queue famous quote from the book...)
I remember looking at the 32-bit Eclipe (well, MV8000 if I remember
right) in the mid 80s, and was horrified of the architecture. I thought
it very messy.
Johnny
van...@vsta.org
May 22, 2012, 10:57:38 AM5/22/12
to
Richard <legaliz...@mail.xmission.com> wrote:
> I thought it was an acronym for some kind of computer journal.
He's far beyond a journal. Basically a one-man encyclopedia on the PDP-8. :->
> I thought it was an acronym for some kind of computer journal.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Walter Banks
Jun 11, 2012, 7:27:09 AM6/11/12
to
and we had a lonely 4K NOVA in a lab full of PDP-8's not enough
PDP8's
I wrote a PDP-8 simulator that simulated a full 4 K PDP-8 on a 4 K
Nova.
The simulator had a virtual RAM data space that used the
extra 4 bits per word on the Nova to create some of the data
space. 3K of 16 bits on the Nova was used to create 4 K PDP-8
12 bit data. The remaining 1K of Nova space was more than
enough to simulate a PDP-8.
The virtual memory if I remember correctly used 12 bits of each
Nova 16 bit word to simulate the first 6K Octal address space
making these access quick, The address space for the final 2K
octal space was made up of the 4 bit pieces of space left over.
That way most of the code executed quite fast because fetches
could read full words and essentially ignore the extra bits.
I could run all the DEC software on the Nova, (focal, PAL
ran fine) What I eventually did in the lab was use the Nova as an
PDP-8 assembler with PAL permanately loaded. The overhead
of the simulated instruction set was low enough that the assembler
was still I/O bound.
Walter :Banks
Robert Adamson <rwadamsonhotmail<dot>com>
Jun 12, 2012, 7:11:19 AM6/12/12
to
On Mon, 11 Jun 2012 07:27:09 -0400, Walter Banks
<wal...@bytecraft.com> wrote:
>It sure did. At the time I was working at the University of Waterloo
>and we had a lonely 4K NOVA in a lab full of PDP-8's not enough
>PDP8's
>
>I wrote a PDP-8 simulator that simulated a full 4 K PDP-8 on a 4 K
>Nova.
>
>The simulator had a virtual RAM data space that used the
>extra 4 bits per word on the Nova to create some of the data
>space. 3K of 16 bits on the Nova was used to create 4 K PDP-8
>12 bit data. The remaining 1K of Nova space was more than
>enough to simulate a PDP-8.
>
>The virtual memory if I remember correctly used 12 bits of each
>Nova 16 bit word to simulate the first 6K Octal address space
>making these access quick, The address space for the final 2K
>octal space was made up of the 4 bit pieces of space left over.
>That way most of the code executed quite fast because fetches
>could read full words and essentially ignore the extra bits.
>
>I could run all the DEC software on the Nova, (focal, PAL
>ran fine) What I eventually did in the lab was use the Nova as an
>PDP-8 assembler with PAL permanately loaded. The overhead
>of the simulated instruction set was low enough that the assembler
>was still I/O bound.
>
>Walter :Banks
You're not the only one!
<wal...@bytecraft.com> wrote:
>It sure did. At the time I was working at the University of Waterloo
>and we had a lonely 4K NOVA in a lab full of PDP-8's not enough
>PDP8's
>
>I wrote a PDP-8 simulator that simulated a full 4 K PDP-8 on a 4 K
>Nova.
>
>The simulator had a virtual RAM data space that used the
>extra 4 bits per word on the Nova to create some of the data
>space. 3K of 16 bits on the Nova was used to create 4 K PDP-8
>12 bit data. The remaining 1K of Nova space was more than
>enough to simulate a PDP-8.
>
>The virtual memory if I remember correctly used 12 bits of each
>Nova 16 bit word to simulate the first 6K Octal address space
>making these access quick, The address space for the final 2K
>octal space was made up of the 4 bit pieces of space left over.
>That way most of the code executed quite fast because fetches
>could read full words and essentially ignore the extra bits.
>
>I could run all the DEC software on the Nova, (focal, PAL
>ran fine) What I eventually did in the lab was use the Nova as an
>PDP-8 assembler with PAL permanately loaded. The overhead
>of the simulated instruction set was low enough that the assembler
>was still I/O bound.
>
>Walter :Banks
Around 1972-ish (?) I was working in an IC design group which used a
GDS1 graphics system hosted on a DG Nova (16k IIRC) with papertape,
disk and magtape. The factory used an LSI tester hosted on a PDP-8i.
I wrote a PDP-8 simulator so that the design group could run the
factory papertape test development software. Didn't try to economise
on memory though - just ignored the top 4 bits.
Most of the DEC software ran straightaway but Focal was a bit of a
pig. Luckily I had a listing available or it would have taken even
longer to sort through the PDP-8 model identification mess and get the
interrupts reliable. Later I added some Focal functions in high memory
to use the DG DOS for disk access which made quite a handy lab
machine.
The Calma GDS1 system included a language called GPL (a variant on APL
intended for graphics manipulations) which I found interesting but was
too alien for the rest of the design team to like.
As it happened, the factory PDP-8 spent most of its time idle, as the
IC testing took far longer than the time to set up the tests so I was
able to patch the tester handler to run as a service to Focal running
in the foreground. Lots of engineers cut their teeth on Focal.
cjl
Mar 7, 2013, 12:40:25 AM3/7/13
to
1) Your opinion about which is better is irrelevant. Part of your remarks are based on the fact that you LIKE the PDP-11 and I gather have no experience with the NOVA. I know people who worked for DEC AND DG and can give much more neutral observations.
2) That you disagree with me about facts I know is your ignorance. [I am not here to personally ram you any more than in the past; this is a friendly argument that more than a few know has gone on for years.]
As I pointed out, there are papers written on the fact that the instruction set is in fact flawed as I stated. I suggest you seek them out, read them and then admit you were mistaken. These are a) real differences, b) not designed, merely hatched because the design was rushed and not vetted. You merely stated the irrelevant simplistic observation, not what matters. Anyone who programs the PDP-8 knows that you have to preset the L bit when calculations demand it; what to do is a function of exactly what operations you are performing. PDP-11 instructions force inconsistent interpretations as an exact result of which instructions were used; that is not useful, it is merely true and is somewhat of a hindrance to proper design. I daresay probably some people will admit it caused their code to fail in some instances.
That an instruction was added is irrelevant to you because you see that the only way to do this on the earliest models is only a little longer/slower represents a minority report. [And because they don't have the new feature, compatible code must always never use the new instruction; welcome to the world of writing code for "the family of 8" as opposed to always assuming every machine has PDP-8/E with EAE.] The fact is they *did* add the instruction and it goes totally against the notion that was sold to people that the -11 was a "symmetrical" architecture. Others besides you realized it was too inefficient for a variety of sticky code situations, thus the more PDP-8-like instruction was added to bail the design out. [Perhaps if there were four variations, that might impress you. To me, that shows that symmetry is a crock, and that one good instruction was needed because various people asked for it, and virtually all of them were in-house DEC.]
To simplify your research, I partially remember one of the key papers explaining properly what should correct your notions. It has a name [don't quote me] such as The PDP-11: a case study in how NOT to design condition-code architectures.
Lastly, please separate the notion that a machine is inherently "good" merely because a lot of useful software got written for it. By that token, many would argue the greatest computer ever made was the IBM 360 and its descendants. Unfortunately, apparently some of that is factually true; I guess these people still remember the old adage: IBM, you can buy better anywhere, but you can't PAY more.
cjl
Johnny Billquist
Mar 7, 2013, 9:01:44 AM3/7/13
to
posting you replied to have expired on my news feed so I can't even see
what I wrote anymore. But I suspect it is the usual business. In some
cases we just disagree. :-)
Johnny
Allodoxaphobia
Mar 7, 2013, 10:01:30 AM3/7/13
to
Quadibloc
Apr 24, 2013, 4:36:57 PM4/24/13
to
I saw a post, too old to reply to, in this thread which said that the
Nova looked like an enlarged PDP-8.
I have seen this sentiment in books and magazine articles too. But I
disagree. The Honeywell H-316 and related machines, and the HP 2116
and related machines, looked a lot like an enlarged PDP-8. The Nova,
while less different from the PDP-8 than the PDP-11, was still a
unique architecture in its own right, as different from the PDP-8 as,
say, the LINC - at least in my opinion.
John Savard
Nova looked like an enlarged PDP-8.
I have seen this sentiment in books and magazine articles too. But I
disagree. The Honeywell H-316 and related machines, and the HP 2116
and related machines, looked a lot like an enlarged PDP-8. The Nova,
while less different from the PDP-8 than the PDP-11, was still a
unique architecture in its own right, as different from the PDP-8 as,
say, the LINC - at least in my opinion.
John Savard
Quadibloc
Jun 13, 2014, 1:31:12 PM6/13/14
to
On Sunday, May 20, 2012 6:42:28 PM UTC-6, Bob Vines wrote:
> Edson De Castro, chief engineer on the straight PDP-8 project [and
> many other successful DEC products] had designed, proposed and had
> gotten approval for a 16-bit machine that was arguably a cross between
> the PDP-8 and the PDP-15 with a few extra features added, but with a
> 16-bit word orientation instead of either 12 or 18 bits.
That sounds like a Honeywell 316 or an HP 2114, rather than the Data General Nova.
> Edson De Castro, chief engineer on the straight PDP-8 project [and
> many other successful DEC products] had designed, proposed and had
> gotten approval for a 16-bit machine that was arguably a cross between
> the PDP-8 and the PDP-15 with a few extra features added, but with a
> 16-bit word orientation instead of either 12 or 18 bits.
In that case, I think that DEC made the right decision in not going with that design. It would have been a me-too design, arriving too late on the market, which would only have a hope of success if it undercut HP and Honeywell on price. Of course, DEC was the low-price leader in those days, and I have to admit that a 16-bit version of the PDP-15 not burdened with support for one's complement arithmetic would have been a nice machine.
But compared to the highly successful and influential PDP-11, there is simply no contest. The Nova at least was also an original design which shared some of the virtues of the PDP-11, if not in as clear a form. What you're describing would either have held back the development of the minicomputer... or it would have led to Interdata taking the crown of leadership away from DEC.
John Savard
Quadibloc
Jun 13, 2014, 2:58:13 PM6/13/14
to
On Monday, May 21, 2012 12:19:36 PM UTC-6, glen herrmannsfeldt wrote:
> I thought the Nova was the eight bit machine, and Eclipse 16 bit.
No, both the Nova and the Eclipse were 16 bit machines; the Eclipse simply added a few features to the Nova.
> I thought the Nova was the eight bit machine, and Eclipse 16 bit.
John Savard
Quadibloc
Jun 13, 2014, 3:02:20 PM6/13/14
to
On Monday, May 21, 2012 7:19:33 PM UTC-6, glen herrmannsfeldt wrote:
> Johnny Billquist <b...@softjar.se> wrote:
> Johnny Billquist <b...@softjar.se> wrote:
> > but later got a 32-bit version as well.
> Just like the PDP-11 --> VAX/11.
Sort of. A selling point of the 32-bit machine from Data General was that it ran Nova software without switching into a compatibility mode; all the new instructions were just additions to the Eclipse/Nova instruction set.
> Just like the PDP-11 --> VAX/11.
Now, this wasn't necessarily a bad idea. The IBM 360 was extended this way. But the Nova happened to use virtually all the opcode space available, so this particular Data General design made very inefficient use of memory space for 32-bit programs. The Nova was not an architecture well-suited to being extended in this fashion.
John Savard
Quadibloc
Jun 13, 2014, 3:15:15 PM6/13/14
to
On Wednesday, March 6, 2013 10:40:25 PM UTC-7, cjl wrote:
> Lastly, please separate the notion that a machine is inherently "good" merely
> because a lot of useful software got written for it. By that token, many would
> argue the greatest computer ever made was the IBM 360 and its descendants.
I could say that one shouldn't say the PDP-8 is "good" just for that reason either.
> Lastly, please separate the notion that a machine is inherently "good" merely
> because a lot of useful software got written for it. By that token, many would
> argue the greatest computer ever made was the IBM 360 and its descendants.
You may well be right that the PDP-11 has flaws not shared by the Data General Nova. I'd have to look at the articles you pointed out to find out the specific weaknesses you are concerned about.
I haven't worked on either the Data General Nova or the PDP-11, but I *have* worked on the Texas Instruments 990/4 computer, which used their 9900 microprocessor.
Like the Nova, it used (in software) the IBM 360 floating-point format. Badly flawed, but at least the bytes in it weren't stored in memory in BADCFEHG order like on the PDP-11. Unlike the PDP-11, it didn't make one of its general registers a stack pointer, and assign the program counter to another general register slot.
But it was an imitation of the PDP-11 idea, each instruction being composed of a four-bit opcode plus two six-bit blocks containing an addressing mode and a register number. Instead of eight addressing modes and eight registers, it had four addressing modes and sixteen registers.
The registers were in a work area in memory indicated by a workspace pointer; this was because the 9900 was one of the earliest 16-bit microprocessors, and they couldn't yet put enough transistors on a chip to put the registers on the chip.
I didn't notice any major flaws in the 9900 ISA.
It wasn't just that a lot of software got written for the PDP-11. Even if it did have flaws due to being rushed to market, it was a highly influential design for a reason - unlike the Honeywell 316 and the HP 2114/2115/2116, which were 16-bit computers in the PDP-8/PDP-15 vein, it was a considerably more modern and orthogonal design.
It was influenced by the System/360 in having both 16-bit register to register instructions and 32-bit memory to register instructions, although it went a step further by also having 32-bit register to memory and 48-bit memory to memory instructions for every opcode.
It blazed a trail for others - like TI with the 9900 - to follow. It made architectures like the Honeywell 316 or the HP 2116 obsolete overnight. (Which other minicomputers that were smaller improvements over that style of computer, like the Nova, failed to do.)
I don't happen to like the fact that computers these days tend to be little-endian, and so I'm not entirely a fan of the PDP-11. But I cannot deny or minimize its importance.
John Savard
Charles Richmond
Jun 13, 2014, 3:37:02 PM6/13/14
to
"Quadibloc" <jsa...@ecn.ab.ca> wrote in message
news:59e502aa-eac4-4cae...@googlegroups.com...
ISTR that the Eclipse was kind of a "super" Nova with "virtual memory"...
--
numerist at aquaporin4 dot com
news:59e502aa-eac4-4cae...@googlegroups.com...
--
numerist at aquaporin4 dot com
Quadibloc
Jun 13, 2014, 3:48:47 PM6/13/14
to
On Wednesday, March 6, 2013 10:40:25 PM UTC-7, cjl wrote:
> As I pointed out, there are papers written on the fact that the instruction set
> is in fact flawed as I stated. I suggest you seek them out, read them and then
> admit you were mistaken.
Attempting to Google for anything about flaws in the PDP-11 instruction set failed for me. Probably one instead needs to search the printed literature around the time when the PDP-11 first came out.
> is in fact flawed as I stated. I suggest you seek them out, read them and then
> admit you were mistaken.
The only thing I did find was that as highly orthogonal an architecture as the PDP-11 will be less efficient in terms of the space consumed by programs. That is true, but the current low price of memory is not the only reason that this is not regarded as a sufficiently significant flaw to offset the virtues of orthogonality - basically, the needs of compiler writers are considered paramount these days.
John Savard
Quadibloc
Jun 13, 2014, 4:10:34 PM6/13/14
to
On Wednesday, March 6, 2013 10:40:25 PM UTC-7, cjl wrote:
> To simplify your research, I partially remember one of the key papers
> explaining properly what should correct your notions. It has a name [don't
> quote me] such as The PDP-11: a case study in how NOT to design condition-code
> architectures.
Your memory is pretty good:
> explaining properly what should correct your notions. It has a name [don't
> quote me] such as The PDP-11: a case study in how NOT to design condition-code
> architectures.
http://dl.acm.org/citation.cfm?id=803047
John Savard
0 new messages