Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DEC/PDP-8 Stuff That Never Quite Happened, Part 1
382 views
Skip to first unread message
Bob Vines
May 20, 2012, 8:39:17 PM5/20/12
to
I've broken this posting from CJL into two parts due to its length.
Here is Part 1.
Bob
---------------------------------------------------------------
DEC had a lot of suggested projects. Some of them even saw the light
of day, if only in-house. Some of the information leaked to third-
parties who implemented some aspects of them [perhaps better], and
some of it was deliberately leaked to competitors as false commitments
so they would waste their time on fools errands designing something no
one cared about. In some cases, I have had personal conversations
with some-time DEC employees, in other instances they represent well-
known issues to a very small circle of people, said circle in need of
being widened. The common thread is that none of them were ever sold
by Digital Equipment Corporation. Studying them should give the
reader some insight into the good [and the bad] of the company.
Items:
Part 1
1) The faux EAE option for the PDP-8/e.
2) The RX03 drive.
3) The TC8E DECtape controller.
4) The "PDP-10".
Part 2
5) The 1 MB DECmate II XPU board.
6) The XPU board for the DECmate III series.
7) The "fast" LA36.
8) The "PDP-16".
----------------------------------------------------------
1) The faux EAE option for the PDP-8/e.
DEC was quite unhappy that a competitor appeared making a PDP-8-
compatible machine. For whatever reason, they felt they couldn't sue
Digital Computer Controls, whose two models DCC-112 and DCC-112H were
quite competitive. Rumor has it that the H [high-speed] model could
outperform DEC's then-current offerings. The Omnibus was new, and the
PDP-8/e was so new, it a) Didn't have revised modules; so many were so
badly flawed, few survived. [How to tell, a few modules have numbers
like M8xx and were NOT replaced with numbers such as M8xxy. However,
most of them were replaced with the 4-digit numbers and these (3-
digit) cards are just about worthless. b) the eventual EAE option was
not fully designed much less implemented. [Note: The DCC machines
used the previous [positive] buss generation that virtually demanded
wire-wrapped backplane peripherals. Thus, it was more of a candidate
for a CPU replacement than an entire competitive machine. You kept
your existing DEC peripherals as part of the upgrade. It is not clear
just how many peripherals DCC made. Known customers included the New
York City OffTrack Betting Coporation and the San Francisco BART
System.] [These two applications likely demanded custom peripherals
conforming to DEC's positive buss spec, and then to save money used
the DCC CPUs. But I did hear about standard configurations such as
DECtapes on the DCC machines.] [In fact, DEC attempted to sabotage OS/
8 and later FOCAL-8 to self-destruct if running on the DCC machines.
If you look in certain OS/8 source code files, there is mention of
REMOVING the DCC sabotage code. In the case of FOCAL-8, the code is
in the binary. The source is obfuscated taking advantage of a
weakness of PAL8 and CREF where printout output lines are sequence-
numbered after-the-fact. P?S/8 PAL and PAL10 perform statement
numbering, not printed output numbering; the serious change in
statement number would be a dead give-away. In any case, P?S/8 and OS/
8 both support BITMAP which plainly shows the multiple loading in the
binary. I personally produced at some point a source file of how to
overlay the FOCAL, 1969 binary paper-tape to get the same result as
the FOCAL-8 tape. My source code doesn't hide anything, so you see
the faux code that loads there [some irrelevant source code lines that
do nothing but irrelevant and innocuous things that have no global
meaning, just to hide the real code] and then the attempt to turn
listing off but the binary loads over the faux lines to see what is
really happening: Three components are added together: two
instructions in the code itself and a fudge constant that makes that
all add up to some group one OPR instruction that apparently on a DCC
machine does something very un-DEC-like. The sum is then stored
inline and thus executed as it falls through into the memory location
it was stored into. Based on what AC or L contents result, it then
either goes ahead if a DEC model or destroys major storage pointers in
FOCAL so it dies a slow death as you use it, to throw people off and
then perhaps blame DCC's hardware. I can only presume something
analogous was actually done to OS/8 and then they changed their minds
and dropped it there, etc. Since it is mentioned in more than a few
source code files, I can only presume it was pretty nasty.]
At the time, DEC was actually designing a two-stage EAE option set for
the PDP-8/e CPU board set. The idea was to be 100% compatible with
the EAE found in the PDP-8/I and PDP-12 [Note: The straight PDP-8 is
a subset of that level of extended arithmetic; the instruction to swap
the AC and MQ register doesn't completely work in that machine. All
models with an MQ since then, even without EAE, support the SWP
instruction correctly.] In the final implementation this became known
as "Mode A" and was the default from a power-up. [Thus, the machine
is 100% compatible with existing programs that require EAE.] A second
mode was added that became known as "Mode B" which basically adds in a
lot of double-precision [24-bit] instructions that execute much faster
than performing the underlying operations across a few instructions.
[Note: Both modes support an instruction to switch to the other
mode.]
However, DEC deliberately published in early documentation what was
first thought to be a tentative specification for the "new" EAE
option. DCC fell for it and started designing it for their machines
[which at the time lacked EAE]. But it was totally bogus. Clearly it
was never intended to be made because it includes nearly worthless
instructions. [If you wanted to develop EAE, an absolute-value
unsigned normalize instruction [NMU] would not be your highest
priority, especially since it would also be totally incompatible with
the EAE of previous models.]
For various reasons, DCC was forced out of business [primarily for
cloning Data General Nova machines of that era right down to the exact
mechanicals and dimensions] and became a division of Data General. DG
supported the 16 bit Nova clones for a time, but immediately
discontinued the 12-bit line. By then, few remembered this odd set of
EAE definitions that were never implemented by DEC. In the end, this
was a good thing to avoid.
2) The RX03 drive.
The RX03 was to be basically a double-sided RX02 drive. In fact, all
existent RX02 drives partially respond to RX03 commands. [If you set
the head bit on an RX03 to the unimplemented surface, your code will
either hang or return a not-well-known error message depending on how
sophisticated the coding is. [Note: The P?S/8 non-system handler
supports single-density [RX01-type] media on all known hardware
configurations including the RX03. If the other head should somehow
exist, the logical disk space continues onto the second side. This
scheme is identical to that used by certain OS/8 handlers that were
also designed for this hardware that was never sold by DEC.]
However, the RX03 did have a viable product life - as a PDP-11
peripheral. Data Systems Design was known for DEC-compatible RX01
drives that could properly support write protect [both from foil label
sensors on the media and write-protect switches on the drive
chassis]. DSD released an RX03-compatible drive as a PDP-11
peripheral which was totally compatible with their superset features
as well as all of the RX03 features. [You'll have to ask an -11
person for its model number. I would believe it is a DSD-something
higher than 240. A 240 isn't an RX anything but I worked on them as
well, a quite powerful hard disk better than RK and RL by a long
shot. Also holds more: 5 MB fixed section with a 45 MB removable
cartridge that vaguely resembles RL cartridges. You could therefore
do copying of drives the long way around even though you only had a
single drive playing some interesting "tower of babylon" games, etc.
Also, it is a minor possibility the company changed its name
eventually. But clearly it concentrated on -11 interfaced-only
devices eventually. An RT-11 guy should know what we need.]
Apparently, as in the case of OS/8 for the PDP-8 series, RT-11 fully
supports the DSD drives as RX03 with no software changes whatsoever.
[Note: It is not known if the DSD drives and chassis could be
attached to the DSD RX8E-compatible controller for the DSD-210 drive.
It is conceivable however the drive was never sold separately. Also,
there is an alternate RX8E-compatible interface for the DSD-210 when
used in the Intersil Intercept I or the PCM-12 and PCM-12A from
Pacific CyberMetrix. They will either all work or all not work; I
have worked with both interfaces on the same DSD-210 drive.] [Note:
All DSD RX-compatible peripherals can format the 8" diskettes unlike
the actual DEC offering.]
It would appear that with that much commitment, this was a last-minute
marketing decision to not sell the RX03 drive. It would have been
compatible with many different systems DEC sold.
3) The TC8E DECtape controller.
When the TU56 dual DECtape drive was designed [also available as the
one-drive TU56H], it was made to be compatible with every viable DEC
tape buss convention. [Note: The relay logic levels of a few very
early controllers was dropped.] This included the negative tape buss
for the TC01/08 and the TC12 function of the PDP-12 and also positive
tape buss systems such as the TC15 and the later TC11 controllers on
18-bit and 16-bit systems. All of these systems have one common
element: The tape drive heads must be handled by an elaborate
analogue module known as the G8882 on all negative logic machines and
controllers [TC01, TC02, LINC-8] and G888 on all positive logic
controllers [TC11, TC15]. [The PDP-12 would also use G888 because it
is a primarily TTL positive logic backplane.] The functionality of
these modules is the well-known Manchester reader/writer implemented
on all relevant DECtape [and LINCtape] systems. [These modules were
based on earlier analogue modules for even earlier systems such as the
PDP-6 and the PDP-5.]
A standard feature was the ability to have the G888 cards directly
within the TU56 chassis allowing the entire drive to be controlled by
TTL signals within a simple ribbon cable.
The first such controller was the single-board Omnibus controller
known as the TD8E. Unlike the earlier systems, the TD8E could only
address a single drive pair. [All of the other systems could use
expansion cables to support up to a total of 8 drives, even if a mixed
system of TU55 and TU56 drives. The limitation is apparently as a
result of having the G888 cards within the single supportable
chassis.]
The TD8E was somewhat of a failure for a variety of reasons: It
required software implementation of supporting every tape cycle. In
terms of 12-bit operations, this occurs every 133 microseconds
nominal. However, the calculation overhead required to program the
DECtape check-summing operation consumes a lot of the CPU power to the
extent that this barely functions in real-time with few CPU cycles to
spare. However, despite being nominally able to keep up with the tape
data rate, an unexpected factor arose related to the condition of the
drive [and to some extent the tapes as well] that was not noticed
earlier in the design life of the TU55 and TU56 drives. [The point is
that it did work, albeit only barely so when jitter and worn/bad
mechanicals [partially as a result of poor mechanical design that was
eventually fixed and could be retrofitted to all drives] contributed
to bunched-up cycles. Some got longer which is not an issue, but
correspondingly, as one got longer, another would get shorter, and if
not enough real time to keep up, could have fatal results as in bad
writing and a small potential of deformatting the tape in extremely
bad nightmare scenarios.] This is because all of the other systems
use DMA to implement both the data transfer and the checksumming
operations [as well as tape position sensing, which is more a matter
of programming code space than anything else] which can tolerate
shorter tape data cycles if need be. [If a tape should jitter
excessively, some tape cycles are actually lengthened. But to the
extent one tape cycle is "stretched" in time, another tape cycle will
be "shrunk" in time. As such, there may not be sufficient program
execution cycles available to keep up with the data rate, especially
at key tape cycles with great overhead borne of the necessity to
quickly perform relatively complex calculations.]
The overall compromised design impacts badly on OS/8, which for quite
awhile dealt with the TD8E as a "bastard step-child". Eventually
other equally code-space-challenging devices were required to be
supported and the TD8E just became the head of the "rogue's gallery"
of peripherals that needed quite kludged handling in OS/8 just to be
supported at all. [Note: The author suggested an alternate memory
model as a superior way to support devices such as the TD8E, but the
suggested design was ignored by the PDP-8 programming group. However,
P?S/8 fully implements this alternate memory model allowing the
possibility of the relevant issues being supported without the kludges
that had to be redundantly added into every application program that
requires a clean 15-bit memory space such as OS/8 BASIC and Fortran 4,
which use 15-bit addressing to access most of 32K with linear
addressing as is required in the supported hardware such as the FPP-12
or FPP-8/A floating point hardware option, or software systems that
emulate the same environment. [Note: Fortran 4 runs on the FPP
hardware or a simulator of the same 15-bit mode of operation by
supplying a run-time simulator if the hardware is not available. OS/8
BASIC only uses a software package that requires the same 32K-oriented
linear addressing mode. All regular PDP-8 operations are 4K 12-bit
addressing modes. Since the OS/8 memory model for use with the TD8E
and similar devices is in conflict with the 15-bit addressing mode,
each of these applications must kludge the OS/8 system handler by
placing it into an alternate 12-bit memory field during the execution
of the application; if the system handler is not returned to the
normal designated memory locations afterwards, the system remains
corrupted in various ways until it is rebooted. Future versions of P?
S/8 are expected to include a SHELL overlay to allow an operating
environment roughly analogous to OS/8, allowing OS/8 applications to
be ported to the SHELL environment with only small to moderate
modification. In the specific case of these problematic applications
as described above, all of the sections of kludge code can be totally
deleted.]
The TD8E cannot operate in an environment where interrupts are enabled
due to the predictable nature of many cycles lost to servicing other
devices. In fact, the TD8E doesn't participate in the interrupt
process at all; there is literally no interrupt structure on the
device. [Note: P?S/8 TD8E handlers presume the CPU is the PDP-8/E or
PDP-8/A only. As such, the handler is able to sense if interrupts are
turned on at entry using an instruction not found on previous models -
SKON - Skip the next instruction if interrupts are on, then turn
interrupts off. This is used to create an interrupt enable at the
exit portion of the handler call. In any case, interrupts are not
allowed during the main execution of the handler operation.] As such,
the TD8E is not only incompatible with all other PDP-8 DECtape
programming, it is also unsuitable for a large variety of real-time
applications that depend on the smooth continuous DMA transfers of the
TC01/08 DECtape controller. [Note: The author wrote various real-
time data collection programs that could not run on very many
devices. This is because the device might run TOO FAST. Even if a
device transfers via DMA, the system could be intermittently
compromised by excessive DMA cycles preventing sufficient attention to
interrupts from other devices.]
While many systems were configured with the TD8E as an economy storage
device, it was often realized that too much money was spent for not
enough performance; if the appropriate KD8E and KA8E buss convertor
cards were added to the PDP-8/E, a TC08 added to the system would
provide all of the lost performance with not that much more cost than
the TD8E. The only problem for some was the overhead of supporting a
somewhat bulky TC08 wire-wrapped controller, clearly a part of the
previous generation. [From the Omnibus perspective, the two buss
convertor cards were only one slot more of a space issue than the
single-card TD8E.]
The solution to all of this was created by DEC and predictably called
the TC8E. It was prototyped as a two-card set that outputted a cable
the same way as the TD8E and used an identically configured TU56 drive
with the G888 cards inside. For any system that didn't otherwise
require the KA8E and KD8E buss convertor cards, it wasn't that much
more expensive than a TD8E.
The TC8E was also to be a superset in terms of functionality as
compared to the TC01 and TC08 controllers. When DECtape is read in
the opposite direction of original writing, the data arrives in
complement-obverse form. [Note: This is not an issue for programs
such as the standard DTCOPY program because the data is always written
in the same direction as was read. However, this has no impact on the
original direction the data was written in as this is a blind-copy
program. Other utilities may have to deal with the intended direction
of transfer such as converting 18/36 bit systems tapes to files native
to the operating system.]
A problematic utility that data direction impacts on is PIP10 which
needs to reckon the original direction of data creation since file
conversion is part of the overall process. To aid in the
implementation of programs of this class, a frill feature was added to
have the controller reshuffle the data bits so that the data arrives
in memory correctly when transferring in the direction opposite to the
original writing direction. The only difference is the transfer order
in memory, which does not require any bit-twiddling, just a
decrementing pointer situation for the direction-opposed block
transfers. By exploiting this feature, programs could perform this
sort of operation more efficiently. In some instances, loss of tape
motion could be avoided. [Note: It is possible to achieve a moderate
approach using more memory for translation tables that is a better
compromise while avoiding the requirement for this frill feature not
found in the TC01 or TC08. TD8E support in these programs could also
be improved by applying some of these techniques.] [Of course, from a
DEC marketing stand-point, that it becomes a unique frill feature is a
sales point, and a lot of people were unhappy with the TD8E for all
sorts of reasons, most of them quite valid.]
We may never know why the TC8E was never marketed. One certainty is
that while the TD8E was initially considered *the* problem case, other
devices with far worse problems came along. Performance in OS/8 is
always compromised because of the unrealistic memory requirement a
handler is constrained by. Thus, the problem became engrained in OS/8
and no one-off hardware project could ever fix that. To the author's
recollection, not one device where OS/8 requires 12K for the system
handler exists where there are no weaknesses within the handler; they
are all compromised because they run out of code space. The issues
could be either performance, depth of error recovery or both [or
perhaps versatility].
The OS/8 TC01/08/8E DECtape system handler is needlessly mediocre.
However, this is merely a matter of poor code design. Due to the
relative intelligence of the controller, there is still enough code
space in the system handler to overcome most of these design
weaknesses. In the design of P?S/8, the one-page system handler for
TC01/08/8E DECtape represents the template of what features can be
crammed into the handler code space. Part of the design effort has
been to define what represents the absolute minimum complement of
features that need to co-exist with handler-specific instructions yet
be able to at least bootup the system on a 4K machine and also support
all defined options and parameters. At this point in time, not one
bit is unallocated. [Note: Little additional work is contemplated for
the P?S/8 main-line code, while most of the effort going forward will
be towards implementing the SHELL. The only known issue pertains to
the main-line code and is not relevant when operating in the SHELL
environment. In one context, the affected words are redeployed, while
in the other, there is a theoretical unspecified bit not associated
with any utility. It is conceivable this unallocated bit may be
revisited; however, there is currently no feature known to become
possible by taking advantage of it.]
[Further explanatory note about really caring about every bit:
To even implement the SHELL, it became necessary to define its
presence or not in a new status bit. Also, previous P?S/8
implementations did NOT have the high-order 6 bits of the 18-bit date
in memory, but rather they were IMPLIED. This is not as bad as it
sounds for a variety of reasons:
1) The Tiny File System (TFS) files and directory structure do not
support the concept of a date [the way OS/8 also doesn't if you set
the Additional Information Word (AIW) count to 0].
Thus, this was merely a matter handled by the keyboard monitor command
DATE which had a small patcheable conditional section that needed to
periodically have the minor patch update every 8 years.
2) Additional programs used once-only code to format out a date using
appropriate digits. Again, the same code could get an analogous patch
every 8 years.
3) Before the date format was changed, you had nearly 12 years to
apply the patch instead of the expected date. This is because the
date can handle nearly 12 years using a small anomaly, i.e., the
calculation of the overall date includes a redundant section of
possibilities. Thus, for any base year of multiples of 8, you could
have any date in the range of the next 8 years, but since the 12-bit
portion could go for nearly another 4 years, you had no immediate
impetus to change it. If you up the base group by 8 years anytime
after the end of the previous 8 years, some of the dates could still
be expressed in those overlapping possibly redundantly expressed years
of those extra nearly 4 years.
When P?S/8 was respecified, the date was reduced back to something
comparable to OS/8 handling exactly 8 years and no more. However, at
the same time, some bits were scrounged up to make more sense
overall. Thus, here is the before and after definition of location
07607 which precedes 07610 which is the low-order 12-bits of the date.
Before, 7610 is that older format that can handle 11.75 years. 7607
is defined as the number of files passed starting in 07757 that are
pre-allocated output files before the input files. The maximum number
of files is 17 decimal if you use 07757-07777 inclusive. Shorter
lists are terminated with a 0000 word. The format is BLOCK&7770 plus
unit & 7. In the TFS, the files must align on multiples of 8
boundaries. In point of fact they align on multiples of 16 bits, thus
an inherent wasted bit still not defined. But meaningful only when
passing TFS files, so this is not even relevant to the SHELL. Because
of the alignment, the low-order bits should be set to 000. This
allows the block number to occupy only 9 bits to get a 12-bit
quantity. In all of P?S?8, the system handler requires a 3-bit
logical unit thus 0 through 7. Thus, the elements of this list give
15 bits of information in 12-bits total each. In any case, all TFS
files are exactly 16 decimal blocks long which makes all of this
possible. Commands exist to pass pre-allocated output files to system
programs. Thus, while there could be as many as 21 files octal
passed, the pre-allocated output files are passed first. Thus, there
needs to be a head count of how many of them are output files [and the
input, if any, implicitly follow]. Thus, this is a quantity that
varies from a low of 0000 to as high as 0021. However, that means
only the low-order 5 bits are ever set/meaningful.
Thus, the new modifications of 07607 [the "after] are as follows:
Bits[7-11] are the count of passed output files if the SHELL is not in
effect only. There is no explicit "The SHELL is in effect" bit, but
the environment a program is even be running in is implicit in how it
was invoked. The only way a program can be running in normal [non-
SHELL] P?S/8 is to expect the files to be passed in 07757-onward; all
of the other paramters exist in both environments. In regular P?S/8
that can only be achieved if the program is added to the systems
program directory or at the minimum is started by the START command,
which in turn reserves the /0-/7 option switches [for the starting
field] and the = parameter for the program's own starting address.
Otherwise, any and all program options would be available. Most
notably, there are no guarantees of any of this when running under
regular P?S/8 ODT which is not designed to debug core-image programs,
just loaded user binary programs now converted to a subset of core-
image program where no system parameters are passed. [The 4K system
cannot be used to debug in the general-purpose sense. The SHELL
largely corrects this, fully except for some nitpicks that are
configuration dependent and do not exist in 8K or larger systems.]
Part of the SHELL environment is a two-page (256 word) area that is
used for passing program and file information that gets dynamically
updated both by the program and making calls to the User File Operator
(UFO is much more interesting than OS/8 USR as an abbreviation, but
the same sort of thing). The two page area holds a lot more than OS/
8's field 1 resident in 17600-17777, which is an intrusive part of
memory and really marginalized OS/8 when it comes to applications that
need contiguous 15-bit address space. And this is far larger than
theirs because there is far more information needed for a variety of
reasons, such as the filenames are 12.4 with case retention while OS/8
is 6.2 without case retention, essentially always upper-case. Also,
part of it is reserved for use with the sprung breakpoint mechanism of
the new debugger.
This item can be memory resident, but it doesn't have to, at some loss
of performance, especially on DECtapes and LINCtapes. If in memory,
it is in x5400-x5777 where x is the highest field of physical memory.
If not, it is the contents of two adjacent low-numbered blocks on the
system device [something like say block 120 octal, which in OS/8 terms
would be record 0050].
A means is necessary to know where to look for it, and that is the new
definition of bit[0] of the word in 07607.
In the SHELL environment, the files must have access to the full date
word data [which is 18 bits, the other 12 low-order being the contents
of 07610]. Unlike the TFS files of regular P?S/8 which have no date
association whatsoever, the full date will be permanently attached to
the file as part of the entry in the directory. Thus, bits[1-6] are
the six-bit extension to the low-order date word, in essence which 8
year group is the low-order date word in [which expresses an offset of
0 days through 8 years-1]. Thus, the date can range from 01-Jan-1960
through 31-Dec-2471. [Will handle all sixties PDP-6/10 files and
forward.] [Note: I am willing to take some consensus info as to
whether to bother to start the range earlier, such as 1900, as in some
IBM systems. When you support 512 years, you can afford to play with
it a little!]
Never let it be said I didn't attempt to use every bit of resources!]
4) The "PDP-10".
Many have discussed the short-comings of the PDP-8/s model. [Some of
which seem somewhat capricious and clearly are merely to minimize the
complement of cards in the chassis. That certain programs become
impossible due to a particular "for want of a nail" is a consequence
of not considering the proper requirements of software design.]
However, the PDP-8/s was completed with core memory within the
chassis. Certain memory-related options are of necessity add-ons.
What may surprise some DEC enthusiasts is that the original machine
was to be somewhat slower than what was produced. This never-
completed machine was to have the maximum memory of 32K in all models
and not an option. However, the memory would be a rotating fixed head
per track disk addressable to the nearest word. As some of you have
gathered, this is essentially a description of the DF32 recast as
rotating memory. It is no coincidence that a single DF32 platter is
exactly the size of a 32K machine.
This machine would have been dubbed the PDP-10, considered at the time
to be the next model number up. It presumably would be compatible
with the current PDP-8/s and would have required extended memory
control. With no apparent means of optimizing instruction physical
position, the "speed" would have been amazingly slow compared to the
PDP-8/S that was sold. In hindsight this was certainly a better
outcome; the DF32 enjoyed special attention because of the ideas
learned in the abortive PDP-10 project such as 4:1 memory interleave
to accommodate the slower serial logic in a processor. The DF32 was
released with expansion DS32 units as a possibility to amass a total
of 128K storage. Arguably this is also the forerunner of the RF08
which could eventually be configured as large as 2.0 MWords of
storage.
[It apparently is true a DF32 could consider having a parity bit
applied. That would be consistent with it being used as memory. All
DEC systems have had some measure of optional memory to possibly
consider. In the PDP-8/e, it was an extra core-stack with some of it
wasted holding the parity bits from all of the 32K of memory
possible. I would gather the notion of parity disk storage was not on
their minds, just that this was a notion when it was rotating main
memory and it's still inherently in the design.]
And of course, the PDP-10 name was re-purposed to be the designation
of a truly wonderful 36-bit machine.
[To be continued in Part 2]
----------------------------------------------------------
cjl
--
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Here is Part 1.
Bob
---------------------------------------------------------------
DEC had a lot of suggested projects. Some of them even saw the light
of day, if only in-house. Some of the information leaked to third-
parties who implemented some aspects of them [perhaps better], and
some of it was deliberately leaked to competitors as false commitments
so they would waste their time on fools errands designing something no
one cared about. In some cases, I have had personal conversations
with some-time DEC employees, in other instances they represent well-
known issues to a very small circle of people, said circle in need of
being widened. The common thread is that none of them were ever sold
by Digital Equipment Corporation. Studying them should give the
reader some insight into the good [and the bad] of the company.
Items:
Part 1
1) The faux EAE option for the PDP-8/e.
2) The RX03 drive.
3) The TC8E DECtape controller.
4) The "PDP-10".
Part 2
5) The 1 MB DECmate II XPU board.
6) The XPU board for the DECmate III series.
7) The "fast" LA36.
8) The "PDP-16".
----------------------------------------------------------
1) The faux EAE option for the PDP-8/e.
DEC was quite unhappy that a competitor appeared making a PDP-8-
compatible machine. For whatever reason, they felt they couldn't sue
Digital Computer Controls, whose two models DCC-112 and DCC-112H were
quite competitive. Rumor has it that the H [high-speed] model could
outperform DEC's then-current offerings. The Omnibus was new, and the
PDP-8/e was so new, it a) Didn't have revised modules; so many were so
badly flawed, few survived. [How to tell, a few modules have numbers
like M8xx and were NOT replaced with numbers such as M8xxy. However,
most of them were replaced with the 4-digit numbers and these (3-
digit) cards are just about worthless. b) the eventual EAE option was
not fully designed much less implemented. [Note: The DCC machines
used the previous [positive] buss generation that virtually demanded
wire-wrapped backplane peripherals. Thus, it was more of a candidate
for a CPU replacement than an entire competitive machine. You kept
your existing DEC peripherals as part of the upgrade. It is not clear
just how many peripherals DCC made. Known customers included the New
York City OffTrack Betting Coporation and the San Francisco BART
System.] [These two applications likely demanded custom peripherals
conforming to DEC's positive buss spec, and then to save money used
the DCC CPUs. But I did hear about standard configurations such as
DECtapes on the DCC machines.] [In fact, DEC attempted to sabotage OS/
8 and later FOCAL-8 to self-destruct if running on the DCC machines.
If you look in certain OS/8 source code files, there is mention of
REMOVING the DCC sabotage code. In the case of FOCAL-8, the code is
in the binary. The source is obfuscated taking advantage of a
weakness of PAL8 and CREF where printout output lines are sequence-
numbered after-the-fact. P?S/8 PAL and PAL10 perform statement
numbering, not printed output numbering; the serious change in
statement number would be a dead give-away. In any case, P?S/8 and OS/
8 both support BITMAP which plainly shows the multiple loading in the
binary. I personally produced at some point a source file of how to
overlay the FOCAL, 1969 binary paper-tape to get the same result as
the FOCAL-8 tape. My source code doesn't hide anything, so you see
the faux code that loads there [some irrelevant source code lines that
do nothing but irrelevant and innocuous things that have no global
meaning, just to hide the real code] and then the attempt to turn
listing off but the binary loads over the faux lines to see what is
really happening: Three components are added together: two
instructions in the code itself and a fudge constant that makes that
all add up to some group one OPR instruction that apparently on a DCC
machine does something very un-DEC-like. The sum is then stored
inline and thus executed as it falls through into the memory location
it was stored into. Based on what AC or L contents result, it then
either goes ahead if a DEC model or destroys major storage pointers in
FOCAL so it dies a slow death as you use it, to throw people off and
then perhaps blame DCC's hardware. I can only presume something
analogous was actually done to OS/8 and then they changed their minds
and dropped it there, etc. Since it is mentioned in more than a few
source code files, I can only presume it was pretty nasty.]
At the time, DEC was actually designing a two-stage EAE option set for
the PDP-8/e CPU board set. The idea was to be 100% compatible with
the EAE found in the PDP-8/I and PDP-12 [Note: The straight PDP-8 is
a subset of that level of extended arithmetic; the instruction to swap
the AC and MQ register doesn't completely work in that machine. All
models with an MQ since then, even without EAE, support the SWP
instruction correctly.] In the final implementation this became known
as "Mode A" and was the default from a power-up. [Thus, the machine
is 100% compatible with existing programs that require EAE.] A second
mode was added that became known as "Mode B" which basically adds in a
lot of double-precision [24-bit] instructions that execute much faster
than performing the underlying operations across a few instructions.
[Note: Both modes support an instruction to switch to the other
mode.]
However, DEC deliberately published in early documentation what was
first thought to be a tentative specification for the "new" EAE
option. DCC fell for it and started designing it for their machines
[which at the time lacked EAE]. But it was totally bogus. Clearly it
was never intended to be made because it includes nearly worthless
instructions. [If you wanted to develop EAE, an absolute-value
unsigned normalize instruction [NMU] would not be your highest
priority, especially since it would also be totally incompatible with
the EAE of previous models.]
For various reasons, DCC was forced out of business [primarily for
cloning Data General Nova machines of that era right down to the exact
mechanicals and dimensions] and became a division of Data General. DG
supported the 16 bit Nova clones for a time, but immediately
discontinued the 12-bit line. By then, few remembered this odd set of
EAE definitions that were never implemented by DEC. In the end, this
was a good thing to avoid.
2) The RX03 drive.
The RX03 was to be basically a double-sided RX02 drive. In fact, all
existent RX02 drives partially respond to RX03 commands. [If you set
the head bit on an RX03 to the unimplemented surface, your code will
either hang or return a not-well-known error message depending on how
sophisticated the coding is. [Note: The P?S/8 non-system handler
supports single-density [RX01-type] media on all known hardware
configurations including the RX03. If the other head should somehow
exist, the logical disk space continues onto the second side. This
scheme is identical to that used by certain OS/8 handlers that were
also designed for this hardware that was never sold by DEC.]
However, the RX03 did have a viable product life - as a PDP-11
peripheral. Data Systems Design was known for DEC-compatible RX01
drives that could properly support write protect [both from foil label
sensors on the media and write-protect switches on the drive
chassis]. DSD released an RX03-compatible drive as a PDP-11
peripheral which was totally compatible with their superset features
as well as all of the RX03 features. [You'll have to ask an -11
person for its model number. I would believe it is a DSD-something
higher than 240. A 240 isn't an RX anything but I worked on them as
well, a quite powerful hard disk better than RK and RL by a long
shot. Also holds more: 5 MB fixed section with a 45 MB removable
cartridge that vaguely resembles RL cartridges. You could therefore
do copying of drives the long way around even though you only had a
single drive playing some interesting "tower of babylon" games, etc.
Also, it is a minor possibility the company changed its name
eventually. But clearly it concentrated on -11 interfaced-only
devices eventually. An RT-11 guy should know what we need.]
Apparently, as in the case of OS/8 for the PDP-8 series, RT-11 fully
supports the DSD drives as RX03 with no software changes whatsoever.
[Note: It is not known if the DSD drives and chassis could be
attached to the DSD RX8E-compatible controller for the DSD-210 drive.
It is conceivable however the drive was never sold separately. Also,
there is an alternate RX8E-compatible interface for the DSD-210 when
used in the Intersil Intercept I or the PCM-12 and PCM-12A from
Pacific CyberMetrix. They will either all work or all not work; I
have worked with both interfaces on the same DSD-210 drive.] [Note:
All DSD RX-compatible peripherals can format the 8" diskettes unlike
the actual DEC offering.]
It would appear that with that much commitment, this was a last-minute
marketing decision to not sell the RX03 drive. It would have been
compatible with many different systems DEC sold.
3) The TC8E DECtape controller.
When the TU56 dual DECtape drive was designed [also available as the
one-drive TU56H], it was made to be compatible with every viable DEC
tape buss convention. [Note: The relay logic levels of a few very
early controllers was dropped.] This included the negative tape buss
for the TC01/08 and the TC12 function of the PDP-12 and also positive
tape buss systems such as the TC15 and the later TC11 controllers on
18-bit and 16-bit systems. All of these systems have one common
element: The tape drive heads must be handled by an elaborate
analogue module known as the G8882 on all negative logic machines and
controllers [TC01, TC02, LINC-8] and G888 on all positive logic
controllers [TC11, TC15]. [The PDP-12 would also use G888 because it
is a primarily TTL positive logic backplane.] The functionality of
these modules is the well-known Manchester reader/writer implemented
on all relevant DECtape [and LINCtape] systems. [These modules were
based on earlier analogue modules for even earlier systems such as the
PDP-6 and the PDP-5.]
A standard feature was the ability to have the G888 cards directly
within the TU56 chassis allowing the entire drive to be controlled by
TTL signals within a simple ribbon cable.
The first such controller was the single-board Omnibus controller
known as the TD8E. Unlike the earlier systems, the TD8E could only
address a single drive pair. [All of the other systems could use
expansion cables to support up to a total of 8 drives, even if a mixed
system of TU55 and TU56 drives. The limitation is apparently as a
result of having the G888 cards within the single supportable
chassis.]
The TD8E was somewhat of a failure for a variety of reasons: It
required software implementation of supporting every tape cycle. In
terms of 12-bit operations, this occurs every 133 microseconds
nominal. However, the calculation overhead required to program the
DECtape check-summing operation consumes a lot of the CPU power to the
extent that this barely functions in real-time with few CPU cycles to
spare. However, despite being nominally able to keep up with the tape
data rate, an unexpected factor arose related to the condition of the
drive [and to some extent the tapes as well] that was not noticed
earlier in the design life of the TU55 and TU56 drives. [The point is
that it did work, albeit only barely so when jitter and worn/bad
mechanicals [partially as a result of poor mechanical design that was
eventually fixed and could be retrofitted to all drives] contributed
to bunched-up cycles. Some got longer which is not an issue, but
correspondingly, as one got longer, another would get shorter, and if
not enough real time to keep up, could have fatal results as in bad
writing and a small potential of deformatting the tape in extremely
bad nightmare scenarios.] This is because all of the other systems
use DMA to implement both the data transfer and the checksumming
operations [as well as tape position sensing, which is more a matter
of programming code space than anything else] which can tolerate
shorter tape data cycles if need be. [If a tape should jitter
excessively, some tape cycles are actually lengthened. But to the
extent one tape cycle is "stretched" in time, another tape cycle will
be "shrunk" in time. As such, there may not be sufficient program
execution cycles available to keep up with the data rate, especially
at key tape cycles with great overhead borne of the necessity to
quickly perform relatively complex calculations.]
The overall compromised design impacts badly on OS/8, which for quite
awhile dealt with the TD8E as a "bastard step-child". Eventually
other equally code-space-challenging devices were required to be
supported and the TD8E just became the head of the "rogue's gallery"
of peripherals that needed quite kludged handling in OS/8 just to be
supported at all. [Note: The author suggested an alternate memory
model as a superior way to support devices such as the TD8E, but the
suggested design was ignored by the PDP-8 programming group. However,
P?S/8 fully implements this alternate memory model allowing the
possibility of the relevant issues being supported without the kludges
that had to be redundantly added into every application program that
requires a clean 15-bit memory space such as OS/8 BASIC and Fortran 4,
which use 15-bit addressing to access most of 32K with linear
addressing as is required in the supported hardware such as the FPP-12
or FPP-8/A floating point hardware option, or software systems that
emulate the same environment. [Note: Fortran 4 runs on the FPP
hardware or a simulator of the same 15-bit mode of operation by
supplying a run-time simulator if the hardware is not available. OS/8
BASIC only uses a software package that requires the same 32K-oriented
linear addressing mode. All regular PDP-8 operations are 4K 12-bit
addressing modes. Since the OS/8 memory model for use with the TD8E
and similar devices is in conflict with the 15-bit addressing mode,
each of these applications must kludge the OS/8 system handler by
placing it into an alternate 12-bit memory field during the execution
of the application; if the system handler is not returned to the
normal designated memory locations afterwards, the system remains
corrupted in various ways until it is rebooted. Future versions of P?
S/8 are expected to include a SHELL overlay to allow an operating
environment roughly analogous to OS/8, allowing OS/8 applications to
be ported to the SHELL environment with only small to moderate
modification. In the specific case of these problematic applications
as described above, all of the sections of kludge code can be totally
deleted.]
The TD8E cannot operate in an environment where interrupts are enabled
due to the predictable nature of many cycles lost to servicing other
devices. In fact, the TD8E doesn't participate in the interrupt
process at all; there is literally no interrupt structure on the
device. [Note: P?S/8 TD8E handlers presume the CPU is the PDP-8/E or
PDP-8/A only. As such, the handler is able to sense if interrupts are
turned on at entry using an instruction not found on previous models -
SKON - Skip the next instruction if interrupts are on, then turn
interrupts off. This is used to create an interrupt enable at the
exit portion of the handler call. In any case, interrupts are not
allowed during the main execution of the handler operation.] As such,
the TD8E is not only incompatible with all other PDP-8 DECtape
programming, it is also unsuitable for a large variety of real-time
applications that depend on the smooth continuous DMA transfers of the
TC01/08 DECtape controller. [Note: The author wrote various real-
time data collection programs that could not run on very many
devices. This is because the device might run TOO FAST. Even if a
device transfers via DMA, the system could be intermittently
compromised by excessive DMA cycles preventing sufficient attention to
interrupts from other devices.]
While many systems were configured with the TD8E as an economy storage
device, it was often realized that too much money was spent for not
enough performance; if the appropriate KD8E and KA8E buss convertor
cards were added to the PDP-8/E, a TC08 added to the system would
provide all of the lost performance with not that much more cost than
the TD8E. The only problem for some was the overhead of supporting a
somewhat bulky TC08 wire-wrapped controller, clearly a part of the
previous generation. [From the Omnibus perspective, the two buss
convertor cards were only one slot more of a space issue than the
single-card TD8E.]
The solution to all of this was created by DEC and predictably called
the TC8E. It was prototyped as a two-card set that outputted a cable
the same way as the TD8E and used an identically configured TU56 drive
with the G888 cards inside. For any system that didn't otherwise
require the KA8E and KD8E buss convertor cards, it wasn't that much
more expensive than a TD8E.
The TC8E was also to be a superset in terms of functionality as
compared to the TC01 and TC08 controllers. When DECtape is read in
the opposite direction of original writing, the data arrives in
complement-obverse form. [Note: This is not an issue for programs
such as the standard DTCOPY program because the data is always written
in the same direction as was read. However, this has no impact on the
original direction the data was written in as this is a blind-copy
program. Other utilities may have to deal with the intended direction
of transfer such as converting 18/36 bit systems tapes to files native
to the operating system.]
A problematic utility that data direction impacts on is PIP10 which
needs to reckon the original direction of data creation since file
conversion is part of the overall process. To aid in the
implementation of programs of this class, a frill feature was added to
have the controller reshuffle the data bits so that the data arrives
in memory correctly when transferring in the direction opposite to the
original writing direction. The only difference is the transfer order
in memory, which does not require any bit-twiddling, just a
decrementing pointer situation for the direction-opposed block
transfers. By exploiting this feature, programs could perform this
sort of operation more efficiently. In some instances, loss of tape
motion could be avoided. [Note: It is possible to achieve a moderate
approach using more memory for translation tables that is a better
compromise while avoiding the requirement for this frill feature not
found in the TC01 or TC08. TD8E support in these programs could also
be improved by applying some of these techniques.] [Of course, from a
DEC marketing stand-point, that it becomes a unique frill feature is a
sales point, and a lot of people were unhappy with the TD8E for all
sorts of reasons, most of them quite valid.]
We may never know why the TC8E was never marketed. One certainty is
that while the TD8E was initially considered *the* problem case, other
devices with far worse problems came along. Performance in OS/8 is
always compromised because of the unrealistic memory requirement a
handler is constrained by. Thus, the problem became engrained in OS/8
and no one-off hardware project could ever fix that. To the author's
recollection, not one device where OS/8 requires 12K for the system
handler exists where there are no weaknesses within the handler; they
are all compromised because they run out of code space. The issues
could be either performance, depth of error recovery or both [or
perhaps versatility].
The OS/8 TC01/08/8E DECtape system handler is needlessly mediocre.
However, this is merely a matter of poor code design. Due to the
relative intelligence of the controller, there is still enough code
space in the system handler to overcome most of these design
weaknesses. In the design of P?S/8, the one-page system handler for
TC01/08/8E DECtape represents the template of what features can be
crammed into the handler code space. Part of the design effort has
been to define what represents the absolute minimum complement of
features that need to co-exist with handler-specific instructions yet
be able to at least bootup the system on a 4K machine and also support
all defined options and parameters. At this point in time, not one
bit is unallocated. [Note: Little additional work is contemplated for
the P?S/8 main-line code, while most of the effort going forward will
be towards implementing the SHELL. The only known issue pertains to
the main-line code and is not relevant when operating in the SHELL
environment. In one context, the affected words are redeployed, while
in the other, there is a theoretical unspecified bit not associated
with any utility. It is conceivable this unallocated bit may be
revisited; however, there is currently no feature known to become
possible by taking advantage of it.]
[Further explanatory note about really caring about every bit:
To even implement the SHELL, it became necessary to define its
presence or not in a new status bit. Also, previous P?S/8
implementations did NOT have the high-order 6 bits of the 18-bit date
in memory, but rather they were IMPLIED. This is not as bad as it
sounds for a variety of reasons:
1) The Tiny File System (TFS) files and directory structure do not
support the concept of a date [the way OS/8 also doesn't if you set
the Additional Information Word (AIW) count to 0].
Thus, this was merely a matter handled by the keyboard monitor command
DATE which had a small patcheable conditional section that needed to
periodically have the minor patch update every 8 years.
2) Additional programs used once-only code to format out a date using
appropriate digits. Again, the same code could get an analogous patch
every 8 years.
3) Before the date format was changed, you had nearly 12 years to
apply the patch instead of the expected date. This is because the
date can handle nearly 12 years using a small anomaly, i.e., the
calculation of the overall date includes a redundant section of
possibilities. Thus, for any base year of multiples of 8, you could
have any date in the range of the next 8 years, but since the 12-bit
portion could go for nearly another 4 years, you had no immediate
impetus to change it. If you up the base group by 8 years anytime
after the end of the previous 8 years, some of the dates could still
be expressed in those overlapping possibly redundantly expressed years
of those extra nearly 4 years.
When P?S/8 was respecified, the date was reduced back to something
comparable to OS/8 handling exactly 8 years and no more. However, at
the same time, some bits were scrounged up to make more sense
overall. Thus, here is the before and after definition of location
07607 which precedes 07610 which is the low-order 12-bits of the date.
Before, 7610 is that older format that can handle 11.75 years. 7607
is defined as the number of files passed starting in 07757 that are
pre-allocated output files before the input files. The maximum number
of files is 17 decimal if you use 07757-07777 inclusive. Shorter
lists are terminated with a 0000 word. The format is BLOCK&7770 plus
unit & 7. In the TFS, the files must align on multiples of 8
boundaries. In point of fact they align on multiples of 16 bits, thus
an inherent wasted bit still not defined. But meaningful only when
passing TFS files, so this is not even relevant to the SHELL. Because
of the alignment, the low-order bits should be set to 000. This
allows the block number to occupy only 9 bits to get a 12-bit
quantity. In all of P?S?8, the system handler requires a 3-bit
logical unit thus 0 through 7. Thus, the elements of this list give
15 bits of information in 12-bits total each. In any case, all TFS
files are exactly 16 decimal blocks long which makes all of this
possible. Commands exist to pass pre-allocated output files to system
programs. Thus, while there could be as many as 21 files octal
passed, the pre-allocated output files are passed first. Thus, there
needs to be a head count of how many of them are output files [and the
input, if any, implicitly follow]. Thus, this is a quantity that
varies from a low of 0000 to as high as 0021. However, that means
only the low-order 5 bits are ever set/meaningful.
Thus, the new modifications of 07607 [the "after] are as follows:
Bits[7-11] are the count of passed output files if the SHELL is not in
effect only. There is no explicit "The SHELL is in effect" bit, but
the environment a program is even be running in is implicit in how it
was invoked. The only way a program can be running in normal [non-
SHELL] P?S/8 is to expect the files to be passed in 07757-onward; all
of the other paramters exist in both environments. In regular P?S/8
that can only be achieved if the program is added to the systems
program directory or at the minimum is started by the START command,
which in turn reserves the /0-/7 option switches [for the starting
field] and the = parameter for the program's own starting address.
Otherwise, any and all program options would be available. Most
notably, there are no guarantees of any of this when running under
regular P?S/8 ODT which is not designed to debug core-image programs,
just loaded user binary programs now converted to a subset of core-
image program where no system parameters are passed. [The 4K system
cannot be used to debug in the general-purpose sense. The SHELL
largely corrects this, fully except for some nitpicks that are
configuration dependent and do not exist in 8K or larger systems.]
Part of the SHELL environment is a two-page (256 word) area that is
used for passing program and file information that gets dynamically
updated both by the program and making calls to the User File Operator
(UFO is much more interesting than OS/8 USR as an abbreviation, but
the same sort of thing). The two page area holds a lot more than OS/
8's field 1 resident in 17600-17777, which is an intrusive part of
memory and really marginalized OS/8 when it comes to applications that
need contiguous 15-bit address space. And this is far larger than
theirs because there is far more information needed for a variety of
reasons, such as the filenames are 12.4 with case retention while OS/8
is 6.2 without case retention, essentially always upper-case. Also,
part of it is reserved for use with the sprung breakpoint mechanism of
the new debugger.
This item can be memory resident, but it doesn't have to, at some loss
of performance, especially on DECtapes and LINCtapes. If in memory,
it is in x5400-x5777 where x is the highest field of physical memory.
If not, it is the contents of two adjacent low-numbered blocks on the
system device [something like say block 120 octal, which in OS/8 terms
would be record 0050].
A means is necessary to know where to look for it, and that is the new
definition of bit[0] of the word in 07607.
In the SHELL environment, the files must have access to the full date
word data [which is 18 bits, the other 12 low-order being the contents
of 07610]. Unlike the TFS files of regular P?S/8 which have no date
association whatsoever, the full date will be permanently attached to
the file as part of the entry in the directory. Thus, bits[1-6] are
the six-bit extension to the low-order date word, in essence which 8
year group is the low-order date word in [which expresses an offset of
0 days through 8 years-1]. Thus, the date can range from 01-Jan-1960
through 31-Dec-2471. [Will handle all sixties PDP-6/10 files and
forward.] [Note: I am willing to take some consensus info as to
whether to bother to start the range earlier, such as 1900, as in some
IBM systems. When you support 512 years, you can afford to play with
it a little!]
Never let it be said I didn't attempt to use every bit of resources!]
4) The "PDP-10".
Many have discussed the short-comings of the PDP-8/s model. [Some of
which seem somewhat capricious and clearly are merely to minimize the
complement of cards in the chassis. That certain programs become
impossible due to a particular "for want of a nail" is a consequence
of not considering the proper requirements of software design.]
However, the PDP-8/s was completed with core memory within the
chassis. Certain memory-related options are of necessity add-ons.
What may surprise some DEC enthusiasts is that the original machine
was to be somewhat slower than what was produced. This never-
completed machine was to have the maximum memory of 32K in all models
and not an option. However, the memory would be a rotating fixed head
per track disk addressable to the nearest word. As some of you have
gathered, this is essentially a description of the DF32 recast as
rotating memory. It is no coincidence that a single DF32 platter is
exactly the size of a 32K machine.
This machine would have been dubbed the PDP-10, considered at the time
to be the next model number up. It presumably would be compatible
with the current PDP-8/s and would have required extended memory
control. With no apparent means of optimizing instruction physical
position, the "speed" would have been amazingly slow compared to the
PDP-8/S that was sold. In hindsight this was certainly a better
outcome; the DF32 enjoyed special attention because of the ideas
learned in the abortive PDP-10 project such as 4:1 memory interleave
to accommodate the slower serial logic in a processor. The DF32 was
released with expansion DS32 units as a possibility to amass a total
of 128K storage. Arguably this is also the forerunner of the RF08
which could eventually be configured as large as 2.0 MWords of
storage.
[It apparently is true a DF32 could consider having a parity bit
applied. That would be consistent with it being used as memory. All
DEC systems have had some measure of optional memory to possibly
consider. In the PDP-8/e, it was an extra core-stack with some of it
wasted holding the parity bits from all of the 32K of memory
possible. I would gather the notion of parity disk storage was not on
their minds, just that this was a notion when it was rotating main
memory and it's still inherently in the design.]
And of course, the PDP-10 name was re-purposed to be the designation
of a truly wonderful 36-bit machine.
[To be continued in Part 2]
----------------------------------------------------------
cjl
--
"In the future, OS/2 will be on everyone's desktop"
Bill Gates, 1992
Jim Gonzalez
Mar 8, 2018, 7:17:59 PM3/8/18
to
How about RK8L information and history?
And no, it is not/was not made for PDP8L.
It is a two board RK8E (OmniBus controlller) with some advanced features.
"Bob Vines" <bobvi...@gmail.com> wrote in message
news:56039eca-6cf2-4468...@e18g2000yqc.googlegroups.com...
And no, it is not/was not made for PDP8L.
It is a two board RK8E (OmniBus controlller) with some advanced features.
"Bob Vines" <bobvi...@gmail.com> wrote in message
news:56039eca-6cf2-4468...@e18g2000yqc.googlegroups.com...
cjl
Mar 19, 2018, 4:34:12 AM3/19/18
to
On Thursday, March 8, 2018 at 7:17:59 PM UTC-5, Jim Gonzalez wrote:
> How about RK8L information and history?
>
> And no, it is not/was not made for PDP8L.
>
> It is a two board RK8E (OmniBus controlller) with some advanced features.
I am aware of it, if for no other reason the name of the newest formatting program claims it.
> How about RK8L information and history?
>
> And no, it is not/was not made for PDP8L.
>
> It is a two board RK8E (OmniBus controlller) with some advanced features.
I can only assume the redo was for the 8/A only to fit all the logic on two hex boards, and that the extension features were to reimplement the RKS8E extensions as well, all in two slots.
I do know that at the time, they were becoming slot-count conscious because of the desirable configuration wanted to fit in 20 slots maximum. However, there were expansion options, albeit rare.
If you use the BC-80C cable in the 8/A chassis, it takes up on slot with a lot of plate-through so the bus comes out as a proper pair of 8/E box connectors for quad Omnibus. This was done so the FPP-8/A and say the 10-slot 8/A box was now to be known as the "FPP-8/E" etc.
I use one of them on a machine with a 40-slot 8/E box on the buss end that starts in toe 8/A box. It is an 8/A 625 with EAE using the 8/E CPU, and the terminator is in the 8/E box just behind the 8/E front panel. This is legal and proper with one proviso. There are "bad" display positions onthe 8/E front panel which will make it display incorrectly because I[0] and I[1] on the Omnbus get ored together, etc. The CPU must be the all-the-way-up version of the KK8F with EAE optional including the highest ECO terminator card, etc.
In mine, the memory is two 2-slot 16K core stacks in the 8/A box, but in theory, this can be KT8A stuff or the CESI incompatible stuff that can go up to 128K and 512K respectively.
I guess they felt saving a slot was important, but it was never sold. Have no idea how the 8/L nomenclature was added, other than a mis-stated "economy" version
cjl
cjl
Aug 1, 2018, 8:13:28 AM8/1/18
to
This one (part 2) slipped through the cracks:
> 5) The 1 MB DECmate II XPU board.
There is a larger XPU board for the DECmate III that has 1/2 of the board demised. Apparently there was an intention to flesh out the board to have 1024 KB of memory. I think this was shot down by the need to place the Z80 into that memory space and they never completely thought it through. From the seeming layout, it might be possible to get 768K; I'm sure the conventional scuttlebut about PCs and 640K comes to mind. Eventually there were some chipsets that allowed more memory than 650K depending on video requirements, but clearly where exactly the contiguous top of memory was subject to change.
I guess with such low production quantities, it wasn't worth the bother to change the artwork, etc.
>
> 6) The XPU board for the DECmate III series.
A lot of documentation exists referencing an XPU board for the DECmate III family, from what I heard it was a working prototype in-uouse, but it wasn't ever marketed.
The APU board was marketed for both the DECmate III and DECmate III+ . However, CPM/80 support screwed up with regard to the DECmate III+ .
In order to create a "working copy" tailored to the machine, you need to have drive 1, not a problem on any system with an RX50. But the DECmate III PACKAGING can't support that!
I have cabled up a DECmate III with a pair of FD55GFV or GFR drives without a problem. Unlike on a PC, the unit select is real, not fudged in a twisted cable so the drives are always drive 1. Also, it is permanently set to spin 20% faster for full media capacity with the RX50, which means that it does transfer bit faster, but no other aspect of the superior drive was taken advantage of.
If you are creating CP/M-80 for the hard disk, there is no problem, but without a drive 1, you cannot create a descendent bootable DIskette version.
Because of the small size of the DECmate III chassis, there is no room for a 1/2 height hard disk and two FD55 drives at the same time, but I did make a cable so it hangs out, and a power Y cable makes it all viable electrically [with both drives hanging out on the table. However, this configuration can create the correct bootable diskette, etc
There are three needlessly different "variants" here: The starter distribution diskette can be booted to because of some internal "special" nature of itself. Descendent systems for machines with APU boards and XPU boards cannot mix.
As such, without a drive 1 at times, it's difficult to get a working APU-based system on the DECmate III directly. You always need "help" some way, either my mechanical kludge or indirectly from a DECmate II with a hard drive.
Master Menu can create backup copies of disk-based bootable operating systems. Fortunately, you can specify drive 0 as the backup drive, thus you can move around compatible bootables between say the DECmate II and the DECmate III+ . The point is you have to unless you have drive 1, and that is the default in many systems, and in some the only choice for certain things, etc.
Thus, this is a logical "hole" in things.
It would have been better to make NONE of them check, yet they do. So, any system created on any APU-based system works fine there, and any XPU system-based CP/M-80 will presuably run there as well. Without a DECmate III based XPU, it does become moot, but in any case, bothering to check which flavor of support is present is a bridge too far. The 6120 bootup code knows what is going on, but someone thought it would be cute to overly check for this in the Z80 code as well. Note: On the XPU, the 8086 asks for services from the Z80, thought shared memory space. The Z80 in turn, talks to the 6121 on device code 14. This part is also true for CP/M-80 directly from the Z80 itself.
>
> 7) The "fast" LA36.
This product was marketed - but not by DEC.
Aooarently, upper management was not ready to support a faster than 300 baud terminal such as the LA36. You may notice there are circumstances it tends to slightly fall behind, but then it goes faster and completely catches up.
This is because it is inherently faster, but this way you never need protocol to talk to the drives from systems such as OS/8 that has flakey console output. Regardless of how it came to be, this capability was wasted.
A really clever engineer on the project had a really brilliant "exit strategy" for himself. there exists a "test sockete" on the inner board of the LA36. It serves no function - not on the normal LA36.
But he quit and formed the conmpany known as DataSouth and marketed a speed-up kit.
You toss the larger interface board on the back cover and in its place mount a tiny board with a microprocessor onboard with some DIP switches. It percectly matches just enough mounting holes to be fine, but now most of the space is truly empty.
There is a cable to plug between the speed-up board and the "test socket" so it can monitor and control what is going on.
Bottom line, you can now print at nearly 4 times the speed. The recomended baud rate is 4800 or 9600. That way, you are always attempting to keep the buffer full. When necessarary, lines are printed in the reverse direction to avoid wasteful carriage movement. It really looks "zippy" performing these tricks, etc.
Of course, you have to seriously support Control-S/Control-Q, so OS/8 usage as a console is out of the question unless you set it back down to 300 baud which totally wastes all the effort.
The only thing you can do in OS/8 is to use it as a serial printer by modifying the KL8E handler to use the protocol and say device 40/41. That works fine. You have to set the top-of-form to match paper-fan-fold considerations but a lot faster to get a nice wide-carriage listing. [Note: But PAL8 cannot handle the full width. It is not possible to get PAL8 to output more than 88 positions and there are quires along the way where some output cannot be wider than 86 positions. A lot of my source code has some line templates after the $ so they are logically ignored, because PAL8 will truncate the output, even if in the midst of a long source line, and of course will always truncate comments, etc.
Contrast this with P?S/8 that fully embraces wider lines and the Control-Control-Q protocol is universal by being disciplined about the issue. My Kermit-12 does, but it is the exception. This is not a design flaw of OS/8, rather an implementation sloppiness.
Thus, in P?S/8 it is perfectly useful for either a serial printer or the system console, etc.
DEC eventually marketed slightly faster devices than this, but quite a while later, and only slightly better and a lot more expensive. As in those faster devices, you also had to mount a (supplied) heatsink to keep the heads from burning up, etc.
A nice fril was also the APL option is built-in and just a DIP switch setting away.
In short, a wonderful improvement all the way around.
>
> 8) The "PDP-16".
This is more of a marketing term for K modules and DIY logic design. There is no real "computer" here. In fact, the usual support is to write programs in a cousin Of OS/8 BASIC called Industrial BASIC. For no good reason, there is actually three variants, instead of one smarter compiler. [Marketing "triumphs" over technology and creates less revenue as well.)
As an aside, there are two well-known published theses that include direct demonstration of the flaky design of the PDP-11, and how poor a performer it is.
One is known as "The PDP-11, a case study in how NOT to design condition-code architecture.
I don't remember the title of the other one, but the gist of it is this:
Three 16-bit archtectures are compared in various static and dynamic ways.
1) The PDP-11 comes out dead last in all of the tests.
2) The DG Nova fairs somewhat better in just about all if the tests. We all admit the level of software SUPPORT is good per se for the PDP-11, that's not the point, it is just not as good a design to have been bothered with, and, as many of us know, the DG design was intended to be marketed by DEC. Imagine if DEC software savvy had been applied to the Nova. DG was not known for great software as most of the people who jumped ship were hardware types.
That said, WordPerfect was started on the Nova by a third-party company. This is why you don't see low release versions for PCs, etc.
3) The "PDP-16". This is the author's notation for a machine design of its own. In essence, it is a 16-bit "stretched" PDP-8 with an address space more like a PDP-15 and also morrows fron the extended OPR design of the PDP-8//15 since there are more bits available, etc.
An entire operating system was created that supported it's assembler and TECO as the designated editor. A simulator was created to make all of that happen, and then cycle by cycle, this is compared to the other two, etc.
Needless to say, due to its PDP-8 roots, it wins hand down in all of the tests. The tests are fair, and expose several weeknesses in all three designs, but they are most problematic on the PDP-11, while the NOva and PDP-16 are somewhat closer. This is also not surprising considering some other aspects of the PDP-8 are borrowed in the NOva, such as the auto-index registers in 10-17, etc.
cjl
> 5) The 1 MB DECmate II XPU board.
I guess with such low production quantities, it wasn't worth the bother to change the artwork, etc.
>
> 6) The XPU board for the DECmate III series.
The APU board was marketed for both the DECmate III and DECmate III+ . However, CPM/80 support screwed up with regard to the DECmate III+ .
In order to create a "working copy" tailored to the machine, you need to have drive 1, not a problem on any system with an RX50. But the DECmate III PACKAGING can't support that!
I have cabled up a DECmate III with a pair of FD55GFV or GFR drives without a problem. Unlike on a PC, the unit select is real, not fudged in a twisted cable so the drives are always drive 1. Also, it is permanently set to spin 20% faster for full media capacity with the RX50, which means that it does transfer bit faster, but no other aspect of the superior drive was taken advantage of.
If you are creating CP/M-80 for the hard disk, there is no problem, but without a drive 1, you cannot create a descendent bootable DIskette version.
Because of the small size of the DECmate III chassis, there is no room for a 1/2 height hard disk and two FD55 drives at the same time, but I did make a cable so it hangs out, and a power Y cable makes it all viable electrically [with both drives hanging out on the table. However, this configuration can create the correct bootable diskette, etc
There are three needlessly different "variants" here: The starter distribution diskette can be booted to because of some internal "special" nature of itself. Descendent systems for machines with APU boards and XPU boards cannot mix.
As such, without a drive 1 at times, it's difficult to get a working APU-based system on the DECmate III directly. You always need "help" some way, either my mechanical kludge or indirectly from a DECmate II with a hard drive.
Master Menu can create backup copies of disk-based bootable operating systems. Fortunately, you can specify drive 0 as the backup drive, thus you can move around compatible bootables between say the DECmate II and the DECmate III+ . The point is you have to unless you have drive 1, and that is the default in many systems, and in some the only choice for certain things, etc.
Thus, this is a logical "hole" in things.
It would have been better to make NONE of them check, yet they do. So, any system created on any APU-based system works fine there, and any XPU system-based CP/M-80 will presuably run there as well. Without a DECmate III based XPU, it does become moot, but in any case, bothering to check which flavor of support is present is a bridge too far. The 6120 bootup code knows what is going on, but someone thought it would be cute to overly check for this in the Z80 code as well. Note: On the XPU, the 8086 asks for services from the Z80, thought shared memory space. The Z80 in turn, talks to the 6121 on device code 14. This part is also true for CP/M-80 directly from the Z80 itself.
>
> 7) The "fast" LA36.
This product was marketed - but not by DEC.
Aooarently, upper management was not ready to support a faster than 300 baud terminal such as the LA36. You may notice there are circumstances it tends to slightly fall behind, but then it goes faster and completely catches up.
This is because it is inherently faster, but this way you never need protocol to talk to the drives from systems such as OS/8 that has flakey console output. Regardless of how it came to be, this capability was wasted.
A really clever engineer on the project had a really brilliant "exit strategy" for himself. there exists a "test sockete" on the inner board of the LA36. It serves no function - not on the normal LA36.
But he quit and formed the conmpany known as DataSouth and marketed a speed-up kit.
You toss the larger interface board on the back cover and in its place mount a tiny board with a microprocessor onboard with some DIP switches. It percectly matches just enough mounting holes to be fine, but now most of the space is truly empty.
There is a cable to plug between the speed-up board and the "test socket" so it can monitor and control what is going on.
Bottom line, you can now print at nearly 4 times the speed. The recomended baud rate is 4800 or 9600. That way, you are always attempting to keep the buffer full. When necessarary, lines are printed in the reverse direction to avoid wasteful carriage movement. It really looks "zippy" performing these tricks, etc.
Of course, you have to seriously support Control-S/Control-Q, so OS/8 usage as a console is out of the question unless you set it back down to 300 baud which totally wastes all the effort.
The only thing you can do in OS/8 is to use it as a serial printer by modifying the KL8E handler to use the protocol and say device 40/41. That works fine. You have to set the top-of-form to match paper-fan-fold considerations but a lot faster to get a nice wide-carriage listing. [Note: But PAL8 cannot handle the full width. It is not possible to get PAL8 to output more than 88 positions and there are quires along the way where some output cannot be wider than 86 positions. A lot of my source code has some line templates after the $ so they are logically ignored, because PAL8 will truncate the output, even if in the midst of a long source line, and of course will always truncate comments, etc.
Contrast this with P?S/8 that fully embraces wider lines and the Control-Control-Q protocol is universal by being disciplined about the issue. My Kermit-12 does, but it is the exception. This is not a design flaw of OS/8, rather an implementation sloppiness.
Thus, in P?S/8 it is perfectly useful for either a serial printer or the system console, etc.
DEC eventually marketed slightly faster devices than this, but quite a while later, and only slightly better and a lot more expensive. As in those faster devices, you also had to mount a (supplied) heatsink to keep the heads from burning up, etc.
A nice fril was also the APL option is built-in and just a DIP switch setting away.
In short, a wonderful improvement all the way around.
>
> 8) The "PDP-16".
This is more of a marketing term for K modules and DIY logic design. There is no real "computer" here. In fact, the usual support is to write programs in a cousin Of OS/8 BASIC called Industrial BASIC. For no good reason, there is actually three variants, instead of one smarter compiler. [Marketing "triumphs" over technology and creates less revenue as well.)
As an aside, there are two well-known published theses that include direct demonstration of the flaky design of the PDP-11, and how poor a performer it is.
One is known as "The PDP-11, a case study in how NOT to design condition-code architecture.
I don't remember the title of the other one, but the gist of it is this:
Three 16-bit archtectures are compared in various static and dynamic ways.
1) The PDP-11 comes out dead last in all of the tests.
2) The DG Nova fairs somewhat better in just about all if the tests. We all admit the level of software SUPPORT is good per se for the PDP-11, that's not the point, it is just not as good a design to have been bothered with, and, as many of us know, the DG design was intended to be marketed by DEC. Imagine if DEC software savvy had been applied to the Nova. DG was not known for great software as most of the people who jumped ship were hardware types.
That said, WordPerfect was started on the Nova by a third-party company. This is why you don't see low release versions for PCs, etc.
3) The "PDP-16". This is the author's notation for a machine design of its own. In essence, it is a 16-bit "stretched" PDP-8 with an address space more like a PDP-15 and also morrows fron the extended OPR design of the PDP-8//15 since there are more bits available, etc.
An entire operating system was created that supported it's assembler and TECO as the designated editor. A simulator was created to make all of that happen, and then cycle by cycle, this is compared to the other two, etc.
Needless to say, due to its PDP-8 roots, it wins hand down in all of the tests. The tests are fair, and expose several weeknesses in all three designs, but they are most problematic on the PDP-11, while the NOva and PDP-16 are somewhat closer. This is also not surprising considering some other aspects of the PDP-8 are borrowed in the NOva, such as the auto-index registers in 10-17, etc.
cjl
Scott Lurndal
Aug 1, 2018, 9:04:53 AM8/1/18
to
[snip]
LA36:
>
>The only thing you can do in OS/8 is to use it as a serial printer by modif=
yesterday that was built with PAL8-V9B, with a 1974 copyright date.
LA36:
>
>The only thing you can do in OS/8 is to use it as a serial printer by modif=
>ying the KL8E handler to use the protocol and say device 40/41.
Coincidentally, I just ran across a KL8E.LS listing (printed by PDP8+12 Line Printer Version 4)
yesterday that was built with PAL8-V9B, with a 1974 copyright date.
cjl
Aug 2, 2018, 1:39:23 AM8/2/18
to
cjl
Scott Lurndal
Aug 2, 2018, 1:47:33 PM8/2/18
to
I dug the listing out of a box (along with a MACRO-8 manual and a few
other things, like a HP-3000 SPL listing of the SOO (Son of Overlord) program.
This one
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/os8/os8.v3d/sources/system/dectapes/dectape4/kl8e.pa
is several years newer than the version on my listing...
cjl
Aug 2, 2018, 7:27:35 PM8/2/18
to
cjl
William Cattey
Aug 3, 2018, 12:54:46 AM8/3/18
to
I'm working with some sources labeled "OS/8 v3f" which I think someone cobbled together from the "OS/8 Unified Kit" which was OS/8 v3d, with the OS/8 V3d Device Extensions, and some other updates.
That set of sources has PAL8.PA 1-OCT-75 version 13A.
That version got a patch to fix a bug with EXPUNGE in the Feb/Mar 80 Digital Software News that brought it up to v13B.
-Bill
That set of sources has PAL8.PA 1-OCT-75 version 13A.
That version got a patch to fix a bug with EXPUNGE in the Feb/Mar 80 Digital Software News that brought it up to v13B.
-Bill
William Cattey
Aug 3, 2018, 1:14:12 AM8/3/18
to
Oops, you were asking about the KL8E driver.
The KL8E.PA in those sources is labeled as TTYVERSION E with changes for
OS/8 V3d and OS/78 V2.
The file has a copyright date into 1978.
The version from the V3d distribution DECtape images I have ALSO says it
is version E, but it makes no
mention of OS/78, and its copyright only extends to 1977.
A side by side comparison would have to be made to dig out the detailed
differences.
I noticed that at a certain point DEC got REALLY careless with version
management and source code control.
My "Build bootable RK05 images with validated OS/8 V3F stuff" project
proceeds slowly. Check out the branch of Warren Young's PiDP-8/i
repository:
https://tangentsoft.com/pidp8i/timeline?n=100&r=os8-v3f-extensions
That's where I'm doing my fiddling.
-Bill
The KL8E.PA in those sources is labeled as TTYVERSION E with changes for
OS/8 V3d and OS/78 V2.
The file has a copyright date into 1978.
The version from the V3d distribution DECtape images I have ALSO says it
is version E, but it makes no
mention of OS/78, and its copyright only extends to 1977.
A side by side comparison would have to be made to dig out the detailed
differences.
I noticed that at a certain point DEC got REALLY careless with version
management and source code control.
My "Build bootable RK05 images with validated OS/8 V3F stuff" project
proceeds slowly. Check out the branch of Warren Young's PiDP-8/i
repository:
https://tangentsoft.com/pidp8i/timeline?n=100&r=os8-v3f-extensions
That's where I'm doing my fiddling.
-Bill
0 new messages