Re: AMOS
Mike Roach
because there may be more interest, and better chance for a response to
my query.
TIME Magazine Person of the Year for 2006 Mike Roach
<never...@panix.com.invalid> wrote:
>TIME Magazine Person of the Year for 2006 Harris Newman
><hsne...@sdf.lonestar.org> wrote:
>
>>
>>Well, I don't exactly know if this is even semi-relevent to a pdp10 group,
>>but right after college I was hacking on some BBS's, and came across this
>>guy running an AMOS system which looked very much like tops-10. For grins
>>I just now typed in alpha micro and now there seems to be an open sourced
>>emulator with a container for the os at:
>>www.otterway.com/am100
>>
>>I tried it and sure enough it came up. The feel of the os is very simular
>>to tops-10...I read somewhere that it was based on borrowed code from DEC.
>
>The author (Dick Wilcox) was familiar with many OSs, including offerings
>from IBM and Honeywell in the 60's. He was also familiar with PDP-11
>architecture, which was very much like the AM-100 (the AM-100 used
>a remicrocoded LSI-11 chip set.) He borrowed look&feel from TOPS-10
>(device independence, PPNs, command language [script], and command
>syntax.) I think he did a previous similar OS for Hughes for the
>PDP-11. AFAICT he didn't borrow any actual code.
>
>Anyone here have access to the AMUS (Alpha Micro User's Society) library?
>--
>Ask your boss to reconsider -- it's so difficult to take "Go to hell"
>for an answer.
--
Definitions of hardware and software for dummies:
Hardware is what you kick;
Software is what you curse.
Cameron Kaiser
>Anyone here have access to the AMUS (Alpha Micro User's Society) library?
Jeff Kreider is still out there, but last time I asked him, he still
desired to keep the AMUS library open to (I presume former now) AMUS
members.
--
Cameron Kaiser * cka...@floodgap.com * posting with a Commodore 128
personal page: http://www.cameronkaiser.com/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
cjl
AMOS is the name of a [nearly working] minimal O/S for a PDP-8/e with
TD8E and one or two TU56 drives, 4K and a teletype. It was developed
in Australia by two young students circa 1973, albeit not copyrighted,
and was what today we would call "freeware" [and probably almost worth
the cost!] It was also known as simply "MOS" [likely standing for
Magnetic-tape Operating System] and I imagine the "A" added in front
stood for Australia.
My somewhat commercial P?S/8 [sold by Intersil under the name IFDOS]
configured for a pair of RX01/RX8E drives and at least 8K would
support the exact same hardware as AMOS except it would also require
the MR8E-C field 7 magnetic core ROM OR at least 8K memory as in the
RX01-based version's requirment.
IFDOS was sold as optional software for a PDP-8-compatible machine
based on the IM6100 and sold by Intersil as the Intercept I.
Compatible kits were also sold by Pacific CyberMetrix as the PCM-12
and PCM-12A. [All three machines are buss/board compatible.] The
RX01-compatible DSD-210 and an interface board for either the PDP-8/e
or the Intercept family was made available by Data Systems Design,
known for their third-party DEC-compatible stuff for the PDP-8 and
PDP-11. Any of these machines having at least 12K could also run OS/
8; memory consisted of 4K modules implemented with CMOS RAM and on-
board battery backup to preserve memory even when powered down [to
simulate core-equivalent capability]. All of this software could also
run [VERY SLOWLY] on DEC's VT-78, which was unaccountably running at
less than the normal speed for IM6100 all the others used.
cjl [AMOS has no connection to anyone named Andy Grove]
Mike Roach
<clasy...@gmail.com> wrote:
>Just to make everyone's day:
>
>AMOS is the name of a [nearly working] minimal O/S for a PDP-8/e with
>TD8E and one or two TU56 drives, 4K and a teletype. It was developed
>in Australia by two young students circa 1973, albeit not copyrighted,
>and was what today we would call "freeware" [and probably almost worth
>the cost!] It was also known as simply "MOS" [likely standing for
>Magnetic-tape Operating System] and I imagine the "A" added in front
>stood for Australia.
The "A" could stand for "A", as in "A Magtape Operating System".
However, the discussion refers to a different "AMOS"; the "Alpha
Microsystems Operating System". This was developed, as I said before,
to have the look and feel of a large scale timesharing operating
system. This OS began in 1976 on a system with a maximum memory of
64K and eventually moved to a series of machines based on the 680X0
microprocessors and supporting hundreds of users. This OS is still in
use though it is now running on an emulated environment on AMD based
server class machines and parts have been migrated to native code. Their
version of a Business Basic type language has also been migrated.
AFAIK the PDP-8 AMOS only ran on one machine for one user.
--
Resisting temptation is easier when you think you'll probably get
another chance later on.
cjl
> TIME Magazine Person of the Year for 2006 cjl
>
> >Just to make everyone's day:
>
> >AMOS is the name of a [nearly working] minimal O/S for a PDP-8/e with
> >TD8E and one or two TU56 drives, 4K and a teletype. It was developed
> >in Australia by two young students circa 1973, albeit not copyrighted,
> >and was what today we would call "freeware" [and probably almost worth
> >the cost!] It was also known as simply "MOS" [likely standing for
> >Magnetic-tape Operating System] and I imagine the "A" added in front
> >stood for Australia.
>
> The "A" could stand for "A", as in "A Magtape Operating System".
Or perhaps something less charitable :-) .
>
> However, the discussion refers to a different "AMOS"; the "Alpha
> Microsystems Operating System". This was developed, as I said before,
> to have the look and feel of a large scale timesharing operating
> system. This OS began in 1976 on a system with a maximum memory of
> 64K and eventually moved to a series of machines based on the 680X0
> microprocessors and supporting hundreds of users. This OS is still in
> use though it is now running on an emulated environment on AMD based
> server class machines and parts have been migrated to native code. Their
> version of a Business Basic type language has also been migrated.
>
> AFAIK the PDP-8 AMOS only ran on one machine for one user.
The one user part is absolutely true. That it even exactly "ran" is
debatable. [It was a marginal system at best and was abandoned; it
was for a too-small environment to be viable; I say this as one of the
few people who wrote a tiny operating system for SLIGHTLY more of a
machine than that. The real question is how did they come to have
such a system that wasn't capable of running anything beyond a
diagnostic software program? [I don't even know if they ever got
those diagnostics to run on the tape; I rather doubt it.] I can tell
you that DEC never sold any such system hardware with any software,
because literally, none of DEC's ever ran there. The closest is to
add in the MR-8EC ROM in, in which case my O/S does run, and there is
at least one DEC system that would as well. Did these people just
"aim too low" or was it true their machine just didn't have enough
capability?
jmfbahciv
It would be very interesting if it ever ran for two on the -8 :-).
/BAH
John Francis
>Mike Roach wrote:
>>
>> AFAIK the PDP-8 AMOS only ran on one machine for one user.
>
>It would be very interesting if it ever ran for two on the -8 :-).
The first PDP-8 I encountered was running a multi-user operating
system. (TSS-8, set up as a multi-client FOCAL configuration).
Mike Roach
<jo...@panix.com> wrote:
>In article <h1vlt...@news6.newsguy.com>, jmfbahciv <jmfbahciv@aol> wrote:
>>Mike Roach wrote:
>>>
>>> AFAIK the PDP-8 AMOS only ran on one machine for one user.
>>
>>It would be very interesting if it ever ran for two on the -8 :-).
Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
>The first PDP-8 I encountered was running a multi-user operating
>system. (TSS-8, set up as a multi-client FOCAL configuration).
There were other multi-user BASIC or FOCAL only implementations. TSS-8
also let you run a custom BASIC for timesharing. I don't know which was
worse, the PAL-D assembler or poor imitation of FORTRAN. You could also
run most anything else that could run in 4K, including LISP, though I
never used that version much. I never got to use ALGOL on TSS/8. IIRC
all my ALGOL and most of my LISP and PDP-8 assembler were done on a
PDP-10.
LISP was available for the AM-100 versions of AMOS since (I think)
version 0.3 (and certainly before 1.0) and UCSD PASCAL was translated
at a later time, though those implementations did not survive the
AMOS conversion to the 680x0. At some point I grafted on the AM-100
AlphaBASIC math package and assembly language subroutine calling
facility onto PASCAL for improved speed. It was so successful that
PASCAL and BASIC had the same floating point bugs! 8^O
Some maniac at Alpha Micro even used the AM-100 macro assembler to
create an 8080 (and perhaps Z-80) cross assembler that was never
released. Too bad; it could have come in handy (after conversion to the
680x0 version of the macro assembler) with the AM-330 serial card or
AM-338/339 RJE, each of which included a Z-80 and could run CP/M 2.2 and
VisiCalc! (I may have the details wrong here; the cross assembler may
well have been written for the 680x0 version to begin with.)
--
The Computer made me do it.
glen herrmannsfeldt
(snip)
< Some maniac at Alpha Micro even used the AM-100 macro assembler to
< create an 8080 (and perhaps Z-80) cross assembler that was never
< released. Too bad; it could have come in handy (after conversion to the
< 680x0 version of the macro assembler) with the AM-330 serial card or
< AM-338/339 RJE, each of which included a Z-80 and could run CP/M 2.2 and
< VisiCalc! (I may have the details wrong here; the cross assembler may
< well have been written for the 680x0 version to begin with.)
With a good macro assembler, it isn't hard to write macros to
assemble 8080 code, or most other 8-bit processors. I used to
use such macros with the IBM OS/360 assembler, and then, using
those as examples, wrote ones for the 6809. Most interesting
is the address arithmetic required to generate little endian
addresses.
-- glen
Mark Crispin
> Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
When I was an undergraduate, I wrote a kernel called Sys/8 that context
switched between multiple threads on a PDP-8/e that had any kind of clock
to invoke the scheduler. It was a simple round-robin scheduler; I forget
now if it even had the concept of a "runnable" vs. "non-runnable" thread.
I hoped to get a timesharing board so (1) I could have more memory
eventually, (2) could have memory protection (each thread would run in its
own field), and (3) could have hardware system calls (since it would add
user mode). That never happened, and I eventually shelved the project.
It's 34 years later, and I doubt that any copy of the source exists
anywhere any more.
> There were other multi-user BASIC or FOCAL only implementations. TSS-8
> also let you run a custom BASIC for timesharing.
There's a TSS/8 emulated disk for sim8.
A big disappointment when I got my sbc6120 was that it didn't have user
mode, and hence could not run TSS/8 (it has the single-user OS/8 instead).
As far as I can tell, Digital went to great efforts to make the world
forget that TSS/8 ever existed after c.1971. TSS/8 is described in the
1970 edition of Programming Languages but vanishes in the 1972 edition.
I never found out why.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
John Francis
Mike Roach <never...@panix.com.invalid> wrote:
>
>I never got to use ALGOL on TSS/8. IIRC all my ALGOL
My first job at DEC was working on DECsystem10 Algol-60,
specifically the runtime debugger (ALGDDT).
cjl
> On Thu, 25 Jun 2009, Mike Roach posted:
>
> > Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
>
> When I was an undergraduate, I wrote a kernel called Sys/8 that context
> switched between multiple threads on a PDP-8/e that had any kind of clock
> to invoke the scheduler. It was a simple round-robin scheduler; I forget
> now if it even had the concept of a "runnable" vs. "non-runnable" thread.
>
> I hoped to get a timesharing board so (1) I could have more memory
> eventually, (2) could have memory protection (each thread would run in its
> own field), and (3) could have hardware system calls (since it would add
> user mode). That never happened, and I eventually shelved the project.
> It's 34 years later, and I doubt that any copy of the source exists
> anywhere any more.
>
> > There were other multi-user BASIC or FOCAL only implementations. TSS-8
> > also let you run a custom BASIC for timesharing.
>
> There's a TSS/8 emulated disk for sim8.
>
> A big disappointment when I got my sbc6120 was that it didn't have user
> mode, and hence could not run TSS/8 (it has the single-user OS/8 instead).
> As far as I can tell, Digital went to great efforts to make the world
> forget that TSS/8 ever existed after c.1971. TSS/8 is described in the
> 1970 edition of Programming Languages but vanishes in the 1972 edition.
>
> I never found out why.
A lot of things changed:
1) When the PDP-8/e came out, the TS option is built-in and standard
as long as you have an extended memory controller card. [There are
configurations with only a ROM that need this, but most actually put
in some RAM!]
2) TSS/8 was totally forgettable. As the principle author of a
system that actually runs fairly effectively on a 4K PDP-8, I can tell
you that you cannot do much without more memory. On the other hand,
what I was able to do in 4K is surprising. But having all of the
overhead to simulate a 4K environment seems more than pointless.
3) Various 32K environment sharing systems came about, just not from
DEC. The notion that it was actually possible for programming not
subject to "not invented here" was just starting to sink in. And that
also includes third-party hardware for more reasonable prices and/or
better performance.
On these systems [such as ETOS], you could run anything you want, up
to 32K if you needed it. This in turn depended on having lots of
actual memory [or else not many users!]. Towards that end, DEC
invented the KT8A memory controller that is a superset that also
supports 4 x 32K using a DEC-standard memory as implemented in the
PDP-8/a box only.
Some of them went further, by avoiding DEC's limitations, such as
using CESI's memory boards that were static RAM [and ran faster than
DEC's] and were 128K each, using an alternate memory controller from
CESI that could use DEC's operating mode for DEC or their own memory,
or could be reconfigured to allow up to 512K 12-bit words [actually
more memory than a then-current IBM PC of 640K] allowing far more
users/system.
The protected environment simulates a 32K PDP-8/e capable of running
just about all software that a "real" stand-alone 8/e could run. Many
used OS/8, which is clearly light years ahead of TSS/8 stuff. And my
4K-minimum P?S/8 could run there as well; it is a seemless
environment, totally compatible as long as you don't delve into areas
you would ordinarily avoid on a time-sharing system. [You don't play
with the TS hardware, it does.]
So, TSS/8 was far more than dead and buried. DEC simply didn't have
any interest in going head to head with these people, who in turn did
compete with each other to do an even better job, etc.
Please note that effective PDP-8 software development and running of
most applicastions requires more memory than 4K. OS/8 requires a
minimum of 8K, and can use more. P?S/8 requires a minimum of 4K, but
arguably uses up to 32K more reasonably than OS/8.
Additionally, please note that this is not simply a matter of more
memory = merely runs faster. Without the memory, many programs
either do not work at all, crash trying, or the best writte of them
give graceful exist informing the user of not enough memory resources.
Large PDP-8 program development needs to include assembly language
development techniques. The prevailing assemblers simply cannot
assemble large programs unless there is typically something more than
16K and often 20K or 24K. [Note: trivial attempts to in essence make
a virtual 8K environment were all that was ever attempted in these 4K-
oriented systems; the sloth was unacceptable on such a limited
system. The notion of working with far-larger programs in an
environment created with analogous limitations is simply
preposterous.]
The P?S PAL assembler can run in 4K. However, the more options you
enable, the smaller the program size you can assemble unless you have
more memory. Once you get to 8K, the same thing applies, just that
the numbers that can be achieved rise somewhat. As more memory is
added on, until you get to 20K, limitations will apply that are
dependent on which assembler features you did/did not enable. And we
are not also speaking to the related matter of performance/time to
assemble binary, a factor that has to take second fiddle to merely
being able to do the job at all when you have less memory, etc. [OS/
8's assembler has a vaguely similar problem, except that there is less
esoteric management of available memory being performed; there aren't
mechanisms to turn off unused features; the memory is usually wasted
whether referenced or not; additionally, due to limitations of OS/8
itself, it is not possible to accomplish the same level of capability
unless you actually have 24K, not 20K. P?S PAL also supports cross-
assembly mode of LINC/LINC-8/PDP-12 LINC architecture assembly as a
dual assembler; the LINC is a totally different architecture, although
it is 12-bits [and it's a ones-complement 2K machine!]. Most people
wouldn't ever want or need LINC mode options unless they are expressly
writing code for one of those machine, etc.]
As an example, I developed an application-specific operating system
for a 32K PDP-8/e that ran 40 cooperative tasks. No preemptive
anything, no special hardware required, just equitable sharing of
available resources by good cooperation. Nothing whatsoever was
compatible with anything else, and it had a file structure tailored to
the needs of the application, including a balanced B-tree-shaped
directory with right-justified name sorting [as required by the
users].
The ability to assemble the source code of this system taxed the upper
limit of both the P?S/8 and OS/8 assemblers. In the end I had to
mechanically alter the source code with kludges that bastardized the
source code, because some "suit" in the company insisted that I make
the source code be DEC-compatible [I made heavy use of an extension
only found in P?S/8, not OS/8. By studying the source code, I was
able to make ugly changes that produced a source file set that could
be asssembled with DEC's stuff; however, as a result, if material
changes were made to the source code, it would have inefficiency creep
in predictably; the P?S/8 assembler has features that tend to
dynamically optimize the code, while the DEC software simply lacks the
feature. [Since they were paying me to do the changes, I told them
the consequences of the changes, and they insisted anyway!]
In any case, no other system could assemble this program. Even PAL10
cannot do it because PAL10 became obsolete, frozen in time to an
earlier and more naive notion of what PDP-8 code looked like, as
opposed to the realistic nature of what needed to be assembled.
[Note: The source files of P?S/8 and OS/8 itself can only be assembled
by these two assemblers I mentioned. Perhaps if someone is
interested, I can specify what is wrong with PAL10 in terms of
obsolescence; it's not that long a laundry list, but it is fatal as it
stands. All of us who developed both of these systems started with
PAL10, but we essentially "outgrew" it as we added in additional
features in both systems that made it viable to actually development
meaningful code.]
Since the limitations of TSS/8 were meaningless, all of the machines
past the PPD-8/a were designed to simply ignore it; attempting to use
it on slower-still systems simply makes no sense. And when personal
systems get that physically small, so does time-sharing as a concept.
We had "personal PDP-8 systems" well before we had "personal
computers" in the IBM PC sense. [And in some cases, in physically
size-comparable boxes.]
Simply put, TSS/8 didn't do anything useful for anyone, especially
given the choices, shopping around, not all DEC all the time.
cjl
Tim Radde
>
> 2) TSS/8 was totally forgettable. As the principle author of a
> system that actually runs fairly effectively on a 4K PDP-8, I can tell
> you that you cannot do much without more memory. On the other hand,
> what I was able to do in 4K is surprising. But having all of the
> overhead to simulate a 4K environment seems more than pointless.
>
>
> given the choices, shopping around, not all DEC all the time.
>
> cjl
I find I have to disagree with your first comment that TSS/8 was
useless.
Back in those days computers were still fairly expensive, especially
for
small colleges, and forget high schools. If it were not for TSS/8
running
at the local community college and providing connectivity to most of
the local (county) high schools I would probably never have gotten
exposed to computing. So you had a virtual 4k pdp-8. I found it
fascinating and could do quite a bit with it. It was pretty amazing
(I think)
what a small computer wiht 32k of core could support user-wise. I
believe
our system supported 12 to 16 users. Mostly over dial up modems.
But they were spread throughout the county and most of these schools
would never have had an type of computer program without TSS/8.
Well, it helped that Mass had some sort of program to help the
college defer some of it's costs for providing such service. But for
it's time I think TSS/8 was a good thing for what it did using the
little
it had.
Tim Radde
jmfbahciv
> TIME Magazine Person of the Year for 2006 John Francis
> <jo...@panix.com> wrote:
>
>> In article <h1vlt...@news6.newsguy.com>, jmfbahciv <jmfbahciv@aol> wrote:
>>> Mike Roach wrote:
>>>> AFAIK the PDP-8 AMOS only ran on one machine for one user.
>>> It would be very interesting if it ever ran for two on the -8 :-).
>
> Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
<grin> I was using the word "interesting" as it's used in the
Chinese curse. :-)
What was the "smallest" OS/8 configuration?
/BAH
Johnny Billquist
Minimum 8K words. And some sort of mass storage.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Mark Crispin
> used OS/8, which is clearly light years ahead of TSS/8 stuff.
I don't understand this comment, and I would appreciate clarification and
explanation.
Here's what I understand:
OS/8 is a program loader in a single-user environment, with a single
directory on each volume.
TSS/8 is a multi-user timesharing system with multiple user accounts and
directories.
I have had very little contact with TSS/8. It was surprised that an
environment that has a SYSTAT command doesn't have commands such as
DIRECT, TYPE, COPY, etc. that make life a lot more pleasant. But isn't
that fixable if you have the source to TSS/8?
I'll grant that, as a single-user system, it looks like OS/8 would be
quite a bit more pleasant to use because its command decoder has all the
nice commands. And since you are in exec mode, you have full access to
all the hardware and memory.
But OS/8 is not a timesharing system. There's no multitasking, no
scheduling, no user accounts, no separate directories (other than separate
volumes). If there is some way to make OS/8 be multi-user, I have not
found it.
It seems to me that, as an operating system, TSS/8 is quite a bit more
advanced. If OS/8 is a superior user environment (which I conceed that it
may be), it seems to me that it is more because the PDP-8 is inadequate
for timesharing and not because of technology.
Similarly, I don't think that many people would say that MS-DOS is light
years ahead of the NT kernel, or that EDDT is light years ahead of
TOPS-10.
cjl
Your response is out of time context for what I mentioned.
By the time that what I wrote applied, no one would care about time-
shared anything for the most part, other than for far larger systems.
The whole point is that you could have your own unshared machine. And
for a quite small audience, you could have time-shared versions of
that as well, which was a whole lot more than TSS/8 ever offered in
its useful lifetime, which had long ended at that point, unless you
swallowed the Koolaid of all DEC all the time.
> Tim Radde
cjl
cjl
> Mike Roach wrote:
> > TIME Magazine Person of the Year for 2006 John Francis
> > <jo...@panix.com> wrote:
>
> >>> Mike Roach wrote:
> >>>> AFAIK the PDP-8 AMOS only ran on one machine for one user.
> >>> It would be very interesting if it ever ran for two on the -8 :-).
>
> > Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
>
> <grin> I was using the word "interesting" as it's used in the
> Chinese curse. :-)
>
> What was the "smallest" OS/8 configuration?
I will take that question into all of the most relevant ways to answer
it.
Generally speaking, P?S/8 runs in 4K with a sufficently easy-to-
program storage device such as a TC01/08 DECtape controller and a
single DECtape TU55/56 drive. [TU56-H is a single drive; the "H"
stands for "half" of a standard pair.]
Generally speaking, OS/8 needs the same exact hardware, but requires
an extended memory controller and at least 4K additional memory,
making the minimum for OS/8 to be 8K.
However, that's a pretty large machine physically.
P?S/8 raises its memory requirement from 128 words resident to 1-1/8
Kwords should the system device be too feeble to support a 128 word
device handler. Thus, on other devices, P?S/8 requires a minimum of
8K. There are several in both categories of needing 128 words versus
needing 1156 words out of a minimum of 8192 words of available
memory. OS/8 raised its requirement to 12K but the system device
doesn't quite get the benefit of the resultant space increase implied
of going from 128 words to 256 words. And of cours, this is why a lot
of OS/8 devices have marginal quality handlers and of course why P?S/8
raises the requirement not from 128 to 256 but rather from 128 to
1156. To date, there has never been a relevant PDP-8 device P?S/8
cannot do an exemplary job in as much as 1156 words. I think the
largest practical one takes aroun 700 or so, but the 1156 is a good
upper limit. Contrast that with extremely kludged OS/8 handlers in
their not-quite 256 word environment, etc.
Given the above, and the fact that newer machines got smaller:
OS/8 can run on an RX01/02/03 or DSD-210 hooked up to a PDP-8/e/f/m to
essentially get you to a machine in a smaller space of essentially two
oversized breadboxes. The DECmate I makes that a little smaller. P?S/
8 and OS/8 both run on these machines, however, the machines can
easily have more memory, and all DECmates have 32K standard.
Thus, for that class of machines, OS/8 and P?S/8 both get more than
their minimum memory requirement typically [and in DECmates always get
the max of 32K] but hook up to physically smaller devices.
The DECmate II is quite a bit smaller, but for the ultimate in DEC-
produced systems, the tiny DECmate III and III+ are clearly the
ultimate in small:
1) Always 32K
2) A pair of RX50 or one drive of a TEAC FD-55GVR bastardized down to
acting no better than a half of an RX50 pair, except that it does
transfer 20% faster, and is inherently a better drive. The machine
supports two drives electrically, but there isn't enoug space in the
little box for the second drive! I make it work with a dual-drive
cable I made with the wires hanging out. There is actually some
software that needs the second drive, and they forgot that the DecMate
III+ only has one drive! [Note: Here is the embarassment: DECmate II
and DECmate III plus both support hard disks, standard in the III+ and
optional in the II. When they both have hard disks, they support a
"menu" layer on the hard disk called "Master Menu" and everything is
installed "under" it, although a few can be done more stand-alone [not
recommended and in some cases, not possible, notably for OS/278, a
DECmate-kludged and only partially functional version of OS/8 for
DECmates that can only be installed under Master Menu, unless you boot
to a diskette]. All DECmates II, III, and III+ support hardware
extensions to support CP/M-80; the DM II has an "APU" card and an
"XPU" card that also adds in an x86 chip as well. The III and III+
share support for an alternate card, software compatible with the APU
card of the DM II, but it's different hardware in the III family.
Anyway, on to the problem: In order to install CP/M-80 on any of the
three systems, it is necessary first to use both drives of the RX50,
even if installing it onto the hard disk, thus, it cannot be done on a
DM III+ as sold! The only software-only solution is to also have
another DM II machine with its APU card, build the system there using
the RX50 pair. After the fact, use Master Menu backup/restore to
create volume backups. Fortunately, this only involves the use of the
one drive all of the machines always have, and does not require the
drive not ever normally found in a DM III+ . A minor complication
note: Volumes created on DM II with the XPU card are not compatible
with other machines that have the APU card! Thus, if you have the
DECmate XPU card on the DM II you are SOL; they both must have the APU
card for this to work. But that's the only all-software-only way to
get past the problem; DEC goofed up!]
Anyway, I think you will be hard-pressed to beat that system in terms
of size:
1) Tiny VAX/DM III/DM III+ box. It was sold with a single diskette
and a 20 MB Seagate Disk [RD52?]
2) Standard DEC VT-220 keyboard with WPS markings standard, but you
could use a VT-220 or Pro or Rainbow cosmetics if you like.
3) Your choice of a VT-220-type monitor, same as all of those era
machines, in your choice of Amber, Green, or Blue-white phosphor. In
the specific case of adding in the obscure color graphics card on the
III or III+, you could optionally use instead the DEC color monitor
associated with a VT-240/241. Weirdly enough, on the DECmate II, the
same color monitor is optionally only supported as a second monitor,
the monochrome is required for all configurations. However, on the
Rainbow or any DM III or DM III+ with the graphics card, you can have
a one-monitor color machine.
Perhaps someone here can comment on the smallest viable configuration
of the newer Gizmo machines. However, I think they cannot beat the DM
III+ by much if at all. And you still would need a terminal hooked to
it!
cjl [I want to put a gizmo into a laptop dock!]
>
> /BAH
jmfbahciv
> jmfbahciv wrote:
>> Mike Roach wrote:
>>> TIME Magazine Person of the Year for 2006 John Francis
>>> <jo...@panix.com> wrote:
>>>
>>>> In article <h1vlt...@news6.newsguy.com>, jmfbahciv
>>>> <jmfbahciv@aol> wrote:
>>>>> Mike Roach wrote:
>>>>>> AFAIK the PDP-8 AMOS only ran on one machine for one user.
>>>>> It would be very interesting if it ever ran for two on the -8 :-).
>>>
>>> Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
>>
>> <grin> I was using the word "interesting" as it's used in the
>> Chinese curse. :-)
>>
>> What was the "smallest" OS/8 configuration?
>
> Minimum 8K words. And some sort of mass storage.
>
/BAH
cjl
> On Fri, 26 Jun 2009, cjl posted:
>
> > used OS/8, which is clearly light years ahead of TSS/8 stuff.
>
> I don't understand this comment, and I would appreciate clarification and
> explanation.
>
> Here's what I understand:
>
> OS/8 is a program loader in a single-user environment, with a single
> directory on each volume.
>
> TSS/8 is a multi-user timesharing system with multiple user accounts and
> directories.
>
> I have had very little contact with TSS/8. It was surprised that an
> environment that has a SYSTAT command doesn't have commands such as
> DIRECT, TYPE, COPY, etc. that make life a lot more pleasant. But isn't
> that fixable if you have the source to TSS/8?
>
> I'll grant that, as a single-user system, it looks like OS/8 would be
> quite a bit more pleasant to use because its command decoder has all the
> nice commands. And since you are in exec mode, you have full access to
> all the hardware and memory.
>
> But OS/8 is not a timesharing system. There's no multitasking, no
> scheduling, no user accounts, no separate directories (other than separate
> volumes). If there is some way to make OS/8 be multi-user, I have not
> found it.
Go re-read my post:
DEC became irrelevant to the potential customer base for TSS/8.
Third parties did all of what you claim are the TSS/8 advantages. Go
find out about ETOS and its ilk. Few of us had contact with any of
these systems due to the expense; we didn't run commercial operations
for time-sharing anything, and were quite content with one-user
systems ---- that we could literally touch with our own hands.
Why would I want to time-share a 4K machine when I can time-share a
32K machine environment for multiple users on a 512K PDP-8?
There were a few of these systems with some minor hardware kludges
required. Most of the kludge's actual "improvements" were hard-ware
lockin to prevent piracy. Smarter software from some of the others
did an adequate job thus conceptually obsoleting the extra hardware.
Part of what made it more viable was the Omnibus add-in card to
support up to 128K instead of 32K, and then the third-party card that
raised that up to 512K. Users were never physically swapped; all
their programs were always somewhere in memory, thus no swapping
disk. Generally, the usual habits of the purveyors of these systems
were to support from a running copy of OS/8, running on an RK8E/RK05
or better-still third-pary disks, some of which I partially developed
personally. I had a customer who also had the ETOS people as a
customer. All I had to do was create an environment "safe" for P?S/8
and OS/8; they did the rest as an upgrade to get away from the expense
and limitations of the RK8E/RK05. The RL01/02 was totally ignored due
to its feeble design. A few used the better DSD-240 [as I did for
some of my customers], but the stuff I developed [SCSI-based] was far
better, and became the recommend ETOS, etc. configuration as well.
The key point that is missing here is that DEC was starting to become
more and more irrelevant as third-party stuff was taking over on a DEC
base. Thie was true for all segments of DEC's market, but especially
felt in the PDP-8 word where, more and more, DEC was letting down the
12-bit world.
The PDP-8 hardware for the RL01/02 is a true abomination. Had the
attention to requirements been that miserable, OS/8 would literally
never have run on the RK8E! [And P?S/8 would, but only with
difficulty.]
As it stands, OS/8 on the RL01/02 is a horrible performer due to OS/
8's minimal memory capabilities for handler space being in direct
conflict with the RL series' excessive requirements of having pathetic
hardware requiring "hand-holding" software where competing designs did
all that in hardware. Had the hardware been even slightly "smarter"
this would have been acceptable, but radical things had to be done
just to get something that worked, albeit poorly. [Note: The RL disks
added in a modicum of more clever hardware that made it cheaper to
manufacture. However, that is a detail within the drive. The problem
is that the disk controller hardware for the PDP-8 was released as a
major step backwards as compared to the RK8E, which in turn was less
capable than the former RK08, but not as fatal in terms of overall
consequences. Compare this to the same general class DSD-240, which
had far more elegant controller design, some of which was stolen and
added into the later SCSI-based design I worked on, etc.]
Thus, witness all of the add-ons to give you better/cheaper/faster for
anything from terminals, printers, memory, disks, memory controllers,
CPUs, etc. and in a few cases, whole replacement systems. It became
quite profitable to sell stuff and make a profit off of DEC's
ineptitude; had they done a better job, these third-parties would have
not existed. Instead, all DEC did was send lawyers after people, such
as suing over the claims you had no right to manufacture products
compatible with a DEC buss design [VAX-BI anyone?]
cjl
cjl
> Johnny Billquist wrote:
> > jmfbahciv wrote:
> >> Mike Roach wrote:
> >>> TIME Magazine Person of the Year for 2006 John Francis
> >>> <jo...@panix.com> wrote:
>
> >>>> <jmfbahciv@aol> wrote:
> >>>>> Mike Roach wrote:
> >>>>>> AFAIK the PDP-8 AMOS only ran on one machine for one user.
> >>>>> It would be very interesting if it ever ran for two on the -8 :-).
>
> >>> Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
>
> >> <grin> I was using the word "interesting" as it's used in the
> >> Chinese curse. :-)
>
> >> What was the "smallest" OS/8 configuration?
>
> > Minimum 8K words. And some sort of mass storage.
>
> Would you have been able to fit an RP02 device driver in that?
No PDP-8 RP interface was ever made to my knowledge, and certainly
none sold.
>
> /BAH- Hide quoted text -
>
> - Show quoted text -
jmfbahciv
Sigh! DEC was in the hardware business. If you wrote software that
sold more DEC hardware, that was ideal.
/BAH
jmfbahciv
We didn't sell "systems" back then. I didn't ask about made nor
what DEC sold. I was wondering if 1. it was possible and 2. if
anybody who BOUGHT a PDP-8 managed to get disk software to run on it.
Lots of our customers bought an 8 (because they could afford that
gear) and wrote their own software to do whatever they needed to
get done. Lots of labs did this. IIRC, most used the 8 to capture
data and stream it to large machine such as a -10 or -11 or VAX.
I was simmply curious about storage on the 8. A DECtape wouldn't have
been as useful as a disk.
/BAH
cjl
The RL required a software seek register; this was the only
nonsensical hardware ever hooked to a PDP-8 where you had to do your
own hardware seeking on a disk! Even a DECtape makes more sense, and
that's a tape! Even an RX01 does its own seek!
There is no proper interrupt structure on that software seek regiter;
as I understand it, there needed to be a software kludge added to
RT-11 to handle the PDP-11 equivalent of the disaster.
The device was the only one ever added to the PDP-8 where you have to
handle software bad-blocks. All competitors either didn't have any or
had subsystems that mapped the errors. Some of the diagnostics I
wrote on the SCSI system were what eventually became known in the PC
world as "factory mode" stuff. This meant that only the diagnostic
ran "behind the curtain" while the handlers saw an error-free device.
I actually worked on a system where they never wrote PC versions of
the factory mode; the same disks ran on a PC SCSI controller; but only
after being properly prepared on the PDP-8 SCSI system.
Due to all of the inherent limitations of OS/8 coupled with the poor
design of the RL controller, the throughput was awful:
At best, you could only get passible performance using a two-way
interleave because it was literally impossible to transfer adjacent
sectors. [On competing disks, you got one-pass transfer, 1:1
interleave always worked, and transferred in hardware.] However, due
to major limitations made worse by OS/8, all of the following
additional degradation occurred:
1) 12-bit means you waste 1/4 of the disk. If you have the space to
bit-twiddle, it could use 8-bit mode [P?S/8 can do this because it has
the defined space]. However, once you give up 25% of the available
space, it is faster to transfer in 12-bit mode given the hardware
inferface, etc.
2) The two-way interleave assumes you transfer every sector, albeit
skipping the next at every point thus taking two passes around to get
all of them. However, OS/8 couldn't define the disk that way for a
variety of reasons. As such, instead the disk was divvied up into a
series of "wedges":
On an RL01 media, there were two large wedges and another one that was
half the size of the other one. On the RL02, this became 5 total
wedges where all wedges were the same size [except for the 1/2 sized
one on the RL01. In wedge units, an RL01 is 2.5 wedges and the RL02
is 5.0 wedges].
Standard diagnostics created bad block tables on the disk. OS/8
required a crutch utility that wrote out home records in 12-bit terms
in each wedge in terms of the local share of the bad blocks. All of
the bad block tables were written in inherently the same logical local
place, so the code was expecting to find the local table in the same
relative place. Logical blocks were calculated in terms of how many
members in the bad block table were at lower records than the desired
one, so you mapped into a slightly larger record number essentially
"skipping over" the bad blocks, etc.
Thus, Each part of a disk had to be a size OS/8 could access in the
wedge sense. A reserved record that could tell how many other records
were error-free had to tell the handler what to avoid in the rest of
the wedge. The maximum device size was the actual allocated size
minus the one record of the bad block table less a reasonable
expectation of the share of expected local bad records being skipped
over. [I think they allocated something like a couple dozen, so the
total logical size becomes about 25 or so less than a theoretical
wedge if you could depend on an error-free region, etc.
There is a major fundamental flaw here: There is no rationale
whatsoever for expecting that each of the sectors OS/8 depended on
actually being free of errors and reliable! Thus, you can lose all of
your data because the designated wedge mini-table record could itself
be flawed in the disk general sense! People found that the bad-table
record corrupted and their data became totally destroyed. Without the
table, it became impossible to determine how to map the rest of the
wedge, assuming of course that the *only* problem was the designated
local bad block record was blown; these disks tend to lose several at
once. Data recovery programs were never written, but would have had
to derive what the bad-block table would have been from the blown bad-
block record, then use the derived alternative to work with a
specially-constructed handler alternative to map through the
reconstructed table, etc.
[Remember, in OS/8, you have to handle *everything* in somewhat less
than 256 words, and its quite a bit less than that, especially in the
first half, which is probably closer to 90 than 128, not quite as bad
in the second 128.]
Thus, each wedge ran as an island unto itself. Thus, a transfer
typically did a localized two-way interleave across any wedge section
of a track. Then, the disk has to do a complete revolution to come
back for the other half of the sectors on that wedge. Then you move
on to the next track.
However, for your troubles, you only got one wedge worth of transfers
in two revolutions, yet you traversed two complete tracks of data;
most of the data wasn't yours! Thus, seeks happened more often than
were expected, because each track gives you 40% or 20% of what you
would expect on an equivalent disk track before resorting to having to
seek, all other things being equal and all transfers subject to a
performance-robbing two-way interleave, etc.
Truly miserable, and this doesn't even get into the issues of
reliability [a lot of people had basic reliability issues with it as
well.]
cjl
cjl
As time went on, the disks got a whole lot better for the PDP-8, and
more and more of them were made by third-parties; the DEC stuff got
worse and worse. The best stuff was the SCSI I worked on, which was
high-performance. The PDP-8 interface was elegant: You laid out a
SCSI command in PDP-8 memory, setup the DMA hardware to do a transfer
of the command into the intelligent controller via the DMA. Then the
intelligent controller carried out the command itself. If there was
any associated reads or writes from PPD-8 memory, it did that via DMA
as well. a data buffer could be defined anywhere in the up to 512K
space, and the maximum size on any one transfer was 32K in one shot!
Once the SCSI command finished, the PDP-8 had skip and interrupt
control over the results of a status register. The PDP-8 was not
distracted from any low-level housekeeping within the disk subsystem;
the intelligent controller did that part, etc. Once PDP-8-initiated
disk preparation was done, any disk handler [including OS/8 if you had
8K, P?S/8 if you had 4K; these are the minimums] could read/write any
part of the disk.
cjl
Johnny Billquist
> cjl wrote:
>> On Jun 27, 8:03 am, jmfbahciv <jmfbahciv@aol> wrote:
>>> Johnny Billquist wrote:
>>>> jmfbahciv wrote:
>>>>> Mike Roach wrote:
>>>>>> TIME Magazine Person of the Year for 2006 John Francis
>>>>>> <jo...@panix.com> wrote:
>>>>>>> In article <h1vltr21...@news6.newsguy.com>, jmfbahciv
>>>>>>> <jmfbahciv@aol> wrote:
>>>>>>>> Mike Roach wrote:
>>>>>>>>> AFAIK the PDP-8 AMOS only ran on one machine for one user.
>>>>>>>> It would be very interesting if it ever ran for two on the -8 :-).
>>>>>> Point taken; I don't think any 4K 8 ever ran multi-user anything ;^)
>>>>> <grin> I was using the word "interesting" as it's used in the
>>>>> Chinese curse. :-)
>>>>> What was the "smallest" OS/8 configuration?
>>>> Minimum 8K words. And some sort of mass storage.
>>> Would you have been able to fit an RP02 device driver in that?
>>
>> No PDP-8 RP interface was ever made to my knowledge, and certainly
>> none sold.
I didn't see Barbs question about the RP02, but to make an answer (which
cjl already did... :-) ) the answer is no.
DEC never interfaed the RP02 to a PDP-8.
The most obvious reason that all DEC software on a PDP-8 never could
reasonably use that large disks, and the interface is complex (in PDP-8
terms).
The absolutely most popular mass storage for the PDP-8 is the RK05. And
even that small disk (what is it? 3.5 megs or something) ends up looking
like two disks in OS/8, since disks in OS/8 can't be that large.
The RK05 is an excellent disk to play with. It's physically small, easy
to replace cartridges, and simple programming interface.
Eventually, DEC had to move to something more "modern", and that was the
RL01/RL02 disks, which were also usable on a PDP-8.
Before the RK05 you had "odd" things like the RF32 and DF<whatever>. (I
might remember things with bit parity errors here.)
Rather small disks anyway. So DECtape was really popular.
Johnny Billquist
1. Everything is possible.
2. Customers used other disks on a PDP-8. Never the RP02. Why should
they? DEC did sell other disk solutions for the PDP-8.
>> Lots of our customers bought an 8 (because they could afford that
>> gear) and wrote their own software to do whatever they needed to
>> get done. Lots of labs did this. IIRC, most used the 8 to capture
>> data and stream it to large machine such as a -10 or -11 or VAX.
>>
>> I was simmply curious about storage on the 8. A DECtape wouldn't have
>> been as useful as a disk.
>
> As time went on, the disks got a whole lot better for the PDP-8, and
> more and more of them were made by third-parties; the DEC stuff got
> worse and worse. The best stuff was the SCSI I worked on, which was
> high-performance. The PDP-8 interface was elegant: You laid out a
> SCSI command in PDP-8 memory, setup the DMA hardware to do a transfer
> of the command into the intelligent controller via the DMA. Then the
> intelligent controller carried out the command itself. If there was
> any associated reads or writes from PPD-8 memory, it did that via DMA
> as well. a data buffer could be defined anywhere in the up to 512K
> space, and the maximum size on any one transfer was 32K in one shot!
> Once the SCSI command finished, the PDP-8 had skip and interrupt
> control over the results of a status register. The PDP-8 was not
> distracted from any low-level housekeeping within the disk subsystem;
> the intelligent controller did that part, etc. Once PDP-8-initiated
> disk preparation was done, any disk handler [including OS/8 if you had
> 8K, P?S/8 if you had 4K; these are the minimums] could read/write any
> part of the disk.
Well, I don't totally agree with that.
The RK05 disk subsystem was very nice. Easy to use, enough feature to
keep you busy if you wanted to, and yet very simple if you didn't want to.
The disks are extremely reliable.
DECs replacement for the RK05 was the RL01 and RL02, which are more
complicated, but still pretty acceptable. And they appear to be rather
reliable as well. So I wouldn't complain at all about DECs offerings.
Mark Crispin
> Third parties did all of what you claim are the TSS/8 advantages. Go
> find out about ETOS and its ilk. Few of us had contact with any of
> these systems due to the expense; we didn't run commercial operations
> for time-sharing anything, and were quite content with one-user
> systems ---- that we could literally touch with our own hands.
There is very little information about ETOS. From what I can tell, in
addition to requiring user mode it also required a special board to
support registers for last jump or IOT. Also, it seems to be a multiple
user virtual machine system, in which each user gets what appears to be
his own dedicated OS/8 system.
The VM approach is basically to create, as much as possible, the
environment that would exist if there really were that many physical
machines.
Virtual machines are useful and interesting, but they aren't the same
thing as timesharing. I have little doubt that someone who expects the
experience of a standalone machine would find a virtual machine to be more
satisfying than timesharing.
However, what's significant about timesharing are the user interchange,
presence, messaging, collaboration, etc. facilities. Those of us who work
in distributed computing have spent the past 25 or so years in
reimplementing these facilities in personal computing, and we're still not
fully there yet. There are IETF working groups dedicated to solving
problems that were trivial even on TOPS-10.
These are two very different approaches.
And, as far as I can tell, there is no chance of running either TSS/8 or
ETOS on an sbc6120.
Rob Warnock
+---------------
| Mike Roach <never...@panix.com.invalid> wrote:
| >I never got to use ALGOL on TSS/8. IIRC all my ALGOL
| >[was] done on a PDP-10.
|
| My first job at DEC was working on DECsystem10 Algol-60,
| specifically the runtime debugger (ALGDDT).
Heh! Did you see my article here last summer about reverse-engineering
the APIs between the PDP-10 Algol compiler and ALGLIB, and between
ALGLIB & ALGOTS? ;-}
Newsgroups: alt.folklore.computers
Date: Fri, 18 Jul 2008 07:02:19 -0500
From: rp...@rpw3.org (Rob Warnock)
Subject: Re: CLIs and GUIs
Message-ID: <76KdnUnQVPPWGx3V...@speakeasy.net>
Fun stuff! ;-}
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
glen herrmannsfeldt
> Heh! Did you see my article here last summer about reverse-engineering
> the APIs between the PDP-10 Algol compiler and ALGLIB, and between
> ALGLIB & ALGOTS? ;-}
I remember using TOPS-10 ALGOL! I never looked at the
details of ALGLIB or ALGOTS, though. I do remember doing
things with FOROTS, including writing my own minimal version.
(I don't remember exactly what it did, but it wasn't much.)
-- glen
Johnny Billquist
> On Sat, 27 Jun 2009, cjl posted:
>> Third parties did all of what you claim are the TSS/8 advantages. Go
>> find out about ETOS and its ilk. Few of us had contact with any of
>> these systems due to the expense; we didn't run commercial operations
>> for time-sharing anything, and were quite content with one-user
>> systems ---- that we could literally touch with our own hands.
>
> There is very little information about ETOS. From what I can tell, in
> addition to requiring user mode it also required a special board to
> support registers for last jump or IOT. Also, it seems to be a multiple
> user virtual machine system, in which each user gets what appears to be
> his own dedicated OS/8 system.
As far as I remember, the hardware for ETOS managed the delayed IF
change, yes. I think it also managed DMA mapping.
> The VM approach is basically to create, as much as possible, the
> environment that would exist if there really were that many physical
> machines.
>
> Virtual machines are useful and interesting, but they aren't the same
> thing as timesharing. I have little doubt that someone who expects the
> experience of a standalone machine would find a virtual machine to be
> more satisfying than timesharing.
>
> However, what's significant about timesharing are the user interchange,
> presence, messaging, collaboration, etc. facilities. Those of us who
> work in distributed computing have spent the past 25 or so years in
> reimplementing these facilities in personal computing, and we're still
> not fully there yet. There are IETF working groups dedicated to solving
> problems that were trivial even on TOPS-10.
>
> These are two very different approaches.
>
> And, as far as I can tell, there is no chance of running either TSS/8 or
> ETOS on an sbc6120.
One does not exclude the other.
I don't know much about the sbc6120, but if it don't have user mode,
then you are basically screwer, and nothing can be done except for
cooperative timesharinng (by some definition of the word).
With user mode, you can do both VMs are timesharing. And if you look at
ftp://ftp.update.uu.se/pub/pdp8/multos8 you'll find a OS for the PDP8
which don't require any extra hardware, but which do requre user mode,
along with a clock, and which presents you with a virtual machine.
However, that virtual machine also gives you a few extra I/O
instructions, which allows you to communicate with other virtual
machines, and figure out that you really are a virtual machine, and so
on. Each virtual machine is a "job", and have a job number.
It's quite fun, and works just fine.
Every user gets his own PDP-8, and boots OS/8.
jmfbahciv
was the piece of runtime code that set up and did the buffered
mode I/O for FORTRAN programs (among other things).
/BAH
jmfbahciv
that wasn't what I wanted to know :-). I was curious if a customer
ever managed to this work.
<snip>
/BAH
cjl
> which don't require any extra hardware, but which do requre user mode,
> along with a clock, and which presents you with a virtual machine.
> However, that virtual machine also gives you a few extra I/O
> instructions, which allows you to communicate with other virtual
> machines, and figure out that you really are a virtual machine, and so
> on. Each virtual machine is a "job", and have a job number.
> It's quite fun, and works just fine.
> Every user gets his own PDP-8, and boots OS/8.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
>
> - Show quoted text -
I don't remember the name of all of the players, but I do know this:
1) It was not relevant to add non-DEC hardware to get anything you
needed to work properly. However, that meant it had to be in a PDP-8/
a box because the hardware would be the KT8A or possibly the CESI
replacement for it that was software incompatible, but could be
configured to up to 512Kwords of memory, which is more important. But
even the DEC card got you to 128K. With 512K, you could mostly forget
about swapping out users unless you truly had way too many of them.
The system whose name I forget, claimed that the reason for the card
was a rather minor matter:
The TSS/8 system does not support the normal stand-alone console,
instead using a single IOT to retrieve a character via a system trap.
This is far less overhead than painstakingly emulating each and every
failed attempt when KSF failed to actually get a character, only to
loop indefinitely, etc. Whichever system it was, they made the claim
that this problem was somehow "solved" via the add-in hardware. As
such, it became a hardware lockin to prevent copying.
The newer system had no such lockin, and embraced the KT8A or the CESI
card and DEC or better still, the CESI 128K memory boards. The
software problem was solved by better emulation. You just check to
see what the user code is attempting, and prevent it from running
until it would cause the KSF to skip, thus the code then became low-
overhead again, etc.
Thus, what you allude to would only make sense if somehow the machine
could somehow get more memory yet not be an -8/a; thus, there cannot
be any dependency on non-DEC hardware to do what the standard DEC
hardware did. However, I believe the locked-in system ran on a 32K
machine, and did a lot of swapping, claiming the need of the card as
constructively necessary, instead of contrivedly necessary, using the
thin excuse to cover the hidden copy-protection agenda. Due to lack
of memory and needing lots of swapping, this system was in essence too
much full of itself; why protect such an inferior product when better
stuff was available that performed far better without any special
hardware, other than a possible option to use available third-party
hardware to make it work even better.
cjl
Johnny Billquist
Ok. Obviously nobody can make a definitive answer to this, unless he
actually did do it.
But as far as I know, nobody did. And I can't see the reason why anyone
would have tried it.
It's not a good fit, and there were already good enough alternatives
from DEC to not need to do this.
I'm pretty sure it would have been much more expensive to try to attach
an RP02 to a PDP-8 than any other available solution, and the gains (in
form of more storage) just wouldn't have been a motivation. As I said -
even an RK05 is huge in PDP8 terms.
jmfbahciv
Because it was there :-). Lots of "kids" played.
> It's not a good fit, and there were already good enough alternatives
> from DEC to not need to do this.
> I'm pretty sure it would have been much more expensive to try to attach
> an RP02 to a PDP-8 than any other available solution, and the gains (in
> form of more storage) just wouldn't have been a motivation. As I said -
> even an RK05 is huge in PDP8 terms.
It was not my intention to claim this made sense to do. I was simply
curious. There were lots of work out there done by customers who
used pieces of our gear and anything else they could get their hands
on to do a specific task. It was fun to hear what these people
managed to get to work and what kinds of work they did.
/BAH
cjl
>
> - Show quoted text -
Just how big is an RP02 anyway? My PDP-8/a SCSI controller can be
hooked to a pair of Seagate ST-4096 disks for a total of 160 MB
storage on a PDP-8 that can have up to 512K words of 12-bit memory.
[The actual machine is one ST-4096 for 80 MB, and two 1.2 MB HD
diskettes using the same hardware as the diskettes for a PC-AT, only
using the better TEAC FD55GFR/GFV drives; the machine is a two-box
hybrid: There is a 40-slot PDP-8/e, except that the terminator is in
the front, and there is no memory or CPU in the box. In the rear-most
slot is the obscure BC-80C cable, which is what is usually designated
for use as what connects the "FPP-8/E" meaning an -8/a box with FPP8A
connected to an -8/e box. The other end goes to a 20-slot -8/a box,
in which is all of the usual -8/a stuff, including a pair of 16K core
stacks, the SCSI controller, and the -8/e processor with EAE, and of
course the second front panel. There is a slight restriction on the
front panels, never to set the semi-fatal combination of the IND[0]
and IND[1] bits on the Omnibus because then it .OR.s the displays
together. As long as you don't display I think that status and the
MQ, but only the AC on the rotary switch or equivalent on the other
panel, you can otherwise have both panels display whatever you want.
Of course either can start/stop or SW/boot from either panel, etc.
The machine also has a TC08P with a pair of TU56 pairs of DECtape
drives, RK8E with two RK05 drives and an RK05f, VT8E, KL8JA to a VT05
with the grey numeric kludge keys for pseudo-numeric pad support in
software used in COS, LA-180 printer, the modified LA-36 with the
"speedup" option that makes it print 4 times as fast and also does
APL-10 character mode, third-party FETCH and EXEC start panel, PC05
reader/punch, and a third-party magtape drive that supports 1600 PE
records on down [nine-track] and an inter-processor buffer to the
modified LINC-8 across the room. When everything is on, the -8 has
handler support for the LINCtapes on the LINC-8 [Note: This can be
turned inside out; the 4K P?S/8 system can copy to DECtapes as well as
LINCtapes across the same interface in reverse using the same
protocol!] Thus, this machine can be booted from around six or so
separately bootable devices. OS/8 cannot handle all of the devices
all at once, so there are multiple copies of BUILD.SV each somewhat
different so that they can indirectly talk to each other, etc. The SW
is implemented on the -8/a, and supports the SCSI, DECtape, RK8E, and
DF/RF all in the same ROM using a minimal keyboard input select. It
just barely fits! All of the non-LINC-8 stuff lives in three tall
cabinets; the interprocessor buffer physically is in the base of the
LINC-8. The -8/e box has the KA8E and KD8E to the TC08; the positive
buss in turn ends in the DW08A level converter; the negative buss
cables run across the room to the LINC-8; due to good design, the
linc-8 power status doesn't affect anything on the -8 and vice-versa
other than the interbuffer device itself, etc.
cjl
Johnny Billquist
If you say that you need n 8/a to get a timesharing system and/or a
virtual machine running on a PDP-8, that just isn't truye, Charles.
When you *do* need is the user mode bit, which all the Omnibus machines
have. When you turn on user mode, all IOTs, along with all instructions
involving HLT gets trapped. Thus, the software can solve all your
problems. However, it is not that efficient, which is why a hardware
solution such as used by ETOS, or the KT8A is so nice. Then you'll have
hardware to solve the ugly problem.
What MULTOS8 do, is give you a virtual machine, with as much memory as
you want (even if your actual machine have less memory). Well, okay, it
is limited to 32K, since it only plays a virtual PDP8 with the normal
memory extension, and not the KT8A style.
Obviously, only two fields needs to be in memory at once, for a process
to work. MULTOS8 itself require one additional field, resulting in a
system minimum requirements of three fields, I believe.
When a process do a CDF, the OS traps this, and checks what happens, and
pages in (if needed) the new field of the process, and then does a
proper CDF to that field before returning back to the process to
continue. Very simple.
The tricky part is CIF, which is delayed until the next JMP or JMS. For
this to work, MULTOS8 interprets all instructions after a CIF until the
next JMP/JMS. That's the only way to make it work, making execution
substantially slower at that point. So, for code to execute fast, you
shouldn't do a CIF followed by a lot of code before the next JMP/JMS.
Now, that is a rule you should follow anyway, since people might have a
hard time following what the code do if you place the CIF far from the jump.
Now, having covered this, it should be very obvious that it is possible
to actually have a virtual PDP8 running on a physical PDP8, with all the
memory aspects working as expected. (CIF and CDF both being IOTs, which
are trapped when in user mode.)
The next thing to deal with is I/O. MULTOS8 do this as well. Most
"normal" devices are known to MULTOS8, such as the console terminal, and
when a virtual machine do I/O to the console terminal, MULTOS8 instead
do the I/O towards the real terminal associated with that process.
In addition, MULTOS8 also implements some buffering, making it possible
to actually have better performance for I/O than plain OS/8 do. Output
is buffered, and TSF normally always skips, since the output data is
placed in the buffer, and then transmitted as soon as it can. On reads,
MULTOS8 actually detects the KSF; JMP .-1 loop, and if that is seen, the
process is instead suspended until data is available.
Devices which do DMA have MULTOS8 modify the field that is used for the
transfer to match the actual physical field by the process. Since all
this is done by IOTs, everything is intercepted by MULTOS8 anyway.
One special case exists. Mass storage devices. MULTOS8 sees those
accesses as well, but don't allow them through. When OS/8 boots, MULTOS8
inserts its own device drivers in the driver table of OS/8, which means
that you access mass storage through MULTOS8 always. Which is a good
thing. Each virtual machine has its own disk, which each user can play
with, just as in OS/8, but you can also read from other users disks, if
you want to, and MULTOS8 takes care of consistency between them.
And as a final twist, MULTOS8 also implements a few IOTs of its own, for
users to communicate with each other, and some other time sharing stuff.
Oh, and HLT is about the same as logging out of the system. :-)
And of course, MULTOS8 do preemtive scheduling between the different jobs.
(And I've probably been very sloppy with the terms here. Job - Process -
User. It's the same thing in MULTOS8.)
So, in the end, you can have both timesharing and virtual machines
implemented with a plain PDP-8, as long as it has the user mode feature.
Without that, you loose.
And all Omnibus machines have this, if they have more than 4K of memory,
since this is on the KM8E module.
> The TSS/8 system does not support the normal stand-alone console,
> instead using a single IOT to retrieve a character via a system trap.
> This is far less overhead than painstakingly emulating each and every
> failed attempt when KSF failed to actually get a character, only to
> loop indefinitely, etc. Whichever system it was, they made the claim
> that this problem was somehow "solved" via the add-in hardware. As
> such, it became a hardware lockin to prevent copying.
What TSS/8 do is by no means a definition of what *can* be done.
> The newer system had no such lockin, and embraced the KT8A or the CESI
> card and DEC or better still, the CESI 128K memory boards. The
> software problem was solved by better emulation. You just check to
> see what the user code is attempting, and prevent it from running
> until it would cause the KSF to skip, thus the code then became low-
> overhead again, etc.
The nice thing about the KT8A, unless my memory fails me, is that you
can set up a translation table for I/O devices. So, when enbled, if your
program is doing IOTs to one device, the KT8A can change that to another
device number, on the fly. Thus, the software don't need to deal with
it, which makes for faster systems.
But handling things like the console terminal isn't a big deal. The
problem with the CIF is what really hurts non-hardware solutions. Having
to emulate the instructions between a CIF and a jump is really slow
compared.
And the KT8A also have DMA remapping features, so that you don't have to
figure out what values are written to the device registers, and instead
you remap the fields at DMA time in hardware.
So, a disk might think it is writing data to field 1, but in reality it
might be field 4, because the KT8A remapped it. And the OS sets up that
map as a part of the context of the process.
> Thus, what you allude to would only make sense if somehow the machine
> could somehow get more memory yet not be an -8/a; thus, there cannot
> be any dependency on non-DEC hardware to do what the standard DEC
> hardware did. However, I believe the locked-in system ran on a 32K
> machine, and did a lot of swapping, claiming the need of the card as
> constructively necessary, instead of contrivedly necessary, using the
> thin excuse to cover the hidden copy-protection agenda. Due to lack
> of memory and needing lots of swapping, this system was in essence too
> much full of itself; why protect such an inferior product when better
> stuff was available that performed far better without any special
> hardware, other than a possible option to use available third-party
> hardware to make it work even better.
The ETOS solution basically addressed the same problem that the KT8A
did. Mainly the delayed action of CIF (which hurts the most), DMA
remapping, and also possibly IOT remapping.
The point is, that if you have IOT remapping, those IOT instructions
don't need to trap to the OS, thus lowering the load on the system as
well. So it's a double gain from a performance point of view, but it's
definitely not neccesary, and not *that* costly if you don't have the
hardware.
The fact that ETOS required this hardware was unfortunate from a point
of view, since it meant that few could use it, and I wonder if a single
system (or hardware) remains today. But from the manufacturers point of
view, it made sense. They wanted high performance, and some parts of
that needed extra hardware, which wasn't available at the time.
But, as I have already pointed out, you don't need these gadgets to
actually implement a time sharing system on a PDP8.
Johnny Billquist
Oh, in todays terms, the RP02 is tiny.
Unless my memory fails me, it's 20 MB.
But for a PDP8, back then... That was more than plenty. And the
controller (atleast for a PDP-11) was a whole 19" cabinet by itself.
And the RP02 didn't do 12-bit data. So, you would have quite a job to
interface it. Not sure if speed would have been a possible problem as well.
And the drive itself is also pretty big. Standalone dish washer type,
with top loading disk packs.
Kindof similar to RP04/05/06 in that regard, if I remember correctly
(gha! it's been soon thirty years since I played with RP02s, and they
were ancient technology then :-) ).
You have a nice system, Charles (but then again, we already knew that).
What I personally miss, is an FPP8A, and a KL8A. For the rest, I'm
happy. I have both a full 8/e, as well as everal 8/a systems, and cables
to expand the 8/e with an 8/a backplane. However, I don't have an 8/a
front panel on that machine.
RK05, RL02, TU10, TD8E, PC8E, RX8E and terminal lines to last me a
lifetime. And some other options in the machine as well, just for fun. :-)
I was pretty happy when I found the extensions to OS/8 to change device
drivers on the fly...
Mark Crispin
> I don't know much about the sbc6120, but if it don't have user mode, then you
> are basically screwer, and nothing can be done except for cooperative
> timesharinng (by some definition of the word).
I believe that is the case; the 6120 CPU apparently does not have user
mode although it does have extended memory. Presumably, the CINT, SINT,
CUF, and SUF instructions are no-ops.
On a PDP-8/e, 8/f, and 8/m, user mode is implemented by the KM8-E extended
memory board, but normally are disabled by jumper. I have a KM8-E and 12K
memory, but either it or the extended memory on my 8/f is not functioning
properly so I just have it running in 4K. I don't have any peripherals
for the 8/f anyway.
I would dearly love for someone to say that there is a way to do user mode
on the 6120 so that I can try bringing up one of the timesharing systems
on my sbc6120 (it does have a hard drive and runs OS/8).
glen herrmannsfeldt
> Are you sure you're thinking of FOROTS and not FORLIB? OTS
> was the piece of runtime code that set up and did the buffered
> mode I/O for FORTRAN programs (among other things).
The one that was in the high segment. I wanted to learn how
to make high segment code. It might be that it only did
the initialize and write to terminal so that I could
write out one thing.
-- glen
Johnny Billquist
> On Sun, 28 Jun 2009, Johnny Billquist posted:
>> I don't know much about the sbc6120, but if it don't have user mode,
>> then you are basically screwer, and nothing can be done except for
>> cooperative timesharinng (by some definition of the word).
>
> I believe that is the case; the 6120 CPU apparently does not have user
> mode although it does have extended memory. Presumably, the CINT, SINT,
> CUF, and SUF instructions are no-ops.
If so, then it's a real shame. I think I'll stick with my real PDP-8
systems for the time being...
cjl
Again, part of all of our problems has to do with defining era-
appropriate reasoning. This notion will come up in the other posts I
will answer next. When machines have been around this long, you have
to define the useful contest, etc.
I had heard about all sorts of projects with good intentions, few
actually being more than flakes with dreams. There was once someone
attempting to hook an IBM 360-class [2711 2714 I think are the IBM
model numbers] disk to a straight-8. They never got there; this
sounds like a comparable notion to what question was asked.
> Kindof similar to RP04/05/06 in that regard, if I remember correctly
> (gha! it's been soon thirty years since I played with RP02s, and they
> were ancient technology then :-) ).
>
> You have a nice system, Charles (but then again, we already knew that).
> What I personally miss, is an FPP8A, and a KL8A. For the rest, I'm
> happy. I have both a full 8/e, as well as everal 8/a systems, and cables
> to expand the 8/e with an 8/a backplane. However, I don't have an 8/a
> front panel on that machine.
I never quite got the ASCII front panel. The Omnibus supports
multiple front panels, as long as you never .OR. the indicator bits
together, which confuses the display.
> RK05, RL02, TU10, TD8E, PC8E, RX8E and terminal lines to last me a
> lifetime. And some other options in the machine as well, just for fun. :-)
I may bug you a bit regarding eventual support for the RL disks; I
have scrupulously avoided them! However, I actually have a large
stash of the RL media, mostly RL01: One of the goals is to get a
proper RL driver to get past the truly abominable support in OS/8's
limitations. [Again, not their "fault" in the short-sighted sense;
they go no help from the hardware people on what was arguably their
biggest need for assistance ever. However, the overall limitation of
OS/8 itself is always the root cause of the need; P?S/8 was always
light-years ahead on this point: An additional 1K is needed; an
additionall less than 128 more words is not always gonna work well, if
even at all.
When I get to it, a small problem that needs to be solved is to get an
RL01 system to work on the RL8A without having to set the RL01-
compatibility mode jumper, which apparently makes it then not work
with RL02 media. By carefully rewriting stuff, the need for the
jumper should go away, except perhaps for dealing with some old
binaries of diagnostic programs, which presumably could be patched to
be functional [a lot easier to patch a 4K binary than a handler!]. As
I understand it, the I/O to work with the software-controlled seek
register idiocy has a problem with setting correctly one extra bit
when the controller is talking to the RL01 media, because the values
simply don't exist on the RL01 drive, and thus it easily gets
confused, etc. Perhaps you can flesh out the details on that one,
etc. In any case, to my knowledge, none of the OS/8 could has solved
the problem, so thus you have to set the board jumper, etc.
I have additional stuff, just not hooked up. I have a complete
DECmate I with RX02, and somewhere floating around an RX8E card; it's
better to have the DSD interface, because that drive is more useful,
since it can format the media as well, etc.
The main DM II has the XPU w/512K, graphics card, and the HD interface
with a 20 MB disk. When reconfigured, it has been known to instead
have a second RX50 [one is standard] pair, and hang the disk cable out
to the disk mounted into an external box, but this makes it less
physically appealing when the monitor is mounted in the "ET head" mini-
stand. However, it has also been configured to have the RX78 board
[mutually exclusive to the HD controller] with the RX cable hanging
out the box, and sent through the Y-shaped cables associated with the
"pedestal" version of the RX02 as implemented optionally on a DECmate
I, used to drive a pair of RX drives. In fact, P?S/8 is the only
system that can boot to that configuration. [It requires a special
bootstrap I wrote that is a superset of all known RX boot code, and
you have to run that code from first booting to the RX50 and running
it from there, etc.]
The Intercept machine, when "liberated" from the "mothball dungeon"
will again become the rightful place for the DSD drive, and then
likely the RX01 [or 02] will be out back on the big machine; the other
one will stay with the DM I.
I have an additional collection of a bunch of DM II, III, and a single
DM III+ machine, which is more useful when you use two TEAC drives on
it, when sitting on the table, unless someone can create an alternate
package [slightly taller] to house them both, or alternatively: Use
the dual-drive from TEAC that supports one of the drives as 3.5". If
others can retrofit the DM II to use a pair of 3.5" instead of an
RX50, then this machine would be the go-between to allow RX50 to/from
3.5" 720K-type media as an alternative to RX50. It only can be done
on the DM III+ presently. 3.5" media is itself getting a bit hard to
find [I recently purchased 100 of them for various projects for about
$0.65US each including shipping], but far easier than looking for
MD1DD [with or without the RX50 suffix; irrelevant if you have a PC
that can run 22disk]
cjl [Don't get me started on the literally tons of other machines in
the basement of the dungeon!]
>
> I was pretty happy when I found the extensions to OS/8 to change device
> drivers on the fly...
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
cjl
There is a problem here of sloppy posting and presumption on the part
of the readership:
The objective of all of these commercial projects was profitability.
All of them *were* time-sharing commeercial systems, some with dial-up
support. Most had local multiple terminal support. Actually, there
really isn't much to the problems of getting a PDP-8 to do stuff like
that.
I personally wrote a 40-task PDP-8 system that ran in 32K. It is
multi-threaded and uses reentrant technoiques and disk caching. All
of the tasks are doing cooperative multi-tasking. In theory, all
could be hooked to terminals. In fact many were, but some were hooked
to printers, paper-tape punches, and some to paper tape readers. A
table defined the configuration of each job, etc.
The nitty-gritty problem comes down to virtualization of a stand-alone
system associated with each terminal, not a problem I was solving,
because of the absurd overhead for my application to foolishly use
something like OS/8. This was a truly stand-alone environment with
its own utilities, backup, crash recovery, and proprietary directory
structure, based on a balanced-binary tree structure; the internals of
the files themselves were doubly-linked so the directory could be
destroyed yet all files recovered during a stand-alone recovery
utility; the directory was for the multi-user tasking system, etc.
Once you want to virtualize a standalone system, you have to make all
of the details work. The sticky ones cause great overhead. Various
attempts were made to get it all to work, yet not crawl uselessly when
more than sparse usage was attempted, etc.
In the era [however brief it was], the original vendor of the system
for a 32K max PDP-8/e-based system used an RK8E/RK05 to swap up-to-32K
images of the allocated virtualized memory space for each user. On
this system, it was necessary to fake which field something was in.
When you allow a standard driver to work with faked memory-mapped data
fields, you have the disconnect problem of who should be allowed to
believe they are running truly on a stand-alone machine versus the
impracticality and overhead associated with that. This is a foolish
solution and naively written if so, since OS/8 does not expect the
drivers to have any form of compatibility, just functionality at the
driver level.
The other problem is mapping the IF to pretend it is what it is not,
without having to overly simulate the instruction set. In other
words, to trap only the problematic instructions without having to get
into high overhead waiting for the JMP or JMS after a pending IF
change. This can be handled quite well in better-grade software; they
chose to do it in hardware a net gain of performance coupled with a
poor objective because they were always faking everything in a max 32K
real memory environment. Thus, this system was justified, only
briefly for a few years, and as a result of proprietary hardware, was
locked in.
But then came the KT8A from DEC, and the ability to have 128K. Now
everyone could have sufficent means to allow 32K virtualized machines
onto separate terminals, and no need for proprietary hardware. Each
machine always had 32K, and it was real. The trap system setup which
32K "bank" was the object of the transfer. Thus, inherently less
overhead, and not justifying lock-in hardware. Thus, the successor
had a better system and no need to support their own hardware.
Then, the writers of that more-standard system optionally supported
third-party add-ons because they allowed 4 times 4 times 32K; that the
instructions are not KT8A compatible is irrelevant, since only the
trap monitor executes any of those instructions. Only the legal stuff
in 32K is relevant to each user, and all that is handled the same;
there is no pending IF change instruction problem to speak of,
although you needed a little bit of intelligence in the system, but
this was not a map in the same sense, etc.
Thus, the "better mousetrap" won out.
cjl
cjl
> cjl wrote:
> > On Jun 28, 3:46 am, Johnny Billquist <b...@softjar.se> wrote:
> >> Mark Crispin wrote:
> >>> The VM approach is basically to create, as much as possible, the
> >>> environment that would exist if there really were that many physical
> >>> machines.
> >>> Virtual machines are useful and interesting, but they aren't the same
> >>> thing as timesharing. I have little doubt that someone who expects the
> >>> experience of a standalone machine would find a virtual machine to be
> >>> more satisfying than timesharing.
> >>> However, what's significant about timesharing are the user interchange,
> >>> presence, messaging, collaboration, etc. facilities. Those of us who
> >>> work in distributed computing have spent the past 25 or so years in
> >>> reimplementing these facilities in personal computing, and we're still
> >>> not fully there yet. There are IETF working groups dedicated to solving
> >>> problems that were trivial even on TOPS-10.
> >>> These are two very different approaches.
> >>> And, as far as I can tell, there is no chance of running either TSS/8 or
> >>> ETOS on an sbc6120.
> >> One does not exclude the other.
> >> I don't know much about the sbc6120, but if it don't have user mode,
> >> then you are basically screwer, and nothing can be done except for
> >> cooperative timesharinng (by some definition of the word).
>
No, I am not. Again, as I posted above, context is what matters. The
best and most effective systems are not the same as theoreticals where
performance is being totally ignored. With the basics and pure
emulation, in slow motion "it works" etc. Look at the code in RTS8
[formerly SRT8] for an example of what "works", albeit barely.
The best, most profitable, commercially speaking, time-shared in the
dial-up virtual machine-looks-like-your-own-system sense, was the
goal, not theoreticals.
> When you *do* need is the user mode bit, which all the Omnibus machines
> have. When you turn on user mode, all IOTs, along with all instructions
> involving HLT gets trapped. Thus, the software can solve all your
> problems. However, it is not that efficient, which is why a hardware
> solution such as used by ETOS, or the KT8A is so nice. Then you'll have
> hardware to solve the ugly problem.
> What MULTOS8 do, is give you a virtual machine, with as much memory as
> you want (even if your actual machine have less memory). Well, okay, it
> is limited to 32K, since it only plays a virtual PDP8 with the normal
> memory extension, and not the KT8A style.
Again, toy versions compared to oriented towards commercial ventures.
>
> Obviously, only two fields needs to be in memory at once, for a process
> to work. MULTOS8 itself require one additional field, resulting in a
> system minimum requirements of three fields, I believe.
It's too much thinking like this that leads to today's seemingly
"powerful" PC systems with most of the power wasted in too many
software levels and excessive "virtualization" techniques, etc.
>
> When a process do a CDF, the OS traps this, and checks what happens, and
> pages in (if needed) the new field of the process, and then does a
> proper CDF to that field before returning back to the process to
> continue. Very simple.
> The tricky part is CIF, which is delayed until the next JMP or JMS. For
> this to work, MULTOS8 interprets all instructions after a CIF until the
> next JMP/JMS. That's the only way to make it work, making execution
> substantially slower at that point. So, for code to execute fast, you
> shouldn't do a CIF followed by a lot of code before the next JMP/JMS.
> Now, that is a rule you should follow anyway, since people might have a
> hard time following what the code do if you place the CIF far from the jump.
There are deliberate circumstances to do the opposite. In my
cooperative multi-tasking system, there is small but crucial code
where the foreground and background need to exchange information.
Thus, interrupts must be briefly off, and mimimize the window of no
interrupts at all costs. The easiest is to surround the code with IOF
and ION, but that isn't the best way to do it. If you need to merely
protect a single instruction, do an ION. It prevents an interrupt
until after precisely one more instruction of any nature. Better
still is to do an extraneous CIF to the current field. Then, all the
code is protected until the next JMP or JMS, which would in this case
be a natural part of the protected code, thus this is the shortest
interupts-off method if you are really counting machine cycles, etc.
However, in general, when used for the infrequent CIF to an actual
different field, most programs do it forthwith, and that is the best
practice anyway. So, if running well-written programs, using an ODT-
like instruction simulator for a brief period gets the job done, and
you don't need any proprietary hardware to do that, just the
compatible TS mode at all.
>
> Now, having covered this, it should be very obvious that it is possible
> to actually have a virtual PDP8 running on a physical PDP8, with all the
> memory aspects working as expected. (CIF and CDF both being IOTs, which
> are trapped when in user mode.)
Yes, and if you aren't really faking fields, each is quite low
overhead.
>
> The next thing to deal with is I/O. MULTOS8 do this as well. Most
> "normal" devices are known to MULTOS8, such as the console terminal, and
> when a virtual machine do I/O to the console terminal, MULTOS8 instead
> do the I/O towards the real terminal associated with that process.
> In addition, MULTOS8 also implements some buffering, making it possible
> to actually have better performance for I/O than plain OS/8 do. Output
> is buffered, and TSF normally always skips, since the output data is
> placed in the buffer, and then transmitted as soon as it can. On reads,
> MULTOS8 actually detects the KSF; JMP .-1 loop, and if that is seen, the
> process is instead suspended until data is available.
> Devices which do DMA have MULTOS8 modify the field that is used for the
> transfer to match the actual physical field by the process. Since all
> this is done by IOTs, everything is intercepted by MULTOS8 anyway.
Yes, proper design makes most of this not be too hard on overhead, but
that doesn't mean all of these attempts were all equally as good!
>
> One special case exists. Mass storage devices. MULTOS8 sees those
> accesses as well, but don't allow them through. When OS/8 boots, MULTOS8
> inserts its own device drivers in the driver table of OS/8, which means
> that you access mass storage through MULTOS8 always. Which is a good
> thing. Each virtual machine has its own disk, which each user can play
> with, just as in OS/8, but you can also read from other users disks, if
> you want to, and MULTOS8 takes care of consistency between them.
The best method is to have a standard image of a system tailored for
the trapped environment. What loads the overall system is
irrelevant. Towards that end, the "real" OS/8 or P?S/8 is just a
program loader. You can kick if all out, including putting back any
form of bootstrap convetion you want to maintain for whatever purpose
of bringing down the master application that's really running the
entire show. OS/8, or even P?S/8, is just in the way at that point.
You need to have compatible foreground tasks that are compatible with
the storage structures you want to support, whatever they may be;
there is no inherent advantage to anything over anything else, you
just support what you need. For most of these people, they just
wanted it to look like a standalone OS/8 system to each user. The TSS/
8 people had other objectives in this area. In theory, many systems'
disk structures can be supported, including the COS variations, WPS,
and P?S/8 all at the same time.
>
> And as a final twist, MULTOS8 also implements a few IOTs of its own, for
> users to communicate with each other, and some other time sharing stuff.
A cute frill, and absolutely not at all what the commercial purveyors
wanted to allow.
>
> Oh, and HLT is about the same as logging out of the system. :-)
An obvious frill!
>
> And of course, MULTOS8 do preemtive scheduling between the different jobs.
>
> (And I've probably been very sloppy with the terms here. Job - Process -
> User. It's the same thing in MULTOS8.)
>
> So, in the end, you can have both timesharing and virtual machines
> implemented with a plain PDP-8, as long as it has the user mode feature.
> Without that, you loose.
Losing is not the objective! But the newer systems took advantage of
newer hardware to do an even more effective job of simulating the same
environment. But TSS/8 wasn't trying as hard.
>
> And all Omnibus machines have this, if they have more than 4K of memory,
> since this is on the KM8E module.
And not materially more than the original PDP-8 could have,
optionally. [Technically, the KM8E is an option!]
>
> > The TSS/8 system does not support the normal stand-alone console,
> > instead using a single IOT to retrieve a character via a system trap.
> > This is far less overhead than painstakingly emulating each and every
> > failed attempt when KSF failed to actually get a character, only to
> > loop indefinitely, etc. Whichever system it was, they made the claim
> > that this problem was somehow "solved" via the add-in hardware. As
> > such, it became a hardware lockin to prevent copying.
>
> What TSS/8 do is by no means a definition of what *can* be done.
I agree, but this seems lost on some other posters.
>
> > The newer system had no such lockin, and embraced the KT8A or the CESI
> > card and DEC or better still, the CESI 128K memory boards. The
> > software problem was solved by better emulation. You just check to
> > see what the user code is attempting, and prevent it from running
> > until it would cause the KSF to skip, thus the code then became low-
> > overhead again, etc.
>
> The nice thing about the KT8A, unless my memory fails me, is that you
> can set up a translation table for I/O devices. So, when enbled, if your
> program is doing IOTs to one device, the KT8A can change that to another
> device number, on the fly. Thus, the software don't need to deal with
> it, which makes for faster systems.
No, what it does is translate the 32K bank extensions for the
compatibility of pre-existing DMA devices, so that for a static setup,
any 32K bank can run standard software. Of course a time-share trap
monitor has to setup these dynamically.
The CESI hardware doesn't support this at all. The intended function
is to use the SCSI hardware that supports 512K without help, as it is
newer. If that is your disk hardware unique, there is no need to
nursemaid devices not present. In return you get 512K memory, not
128K.
Thus, no need to play the game about mapping IF changes at all because
all of the fields stated are real; you still have to emulate a few
instructions, but they are not mapped, just deferred at the job
level. No actual memory handling OS/8 or P?s/8 would do need me
mapped at all, not in the 32K sense.
> But handling things like the console terminal isn't a big deal. The
> problem with the CIF is what really hurts non-hardware solutions. Having
> to emulate the instructions between a CIF and a jump is really slow
> compared.
No, not really; it shouldn't be that many instructions, as you pointed
out. The real overhead is when the fields are mapped to different
values within the same 32K. You are preventing what the shared-image
system would want to do "normally" by restricting it. In the bigger
memory systems, that's not a problem at all.
> And the KT8A also have DMA remapping features, so that you don't have to
> figure out what values are written to the device registers, and instead
> you remap the fields at DMA time in hardware.
No, incorrect. All it does is add in the bank support for the older
devices, not relevant at the user level at all. And invisible to a
system where the handlers work with "mythical" devices thast only
exist within the standard image used only by users, etc.
> So, a disk might think it is writing data to field 1, but in reality it
> might be field 4, because the KT8A remapped it. And the OS sets up that
> map as a part of the context of the process.
Not how it works. There is no mapping, just bank enhancement for the
older disks. All the overhead exists, if you allow it, and the
proprietary hardware made you dependent on it.
>
> > Thus, what you allude to would only make sense if somehow the machine
> > could somehow get more memory yet not be an -8/a; thus, there cannot
> > be any dependency on non-DEC hardware to do what the standard DEC
> > hardware did. However, I believe the locked-in system ran on a 32K
> > machine, and did a lot of swapping, claiming the need of the card as
> > constructively necessary, instead of contrivedly necessary, using the
> > thin excuse to cover the hidden copy-protection agenda. Due to lack
> > of memory and needing lots of swapping, this system was in essence too
> > much full of itself; why protect such an inferior product when better
> > stuff was available that performed far better without any special
> > hardware, other than a possible option to use available third-party
> > hardware to make it work even better.
>
> The ETOS solution basically addressed the same problem that the KT8A
> did.
No, wrong.
> Mainly the delayed action of CIF (which hurts the most), DMA
> remapping, and also possibly IOT remapping.
Already properly explained.
> The point is, that if you have IOT remapping, those IOT instructions
> don't need to trap to the OS, thus lowering the load on the system as
> well. So it's a double gain from a performance point of view, but it's
> definitely not neccesary, and not *that* costly if you don't have the
> hardware.
You wouldn't have posted that in light of my answers above.
>
> The fact that ETOS required this hardware was unfortunate from a point
> of view, since it meant that few could use it, and I wonder if a single
> system (or hardware) remains today. But from the manufacturers point of
> view, it made sense. They wanted high performance, and some parts of
> that needed extra hardware, which wasn't available at the time.
Yes, but that was a rather brief period, over when the KT8A made it
far easier to play with banks, not fields. Then totally buried when
the CESI hardware raised the ante to 512K words.
>
> But, as I have already pointed out, you don't need these gadgets to
> actually implement a time sharing system on a PDP8.
Yes, if you are not concerned with performance and lots of paying
customers!
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
cjl
cjl
> On Sun, 28 Jun 2009, Johnny Billquist posted:
>
> > I don't know much about the sbc6120, but if it don't have user mode, then you
> > are basically screwer, and nothing can be done except for cooperative
> > timesharinng (by some definition of the word).
>
> I believe that is the case; the 6120 CPU apparently does not have user
> mode although it does have extended memory. Presumably, the CINT, SINT,
> CUF, and SUF instructions are no-ops.
>
> On a PDP-8/e, 8/f, and 8/m, user mode is implemented by the KM8-E extended
> memory board, but normally are disabled by jumper. I have a KM8-E and 12K
> memory, but either it or the extended memory on my 8/f is not functioning
> properly so I just have it running in 4K. I don't have any peripherals
> for the 8/f anyway.
>
> I would dearly love for someone to say that there is a way to do user mode
> on the 6120 so that I can try bringing up one of the timesharing systems
> on my sbc6120 (it does have a hard drive and runs OS/8).
Definitely no. You need to understand the wonderful alternative
environment of the 6120:
There is a total of 64K, because there is the "alternate universe" of
the control-panel memory environment, as it was originally called.
The machine is a marginal superset of a 32K PDP-8/e with no possible
support for either EAE or the TS hardware. Instead, there are
instructions to make exec calls to the "other" 32K. It fields
interrupts in a strange way: Even if the PDP-8 mode halts, this mode
wakes up, and when it exits, the HLT still applies! Peripherals exist
that only cause CP interrupts. The hardware of the device 03 and 04
*could* have been totally emulated, and then the DM would be software-
compatible with the PDP-8. Instead, what they did was trap only the
*even* instructions, so what was emulated is an adaptation of the
limitation of the 6121 I/I chip. Thus, the following disaster is what
is there:
6030 In the -8/e, an extension to clear the keyboard flag
and not advance the reader. Solves the age-old problem of interrupts
and paper-tapes on an ASR-33.
But on the 6121 03/04 portion, it SETS the flag! [But since it is
trapped, it could be modified.]
6031 Skip on the keyboard flag set. Not so, here it also
CLEARS the flag! Say goodbye to all compatibility between exiting
applications and the O/S as in OS/8 and where P?S/8 was before the
radical modifications I made to get around this [and I am still not
happy about it, but...]
6032 Clear the flag essentially becomes a NOP because the
flag is already clear. It may clear the AC, but again, it also
depends on the trap emulation. It probably dismisses the latest
internally buffered character in the DECmate's trap environment in CP
memory; if executed, could get out of a hang condition necessitating
pulling the plug.
6033 I believe a NOP, but not a standard instruction to
worry about anyway.
6034 Should be a static read of the latest character with no
flag disturbance. I believe is uselessly emulated as read the next
character!
6035 Sets interrupt enable per AC[11] for this device. On the
-8/e, this is part of an optional baud-rate interface or a NOP. The
functionality was that 6045 did the same thing for both 03 and 04, but
on this it does it individually. remember, interrupt handling has
nothing to do with CP interrupt handling!
6036 Clear the flag, clear the AC and .OR. in the latest char
thus effectively clear the flag and load the AC. Also advances the
paper-tape if an ASR-33. You could have instead used 6034 and then
6030 on the -8/e with interrupts on. However, on the demended
DECmates, this is trapped to load the AC with the latest character, so
that the trap can do the next character. Failing to do 6032 or 6036
will hang the machine because 6031 cannot skip again. Why couldn't
they just trap all of the instructions instead of only the even ones?
6040 Set the flag; the only instruction the same as on the 8/e!
6041 skip on output flag set, But here it also CLEARS the
flag! This is less of a compatibility issue, but it still breaks
certain programs.
6042. Do nothing, perhaps clears the AC, should clear the flag,
but why bother.
6043; apparently a NOP
6044 fake an output operation, essentially compatible. But
there is no flag distinction.
6045 Load ineterrupt per AC[11] but on the -8/e for 03 and 04,
here for 04 only
6046 fake an output operation and clear the flag, but here the
flag is not used because 6041 clears it when it skips.
So, by excessive logical trapping, the ability to emulate a PDP-8 is
forever lost. It emulates what a more "bare" 6121 version would look
like. The DM I was about the same, except less buffered and prone to
losing characters in some instances. And a less-performing emulated
screen.
There is a firmware level to this, and a booted-up "slushware" level
to it. I disassembled the ROMs and the code is posted on the net,
somewhere in an area known to Roger Ivie.
The slushware is the contents of tracks 0, 78, 79 of any truly
bootable floppy, in a pre-O/S sense, even before attempting to
actually bootstrap the O/S portion of the same diskette. There is an
equivalent for a hard disk in terms of a reserved area the master menu
loading system keeps hands off of.
On the gizmo, all of this is solved [thankfully!] because a real PDP-8-
type 03/04 is respectfully implemented. This never was a CPU-specific
issue, just the stupidity of using the 6121 because it is a superset
of an *almost* compatible interface pair, and the misguided zeal to
emulate it, incompatibilities and all.
In any case, normal CP memory instructions replace the time-share
stuff. This allows a few nice calls to the CP memory for some minor
requests. I suspect the Gizmo used this mechanism to get sufficient
"internal" support so that writing an OS/8 handler became a more
trivial matter. All of this comes at the expense of interrupts
however, since CP code runs while all normal PDP-8 cycles don't even
happen, i.e., the PDP-8 side figuratively skips many thousands of
beats.
CP memory allows you to have a really snazzy debugger, and there is
one floating around, usualy known as CPODT, which lords over your
entire operating environment in the PDP-8 sense, trapping even a HLT
instruction.
If we had more TSS/8-like notions, essentially trapped and faked
instructions for all operations, this would be a good home for a new
totally incompatible system, and that assumes the ability to load the
CP memory accordingly. A DECmate is not gonna do that, especially
since part of is work is to simulate a VT-220-like terminal in CP
memory as well. But in theory, a properly roll-your-own machine with
good access to load-custom CP code could be a better system overall.
But this takes us even further afield from mainstream PDP-8 stuff.
cjl
John Francis
Rob Warnock <rp...@rpw3.org> wrote:
>John Francis <jo...@panix.com> wrote:
>+---------------
>| Mike Roach <never...@panix.com.invalid> wrote:
>| >I never got to use ALGOL on TSS/8. IIRC all my ALGOL
>| >[was] done on a PDP-10.
>|
>| My first job at DEC was working on DECsystem10 Algol-60,
>| specifically the runtime debugger (ALGDDT).
>+---------------
>
>Heh! Did you see my article here last summer about reverse-engineering
>the APIs between the PDP-10 Algol compiler and ALGLIB, and between
>ALGLIB & ALGOTS? ;-}
>
> Newsgroups: alt.folklore.computers
> Date: Fri, 18 Jul 2008 07:02:19 -0500
> From: rp...@rpw3.org (Rob Warnock)
> Subject: Re: CLIs and GUIs
> Message-ID: <76KdnUnQVPPWGx3V...@speakeasy.net>
>
>Fun stuff! ;-}
Missed that the first time round.
After fighting with the sorry excuse for a search capability in
Google Groups I did get to read (most of) the relevant thread.
A few additions, from my (somewhat fuzzy) recollection:
It was possible, from Algol-10, to call subroutines written to
the FORTRAN calling conventions. The converse was not true.
The Algol calling sequence was a little more complicated than
you mention; thunks were tri-part, not bi-part. One part was
simple - to return the value. But to store to a formal parameter
there were two steps; one to evaluate the address, and one to
store the actual value. This was necessary to satisfy the "order
of evaluation" rules specified in the Algol language definition.
When you have to deal with all the potential type conversions
between formal and actual parameters thunks could get to be
fun, indeed. IIRC some of that information was encoded in the
accumulator field of the XCT instruction used in some thunks.
cjl
another reason I don't care much about it. Let others emulate the
environment if they want to play that game. I want to enhance the
stand-alone enviroments most of them are apparently attempting to
emulate!
I don't care about what DEC did in their original limited attempts.
Third-parties did it better, and more usefully, often requiring
additional third-party hardware to help out, or just using some newer
available DEC PDP-8 stuff that also has other applications besides the
T/S trap consideration.
Much of what I have ever cared about is performance, not creating
multi-user illusions of mediocrity with graded-out performance in a
pecking order of attempts that at best are still inferior to what the
standard machine can do for one user, or in a few commercial
instances, what a stand-alone application system can deliver.
I have done several multi-user cooperative task systems over the
years. There are several standard guide-lines:
1) DEC's stuff is always the wrong approach as a base. Ask the
programmers who developed it, and you will always get the same
response: they wrote a development system, not something to run from,
unless you put up with the limitations needlessly imposed. Thus, be
prepared to write a stand-alone O/S for your application; you will
remove the predictable disappointments.
2) Most of the applications will need to be interrupt-driven. The
best the DEC stuff gets you is interrupt tolerance, and not always.
If you don't mind their file-system, the best it does is load your
program and get out of the way. However, it is often true their
filesystem is itself not up to the task, and their handlers are even
worse and less suited for a performance-oriented system.
Thus, the best way is to first start with an application's scope,
memory requirements, etc., then storage requirements, then design a
filesystem that suits the need of the application. Then create a
system loader that is compatible with the basics of the requirement,
but runs easily and with no hassles, but with interrupts off, that is
until it launches the image of the application. It is a waste of time
making that image part of the invented filesystem; just reserve system
blocks before the directory starts, and place the running interupt-
driven application code before that and after the bootstrap area, etc.
I wrote one system that addressed an entire RK05 as a logical unit.
The block-size was raised to logical quad-pages, or pairs of RK
records. This way, there was a 12-bit quantity of logical records per
block. The 4-page buffers were not unweildy within the application.
In another approach, the system call used two-page records, but
supported a more-than 12-bit record count to access the entire disk.
This was an easier approach to implement because you could do things
two pages at a time, and it could support larger devices if necessary.
At no point the P?S/8 or OS/8 scheme was useful at all at any level,
and their presence on a stand-alone system would be intrusive, counter-
productive, unnecesarry, unwelcome, and ultimately rejected out of
hand.
The development of the program, on the other hand, was best handled by
P?S PAL by using an advanced feature of P?S PAL, the "conditional"
literal:
In all three prevailing assemblers, you can use:
TAD (3)
or
TAD [3]
The first forces the current page usage while the second forcees a
page-zero usage.
In many situations, programmers either use a source library of common
"bag of tricks" subroutines or an explicit library [perhaps only kept
in their heads, or go back and look at other code in other programs,
whatever].
Regardless, it becomes obvious that certain literal constants will
tend to often repeat, To handle this, P?S PAL offers the
"conditional" literal:
TAD \3/
This becomes a page zero literal ONLY if it pre-exists on page zero,
else it becomes a current page literal. Thus, once the structure of
the overall program is forming, the "library" code fits in better
without forcing needless waste, etc.
By scutinizing the listing, it is possible to retrofit the code back
to what feeble OS/8 PAL8 demands. Basically, I had to remove all of
the conditional literals and replace with either current page literals
or used "Z" followed by the value in lieu of page-zero literals. The
code started with a lot of equates of the form
Z3= [3]
Z7= [7]
etc. to force all of the users of the symbol to get the same result.
By ordering the equates correctly, I proved that binary compatibility
had been achieved. Of course, the fact that you have taken a dynamic
optimization and made it a static one I could not convince the various
"suits" of the bad idea it was; they were more into the "what if I
were run over by a truck" routine, especially when I refused to
release the entire source code of P?S/8 to them, since my agreement
was for a truly modest one-off license fee allowing me to use it to
develop their code while I was just collecting a reasonable consulting
fee for doing the work and not much more, complete with completely
free maintenance of P?S/8 as I was also developing it at the time,
etc. They of course weren't prepared to pay me for owning the entire
system, so since they couldn't let them have it both ways, I made them
agree to pay me for the conversion time as extra work [which it was!],
and put them on notice that future versions of the code could become
sub-optimal as a result, and if it ran out of memory, they would have
to pay even more to study the listing to squeeze out the code, all
needlessly because I couldn't use a non-existent feature in the DEC
system they placed far too much faith in.
You can lead a horse to water, but...
cjl [Those who live by the mediocrity sword, die by the, etc.]
Johnny Billquist
> On Jun 28, 9:06 am, Johnny Billquist <b...@softjar.se> wrote:
>> If you say that you need n 8/a to get a timesharing system and/or a
>> virtual machine running on a PDP-8, that just isn't truye, Charles.
>
> No, I am not. Again, as I posted above, context is what matters. The
> best and most effective systems are not the same as theoreticals where
> performance is being totally ignored. With the basics and pure
> emulation, in slow motion "it works" etc. Look at the code in RTS8
> [formerly SRT8] for an example of what "works", albeit barely.
Ok. I must have misunderstood you. It looked like you were claiming that
you needed an 8/a to do this stuff.
Performance wise, a KT8A helps, but performance isn't that bad even
without one.
> The best, most profitable, commercially speaking, time-shared in the
> dial-up virtual machine-looks-like-your-own-system sense, was the
> goal, not theoreticals.
I'm not talking "theoreticals" here. MULTOS8 was a commercial product,
not a "theoretical".
But let's leave it at that. There isn't much point in arguing how good
or bad it performed. We both agree that hardware assistance makes for
better performance, but it's perfectly doable without.
>> When you *do* need is the user mode bit, which all the Omnibus machines
>> have. When you turn on user mode, all IOTs, along with all instructions
>> involving HLT gets trapped. Thus, the software can solve all your
>> problems. However, it is not that efficient, which is why a hardware
>> solution such as used by ETOS, or the KT8A is so nice. Then you'll have
>> hardware to solve the ugly problem.
>> What MULTOS8 do, is give you a virtual machine, with as much memory as
>> you want (even if your actual machine have less memory). Well, okay, it
>> is limited to 32K, since it only plays a virtual PDP8 with the normal
>> memory extension, and not the KT8A style.
>
> Again, toy versions compared to oriented towards commercial ventures.
That's a rather disparangly remark. I didn't write MULTOS8, but I have
used it. And it was a commercial product at one time.
So calling it a "toy" hardly seems correct.
>> When a process do a CDF, the OS traps this, and checks what happens, and
>> pages in (if needed) the new field of the process, and then does a
>> proper CDF to that field before returning back to the process to
>> continue. Very simple.
>> The tricky part is CIF, which is delayed until the next JMP or JMS. For
>> this to work, MULTOS8 interprets all instructions after a CIF until the
>> next JMP/JMS. That's the only way to make it work, making execution
>> substantially slower at that point. So, for code to execute fast, you
>> shouldn't do a CIF followed by a lot of code before the next JMP/JMS.
>> Now, that is a rule you should follow anyway, since people might have a
>> hard time following what the code do if you place the CIF far from the jump.
>
> There are deliberate circumstances to do the opposite. In my
> cooperative multi-tasking system, there is small but crucial code
> where the foreground and background need to exchange information.
> Thus, interrupts must be briefly off, and mimimize the window of no
> interrupts at all costs. The easiest is to surround the code with IOF
> and ION, but that isn't the best way to do it. If you need to merely
> protect a single instruction, do an ION. It prevents an interrupt
> until after precisely one more instruction of any nature. Better
> still is to do an extraneous CIF to the current field. Then, all the
> code is protected until the next JMP or JMS, which would in this case
> be a natural part of the protected code, thus this is the shortest
> interupts-off method if you are really counting machine cycles, etc.
Yes, if you allow users to have that kind of access in an uncontrolled
fahion. In a "normal" timesharing system, you don't want to allow that
kind of trickery. It is sortof potentially disruptive to all other users.
> However, in general, when used for the infrequent CIF to an actual
> different field, most programs do it forthwith, and that is the best
> practice anyway. So, if running well-written programs, using an ODT-
> like instruction simulator for a brief period gets the job done, and
> you don't need any proprietary hardware to do that, just the
> compatible TS mode at all.
Yes.
>> Now, having covered this, it should be very obvious that it is possible
>> to actually have a virtual PDP8 running on a physical PDP8, with all the
>> memory aspects working as expected. (CIF and CDF both being IOTs, which
>> are trapped when in user mode.)
>
> Yes, and if you aren't really faking fields, each is quite low
> overhead.
Every instruction having to be emulated instead of running itself is
very much slower. Instead of one instruction, each instruction will take
atleast 10, which means a 10 times slowdown.
But as long as you keep the distance short between the CIF and the jump,
you can probably live with it.
But, assuming you also have to page in memory once the field change
takes effect, then the overhead comes much more, I agree.
But that's the age old story of virtual memory. You are fooled into
believing there are more memory than there actually is. And at some
point, the system will have to go to some backing store in order to make
the illusion seem real.
Sure, you can design a system where you are not allowed to allocate more
memory than physically available. That's another design decision.
>> One special case exists. Mass storage devices. MULTOS8 sees those
>> accesses as well, but don't allow them through. When OS/8 boots, MULTOS8
>> inserts its own device drivers in the driver table of OS/8, which means
>> that you access mass storage through MULTOS8 always. Which is a good
>> thing. Each virtual machine has its own disk, which each user can play
>> with, just as in OS/8, but you can also read from other users disks, if
>> you want to, and MULTOS8 takes care of consistency between them.
>
> The best method is to have a standard image of a system tailored for
> the trapped environment. What loads the overall system is
> irrelevant. Towards that end, the "real" OS/8 or P?S/8 is just a
> program loader. You can kick if all out, including putting back any
> form of bootstrap convetion you want to maintain for whatever purpose
> of bringing down the master application that's really running the
> entire show. OS/8, or even P?S/8, is just in the way at that point.
> You need to have compatible foreground tasks that are compatible with
> the storage structures you want to support, whatever they may be;
> there is no inherent advantage to anything over anything else, you
> just support what you need. For most of these people, they just
> wanted it to look like a standalone OS/8 system to each user. The TSS/
> 8 people had other objectives in this area. In theory, many systems'
> disk structures can be supported, including the COS variations, WPS,
> and P?S/8 all at the same time.
Indeed. But that was not my point.
There is an additional problem lurking here. Each virtual OS/8 that is
running, is assuming that it is the sole user of mass storage. And OS/8
only allows one open file for writing at a time, on a device.
When you have several virtual OS/8 systems running, and they can access
shared resources, you can get into trouble. This was what I was talking
about, and which MULTOS8 helps with.
>> And as a final twist, MULTOS8 also implements a few IOTs of its own, for
>> users to communicate with each other, and some other time sharing stuff.
>
> A cute frill, and absolutely not at all what the commercial purveyors
> wanted to allow.
I'm not sure I follow here. The question from others (Mark Crispin
included) was about time sharing systems, as opposed to pure virtual
machines. As such, IOTs that actually give features and functionality
that are related to time sharing systems are rather essential.
If you want to talk about a specific customer (or customers), then
obviously they might have very different and specific requirements and
needs. But that don't mean that all have the same ones.
>> Oh, and HLT is about the same as logging out of the system. :-)
>
> An obvious frill!
Well. For a time sharing system, logging out is rather essential. Just
as logging in is. Back in the old days, you actually charged for the CPU
time used on time sharing systems. So loggin in and out served many
purposes, and was definitely not a "frill".
>> So, in the end, you can have both timesharing and virtual machines
>> implemented with a plain PDP-8, as long as it has the user mode feature.
>> Without that, you loose.
>
> Losing is not the objective! But the newer systems took advantage of
> newer hardware to do an even more effective job of simulating the same
> environment. But TSS/8 wasn't trying as hard.
Sadly I don't know much about TSS/8.
(I'm deleting all the stuff about the KT8A here. Suffice to say that I
was way off the bat. I totally misremember what the KT8A did, and how. I
read through the manual again now to refresh mysef, and noticed that
it's not that useful after all. You basically have to do the same thing
as with the KM8E, unless you want to limit your time sharing system to
only allocate memory that you know you have physical memory for.)
David Gesswein
Johnny Billquist <b...@softjar.se> wrote:
>
>The fact that ETOS required this hardware was unfortunate from a point
>of view, since it meant that few could use it, and I wonder if a single
>system (or hardware) remains today.
>
school. The board is in my online pdp-8 so you can run ETOS
on it. Easiest way is to use the shortcut menu and either pick operating
systems etos image or the games golf and football etos image.
http://www.pdp8online.com/run.shtml
Some information on the ETOS images
http://www.pdp8online.com/os/etos/index.shtml
Scans of the manuals are here
http://www.pdp8online.com/pdp8cgi/query_docs/query.pl?Search=etos&stype=Partial+Word&dtype=Document+Sets&submit=Submit+Query
Bernhard Baehr figured out how the ETOS board worked and supports it in his
PDP-8 emulator. SIMH used that information to support it also. This is the
information he figured out on the board
http://www.bernhard-baehr.de/pdp8e/TSC8-75_doc.html
Here are the images in SIMH format http://www.pdp8online.com/ftp/images/etos/
The company that developed it was still around when I contacted them a while
ago. They don't have anything left on ETOS so the source is probably lost.
David Gesswein
http://www.pdp8online.com/ -- Run an old computer with blinkenlights
Have any PDP-8 stuff you're willing to part with?
Dennis Ritchie
"Johnny Billquist" <b...@softjar.se> wrote in message
news:h25nc9$4si$2...@Tempo.Update.UU.SE...
...
> The RK05 disk subsystem was very nice. Easy to use, enough feature to keep
> you busy if you wanted to, and yet very simple if you didn't want to.
> The disks are extremely reliable.
>
> DECs replacement for the RK05 was the RL01 and RL02, which are more
> complicated, but still pretty acceptable. And they appear to be rather
> reliable as well. So I wouldn't complain at all about DECs offerings.
The RK05 (for the 11s anyway) was already a replacement for
the RK03, which was manufactured by Diablo at the time.
It was functionally compatible and used the same disks, but the Digital
version
had a bug--sometimes a preseek on the RK05 (start the
head moving without starting IO) would go to the wrong place
or the controller would hang (I forget). The RK03 was mechanically
somewhat better, I think.
Dennis
glen herrmannsfeldt
> I had heard about all sorts of projects with good intentions, few
> actually being more than flakes with dreams. There was once someone
> attempting to hook an IBM 360-class [2711 2714 I think are the IBM
> model numbers] disk to a straight-8. They never got there; this
> sounds like a comparable notion to what question was asked.
DASD are 23xx and 33xx. The disks you were thinking of
are 2311 and 2314. The 2314 is about 28 megabytes.
(20 surface, 200 cylinder, 7294 bytes/track.) I believe
the 2311 is about half that.
-- glen
cjl
> cjl wrote:
> > On Jun 28, 9:06 am, Johnny Billquist <b...@softjar.se> wrote:
> >> If you say that you need n 8/a to get a timesharing system and/or a
> >> virtual machine running on a PDP-8, that just isn't truye, Charles.
>
> > No, I am not. Again, as I posted above, context is what matters. The
> > best and most effective systems are not the same as theoreticals where
> > performance is being totally ignored. With the basics and pure
> > emulation, in slow motion "it works" etc. Look at the code in RTS8
> > [formerly SRT8] for an example of what "works", albeit barely.
>
> Ok. I must have misunderstood you. It looked like you were claiming that
> you needed an 8/a to do this stuff.
No, to do it far better than without! This was for competitive
systems of this ilk.
> Performance wise, a KT8A helps, but performance isn't that bad even
> without one.
The people who ran these systems to make a living totally disagreed
with that.
>
> > The best, most profitable, commercially speaking, time-shared in the
> > dial-up virtual machine-looks-like-your-own-system sense, was the
> > goal, not theoreticals.
>
> I'm not talking "theoreticals" here. MULTOS8 was a commercial product,
> not a "theoretical".
> But let's leave it at that. There isn't much point in arguing how good
> or bad it performed. We both agree that hardware assistance makes for
> better performance, but it's perfectly doable without.
Wrong, the key phrase here is "was" as you are quoted. It was
replaced in the marketplace, by at least two better competitors, one
of which got even more business than the other. Once the product has
lost a large segment of its market, it becomes more "theoretical"
since it just couldn't keep up; it never embraced the better hardware,
and by then it would be too late to compete.
>
> >> When you *do* need is the user mode bit, which all the Omnibus machines
> >> have. When you turn on user mode, all IOTs, along with all instructions
> >> involving HLT gets trapped. Thus, the software can solve all your
> >> problems. However, it is not that efficient, which is why a hardware
> >> solution such as used by ETOS, or the KT8A is so nice. Then you'll have
> >> hardware to solve the ugly problem.
> >> What MULTOS8 do, is give you a virtual machine, with as much memory as
> >> you want (even if your actual machine have less memory). Well, okay, it
> >> is limited to 32K, since it only plays a virtual PDP8 with the normal
> >> memory extension, and not the KT8A style.
>
> > Again, toy versions compared to oriented towards commercial ventures.
>
> That's a rather disparangly remark. I didn't write MULTOS8, but I have
> used it. And it was a commercial product at one time.
> So calling it a "toy" hardly seems correct.
No, it is quite accurate for the time-period as described. The
hardware to beat was the stuff I was peripherally connected with,
primarily the high-performance and larger disk subsystem. The disk
subsystem had the lowest possible PDP-8 overhead imaginable. The -8
asks for another machine to do the work for it, and is informed after-
the-fact that the DMA has already been accomplished. As perfect as it
gets for a variety of systems, including this one.
The support has nothing to do with OS/8, other than it has to
implement an OS/8-compatible implementation of a reentrant support
realtime version of a file-system, including the option for doing OS/8-
style directory and file stuff. But the point is that no actual OS/8
code does any of the work.
As I said, this has nothing to do with time-share option whatsoever.
For a cooperative-task system, you have to use it; it has no overhead
whatsoever; it's the shortest interrupt latency solution for multiple-
word routines that have to invade briefly the foreground/background
barriers out of necessity.
By its nature, all of these systems can be brought to their knees
using perverse small programs. These systems were meant to be
cooperative at some level. System usage logs would reveal abusers,
but only after-the-fact; they got kicked off and their companies
penalized for mischief, etc.
>
> > However, in general, when used for the infrequent CIF to an actual
> > different field, most programs do it forthwith, and that is the best
> > practice anyway. So, if running well-written programs, using an ODT-
> > like instruction simulator for a brief period gets the job done, and
> > you don't need any proprietary hardware to do that, just the
> > compatible TS mode at all.
>
> Yes.
>
> >> Now, having covered this, it should be very obvious that it is possible
> >> to actually have a virtual PDP8 running on a physical PDP8, with all the
> >> memory aspects working as expected. (CIF and CDF both being IOTs, which
> >> are trapped when in user mode.)
>
> > Yes, and if you aren't really faking fields, each is quite low
> > overhead.
>
> Every instruction having to be emulated instead of running itself is
> very much slower. Instead of one instruction, each instruction will take
> atleast 10, which means a 10 times slowdown.
> But as long as you keep the distance short between the CIF and the jump,
> you can probably live with it.
>
> But, assuming you also have to page in memory once the field change
> takes effect, then the overhead comes much more, I agree.
And the non-Toy systems made that be the norm, to avoid that overhead
unless overloaded with say, more than 15 or 16 users in 32K non-
swapped.
>
> But that's the age old story of virtual memory. You are fooled into
> believing there are more memory than there actually is. And at some
> point, the system will have to go to some backing store in order to make
> the illusion seem real.
Yes, but these are performance-oriented systems so the design is
realistic, not pie-in-the-sky at all.
>
> Sure, you can design a system where you are not allowed to allocate more
> memory than physically available. That's another design decision.
But when each virtual job gets 32K actual RAM, your point is moot.
The system does not emulate either the TS option nor hardware to
support the extra stuff beyond 32K. This is largely a brute-force
approach, but it does work.
You have just again proved my point. You cannot use "real" OS/8 to do
the job, so you provide "fake" handlers that eventually trap to multi-
tasking routines that handle all accesses from all of the jobs,
something OS/8 itself could never do. This is an obvious design point
when using the structure of a single-user-oriented filesystem in some
multi-user mode.
In my multi-terminal application system, the filesystem supported disk
caching and was designed for infinite simultaneous access. Each user
has to gain solid allocation access to do anything. At each record,
the file either grows if writing or reads in a latest record if
reading. If that job was indefinitely blocked, it wouldn't matter.
The directoty entries are performed at a higher priority than the file
creation, and the allocation is done at a still higher level, each
queued, etc. Even if it crashed, the worst thing is that the latest
file wasn't created into the directory. Since the system supports a
stand-alone data recovery procedure, the directory is abandoned and
created from scratch after finding the files themselves. Each file
record is doubly-linked so the directory, as complicated as it is, is
merely a shortcut to the data. Thus, it can be easily recreated by a
full search of the disk. The algorithm is sort-of as follows:
1) Zero the directory.
2) Search the entire disk, linearly. other than as modified below.
3) For every record traversed, indicate it in a temporary allocation
table.
4) As you find a valid record that is part of a file, check to see if
it a beginning of file. Otherwise, use the reverse link to find the
previous record; repeat until you find the beginning. Then, chain
through every record forward until you find an EOF link. If you don't
get there, this is not a file, map as searched, and moved on. If you
now have a complete and validated file, create a directory entry, then
move on, as linearly as possible, other than stepping over already
dealt-with records.
5) You are done when all the searchable records have been checked.
This took about 8 minutes on the worst-case full RK05, which was quite
acceptable. You had the option to first check to see if the directory
was accurate as stated, but it wasted time if it was corrupted. In
any case, either way you could find files that never made it to the
directory before, but were intact on the disk, which in theory could
have happened during a crash, etc.
The real-time application code was reentrant reusable. It required a
swapped-in page zero save area for each user. The nature of the
application was that it needed only 20 page zero words to store the
context. All subroutines use a software CDF MYFLD; CIF
THRFLD;PUSHJ;ADDRESS convention with a dedicated stack for each job.
[Note: The stack pointer was location 0017, so it saved 0017-about
0037 or so for each job. Auto-index registers were unimportant other
than for the stack pointer itself.
>
> >> And as a final twist, MULTOS8 also implements a few IOTs of its own, for
> >> users to communicate with each other, and some other time sharing stuff.
>
> > A cute frill, and absolutely not at all what the commercial purveyors
> > wanted to allow.
>
> I'm not sure I follow here. The question from others (Mark Crispin
> included) was about time sharing systems, as opposed to pure virtual
> machines. As such, IOTs that actually give features and functionality
> that are related to time sharing systems are rather essential.
No, the few that are obvious are not what I am addressing. This
needed the privacy of the simulation of personal machines per logged-
in user. If anything was needed, it could be added; just that the
customers tended to not need that; it was always a matter of doing the
fastest implementation. It was often a matter of just how much faster
than TSS/8 it was as a form of crude yardstick.
> If you want to talk about a specific customer (or customers), then
> obviously they might have very different and specific requirements and
> needs. But that don't mean that all have the same ones.
Your theoretical reasoning was not a factor to this customer segment.
They always offered custom mods, but it really was never a factor,
other than some more minimal stuff if at all.
>
> >> Oh, and HLT is about the same as logging out of the system. :-)
>
> > An obvious frill!
>
> Well. For a time sharing system, logging out is rather essential. Just
> as logging in is. Back in the old days, you actually charged for the CPU
> time used on time sharing systems. So loggin in and out served many
> purposes, and was definitely not a "frill".
No, logging out at all yes, that with a HLT is a frill. I think that
many people would want it NOT enabled, or at least only goes to a
prompt with default to not do so.
Whether or not you are aware of it, OS/8 has some internal HLT
operations! Go search the code if you want.
>
> >> So, in the end, you can have both timesharing and virtual machines
> >> implemented with a plain PDP-8, as long as it has the user mode feature.
> >> Without that, you loose.
>
> > Losing is not the objective! But the newer systems took advantage of
> > newer hardware to do an even more effective job of simulating the same
> > environment. But TSS/8 wasn't trying as hard.
>
> Sadly I don't know much about TSS/8.
It was used by these people as what to not do.
>
> (I'm deleting all the stuff about the KT8A here. Suffice to say that I
> was way off the bat. I totally misremember what the KT8A did, and how. I
> read through the manual again now to refresh mysef, and noticed that
> it's not that useful after all. You basically have to do the same thing
> as with the KM8E, unless you want to limit your time sharing system to
> only allocate memory that you know you have physical memory for.)
No, because you could have 128K physical memory, but the objective is
to only allocate 32K maximum because only the extended memory of 32K
is being made available, not the KM8E instructions or KT8A
instructions at all. Thus, you don't quite mean what you said.
cjl
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
cjl
wrote:
Thanks, yes, those are the numbers. I was confused because that was
part of my PDP-10 login and password way back when at SIT.
>
> -- glen
cjl
I cannot say about the -11 variant, but proper I/O [and not the
crippled OS/8 handler!] on the PDP-8 RK8E and RK05/05F is that
instruction time-out means you have to perform a reset and
recalibrate, and if that fails after a retry count times, give up.
Occasionally, it did take many seconds to recover, but it eventually
did. This was really obscure.
Due to poor overall design, OS/8 just doesn't have enough code space
to perform all of the operations. Thus, the code has limitations: Do
a function, wait essentially forever, check for errors if the flag
ever comes up, else hung; if any errors, do the worst-case-reset/
recalibrate for any error, even if a CRC data read error despite that
being orders of magnitude more likely. Also, excessively checks for
next sector even when not actually seeking in twice as many cases than
is proper due to lack of room for proper coding.
The pathetic thing is that many look to this handler as a "good"
handler in OS/8. Little do they know. It is true there are far
worse, but all is relative...
By better design, P?S/8 allows more than enough code space to handle
so far anything attempted. In round numbers, about 5-6 times as much
space as OS/8 painted itself into a corner, and that assumes the
largest configuration of the system. [known as "12K" instead of "8K"
which has nothing otherwise to do with how much main memory wsa
actually available.]
And yes, the P?S/8 handler is not prone to the above problem. In
fact, I had some psychoit behavior on some marginal disks where OS/8
could never read the data, while P?S/8 did, albeit with retry
difficulty.
The problem seems to be that if you actually get a CRC data read
error, and then extraneously perform a recalibrate/reset before trying
again, it can never actually read the data correctly. [Perhaps it's a
power supply overload problem?]. The P?S/8 utility would just retry
the read many times, focusing in on the data error as a single
transfer; if a multiple block transfer failed, it was replaced with a
onesy transfer of each member of the group, so you got focused retry
on the relevant disk record. Hopefully, eventually just reading and
not upsetting the disk arm, the read was finally good. Then move on
the the next.
Notice that without that refinement, it was highly likely that if the
buffer had multiple flaws near each other, it was also more likely to
fail; if one part fails 9 in ten times, and the same for another one
attempted in the same call, you will have far less likelihood of
getting the composite to complete without error if you take the call
as a group to be done over again as a group on any error, etc. You
would be lucky if it worked 1 in one hundred times by the example's
math.
cjl
glen herrmannsfeldt
>> DASD are 23xx and 33xx. ?The disks you were thinking of
>> are 2311 and 2314. ?The 2314 is about 28 megabytes.
>> (20 surface, 200 cylinder, 7294 bytes/track.) I believe
>> the 2311 is about half that.
> Thanks, yes, those are the numbers. I was confused because that was
> part of my PDP-10 login and password way back when at SIT.
The first digit is 2 for most S/360 equipment, 3 for S/370.
The second digit is 0 or 1 for CPUs, 3 for DASD, 4 for tape,
7 for telecom. There are others, but those are the more common ones.
The last two digits sort of increase with successive generations
or improvements.
The most common printer for S/360, the 1403, was left over from
the 1401 computer family. 2301 and 2303 are drums. The 2305
is the fixed head disk commonly used for paging on S/370 systems.
Successive generations of disks: 2314, 3330, 3350, 3370, 3380, 3390.
Tape drives went from 2400 to 3420 (two generations of nine-track),
to 3480 (cartridge tapes). 2701, 2702, and 2703 are dumb serial
line interface boxes, the 3705 is a fancier microprogrammed box.
The 2714 is a printing terminal using a selectric typewriter as
its print mechanism, and possibly connected to some DEC systems.
-- glen
Johnny Billquist
> On Jun 28, 9:38 pm, Johnny Billquist <b...@softjar.se> wrote:
>> cjl wrote:
>>> On Jun 28, 9:06 am, Johnny Billquist <b...@softjar.se> wrote:
>>>> If you say that you need n 8/a to get a timesharing system and/or a
>>>> virtual machine running on a PDP-8, that just isn't truye, Charles.
>>> No, I am not. Again, as I posted above, context is what matters. The
>>> best and most effective systems are not the same as theoreticals where
>>> performance is being totally ignored. With the basics and pure
>>> emulation, in slow motion "it works" etc. Look at the code in RTS8
>>> [formerly SRT8] for an example of what "works", albeit barely.
>> Ok. I must have misunderstood you. It looked like you were claiming that
>> you needed an 8/a to do this stuff.
>
> No, to do it far better than without! This was for competitive
> systems of this ilk.
The problem here is that you are talking about one specific system. A
system that I know nothing about. And you seem to think that that is the
yardstick we are comparing to.
You are. I am not. Different systems are designed with different goals,
leading to different compromises, and different results.
> By its nature, all of these systems can be brought to their knees
> using perverse small programs. These systems were meant to be
> cooperative at some level. System usage logs would reveal abusers,
> but only after-the-fact; they got kicked off and their companies
> penalized for mischief, etc.
Well, no. All the systems you seem to be talking about, yes. But not all
concievable systems. MULTOS8 (again, seems to be my favourite argument)
will not allow a user to lock others out. Always nice with a counter
example.
And as *I* seem to be talking about time sharing systems on a PDP8, and
not some special system for a specific customer, which designed a system
for some specific goals, in which you seem to talk a lot about
cooperative multitasking, we are obviously talking about different kinds
of systems here.
>> Sure, you can design a system where you are not allowed to allocate more
>> memory than physically available. That's another design decision.
>
> But when each virtual job gets 32K actual RAM, your point is moot.
> The system does not emulate either the TS option nor hardware to
> support the extra stuff beyond 32K. This is largely a brute-force
> approach, but it does work.
No, my point is not moot. If you allow each user to allocate 32K of
memory, and you have a KT8A to help you out, you can not have more than
three concurrent users (one bank must be left for your OS to live in,
which leaves less than 32K free in that bank).
So it's a design decision, and it have a real impact.
Well, that depends on what you define as OS/8 here. MULTOS8 places it's
own device driver in the system. But then again, I can write my own
device driver for OS/8 as well.
Does that make it not be OS/8 anymore?
What MULTOS8 do, is prevent several users creating files on the same
structure at the same time. So it still adheres to the OS/8 paradigm,
but extends upon it, so that it is still true even when in time sharing
mode.
It is usually not a restriction that any user suffers because of, since
each user have a "private" home disk, which is SYS:, and where most of
the playing of each user takes place.
And each user can simultaneously be writing to his SYS: without a problem.
>> If you want to talk about a specific customer (or customers), then
>> obviously they might have very different and specific requirements and
>> needs. But that don't mean that all have the same ones.
>
> Your theoretical reasoning was not a factor to this customer segment.
> They always offered custom mods, but it really was never a factor,
> other than some more minimal stuff if at all.
I don't understand why you call it a theoretical reasoning. There is
nothing theoretical about it at all. The software already exists.
>>>> Oh, and HLT is about the same as logging out of the system. :-)
>>> An obvious frill!
>> Well. For a time sharing system, logging out is rather essential. Just
>> as logging in is. Back in the old days, you actually charged for the CPU
>> time used on time sharing systems. So loggin in and out served many
>> purposes, and was definitely not a "frill".
>
> No, logging out at all yes, that with a HLT is a frill. I think that
> many people would want it NOT enabled, or at least only goes to a
> prompt with default to not do so.
>
> Whether or not you are aware of it, OS/8 has some internal HLT
> operations! Go search the code if you want.
Indeed. But executing a HLT means you won't be doing much more anyway.
A HLT is not something you normally would be executing anywhere, anyway.
So, having a HLT in the time shared system log out out is pretty reasonable.
>> (I'm deleting all the stuff about the KT8A here. Suffice to say that I
>> was way off the bat. I totally misremember what the KT8A did, and how. I
>> read through the manual again now to refresh mysef, and noticed that
>> it's not that useful after all. You basically have to do the same thing
>> as with the KM8E, unless you want to limit your time sharing system to
>> only allocate memory that you know you have physical memory for.)
>
> No, because you could have 128K physical memory, but the objective is
> to only allocate 32K maximum because only the extended memory of 32K
> is being made available, not the KM8E instructions or KT8A
> instructions at all. Thus, you don't quite mean what you said.
I definitely mean what I said.
Having a limit of max 3 concurrent processes is (in my mind) a rather
severe limitation.
Oh, it is definitely good enough for some situations, and some problems,
but it's definitely not good enough for a more general purpose time
sharing system, where you'd want a few more concurrent users.
MULTOS8 for instance can have up to 6 concurrent users.
Nico de Jong
"glen herrmannsfeldt" <g...@ugcs.caltech.edu> skrev i en meddelelse
news:h29nnp$d61$1...@naig.caltech.edu...
> In alt.sys.pdp8 cjl <clasy...@gmail.com> wrote:
> (snip, I wrote)
>
>>> DASD are 23xx and 33xx. ?The disks you were thinking of
>>> are 2311 and 2314. ?The 2314 is about 28 megabytes.
>>> (20 surface, 200 cylinder, 7294 bytes/track.) I believe
>>> the 2311 is about half that.
No, it is about 7.25 megabytes
Nico
Peter Flass
And the 1311 which used the same media was about 2MB. It was sectored
instead of CKD. The 1311 is a disk for 14xx systems.
Mike Ross
<g...@ugcs.caltech.edu> wrote:
>In alt.sys.pdp8 cjl <clasy...@gmail.com> wrote:
>(snip, I wrote)
>
>>> DASD are 23xx and 33xx. ?The disks you were thinking of
>>> are 2311 and 2314. ?The 2314 is about 28 megabytes.
>>> (20 surface, 200 cylinder, 7294 bytes/track.) I believe
>>> the 2311 is about half that.
>
>> Thanks, yes, those are the numbers. I was confused because that was
>> part of my PDP-10 login and password way back when at SIT.
>
>The first digit is 2 for most S/360 equipment, 3 for S/370.
>The second digit is 0 or 1 for CPUs, 3 for DASD, 4 for tape,
>7 for telecom. There are others, but those are the more common ones.
>The last two digits sort of increase with successive generations
>or improvements.
>
>The most common printer for S/360, the 1403, was left over from
>the 1401 computer family. 2301 and 2303 are drums. The 2305
>is the fixed head disk commonly used for paging on S/370 systems.
>Successive generations of disks: 2314, 3330, 3350, 3370, 3380, 3390.
You forgot the 3340; the *original* 'Winchester'. 30-30. And yes I'm *still*
looking for one!
>Tape drives went from 2400 to 3420 (two generations of nine-track),
And the compact top-loaders, 3410 and 3430.
>to 3480 (cartridge tapes). 2701, 2702, and 2703 are dumb serial
>line interface boxes, the 3705 is a fancier microprogrammed box.
>The 2714 is a printing terminal using a selectric typewriter as
>its print mechanism, and possibly connected to some DEC systems.
2741. With luck I'm picking up two of them on Wednesday!
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Mark Crispin
> You forgot the 3340; the *original* 'Winchester'. 30-30. And yes I'm *still*
> looking for one!
Go to any gun store. :)
For the benefit of those who didn't get the joke, .30-30 is a popular
caliber for deer hunting, and thus a Winchester .30-30 would be a typical
deer rifle.
TrailingEdgeTechnologies
> In alt.sys.pdp8 cjl <clasyst...@gmail.com> wrote:
> (snip, I wrote)
>
> >> DASD are 23xx and 33xx. ?The disks you were thinking of
> >> are 2311 and 2314. ?The 2314 is about 28 megabytes.
> >> (20 surface, 200 cylinder, 7294 bytes/track.) I believe
> >> the 2311 is about half that.
> > Thanks, yes, those are the numbers. �I was confused because that was
> > part of my PDP-10 login and password way back when at SIT.
>
> The first digit is 2 for most S/360 equipment, 3 for S/370.
> The second digit is 0 or 1 for CPUs, 3 for DASD, 4 for tape,
> 7 for telecom. �There are others, but those are the more common ones.
> The last two digits sort of increase with successive generations
> or improvements.
For first generation S/360, add second digit "2" for display terminals
(2250, 2260), second digit "8" for controllers (2821, 2841, 2848),
second digit "9" for RPQ devices.
The numbering system did not last long, e.g., the 3270 series,
which included both displays (3277) and printers (3284), but
were both local devices (3272) and telecommunications devices
(3271, 3275). When 8" diskettes came into use for data entry
the keying/verifier devices were 3741 and 3742, but they had
no telecommunications, which was handled by the 3747, while
attached to a S/370 for loading diskettes was a 3540.
>
> The most common printer for S/360, the 1403, was left over from
> the 1401 computer family. �2301 and 2303 are drums. �The 2305
> is the fixed head disk commonly used for paging on S/370 systems.
> Successive generations of disks: 2314, 3330, 3350, 3370, 3380, 3390.
> Tape drives went from 2400 to 3420 (two generations of nine-track),
> to 3480 (cartridge tapes). �2701, 2702, and 2703 are dumb serial
> line interface boxes, the 3705 is a fancier microprogrammed box.
> The 2714 is a printing terminal using a selectric typewriter as
> its print mechanism, and possibly connected to some DEC systems.
That was the 2741 (non-buffered) and 2740-1 and 2740-2 (buffered).
Bruce B. Reynolds, Trailing Edge Technologies, Glenside PA
TrailingEdgeTechnologies
> Nico de Jong wrote:
> > "glen herrmannsfeldt" <g...@ugcs.caltech.edu> skrev i en meddelelse
> >news:h29nnp$d61$1...@naig.caltech.edu...
> >> (snip, I wrote)
>
> >>>> DASD are 23xx and 33xx. ?The disks you were thinking of
> >>>> are 2311 and 2314. ?The 2314 is about 28 megabytes.
> >>>> (20 surface, 200 cylinder, 7294 bytes/track.) I believe
> >>>> the 2311 is about half that.
>
> > No, it is about 7.25 megabytes
>
> And the 1311 which used the same media was about 2MB. �It was sectored
> instead of CKD. �The 1311 is a disk for 14xx systems.
Media model number for 1311 and 2311 was 1316; 1311 disk also used
on 1620. There was also the 2310, used <inter alia> on the S/360-44,
the 1130, and (as the 1810) on the 1800. The cartridge of the 2310
was used by DEC as the form factor for the RK05 (to bring things full
circle in proper a.f.c. fashion).
TrailingEdgeTechnologies
> >Successive generations of disks: 2314, 3330, 3350, 3370, 3380, 3390.
>
> You forgot the 3340; the *original* 'Winchester'. 30-30. And yes I'm *still*
> looking for one!
The media for the 3330 was model 3333.
And the dismountable HDA for the 3340 was the 3348.
I'm having a senior moment as to the model number for
the media for the 2314/2319.
When the "Piccolo" drive (64MB) was developed, it
became the 3310 for S/370s and 4300s, the 4963 for
Series/1s, and the internal drive for S/34, S38, and
the 5520, and I believe the drive for the 8100s.
glen herrmannsfeldt
(snip, I wrote)
>> 2701, 2702, and 2703 are dumb serial
>>line interface boxes, the 3705 is a fancier microprogrammed box.
>>The 2714 is a printing terminal using a selectric typewriter as
>>its print mechanism, and possibly connected to some DEC systems.
> 2741. With luck I'm picking up two of them on Wednesday!
I must have typed too fast. Where did you find them?
-- glen
Charlie Gibbs
<39acff13-1702-4266...@d10g2000vbm.googlegroups.com>,
bbrey...@aol.com (TrailingEdgeTechnologies) writes:
> On Jun 29, 2:42�am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>> The first digit is 2 for most S/360 equipment, 3 for S/370.
>> The second digit is 0 or 1 for CPUs, 3 for DASD, 4 for tape,
>> 7 for telecom. �There are others, but those are the more common ones.
>> The last two digits sort of increase with successive generations
>> or improvements.
>
> For first generation S/360, add second digit "2" for display terminals
> (2250, 2260), second digit "8" for controllers (2821, 2841, 2848),
> second digit "9" for RPQ devices.
Don't forget 5 for card equipment (e.g. the 2501 card reader and
2540 read/punch).
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
glen herrmannsfeldt
(snip, someone wrote)
>> For first generation S/360, add second digit "2" for display terminals
>> (2250, 2260), second digit "8" for controllers (2821, 2841, 2848),
>> second digit "9" for RPQ devices.
> Don't forget 5 for card equipment (e.g. the 2501 card reader and
> 2540 read/punch).
That is what I was forgetting. That is, that there should be
something with the 5 there. It does get confusing sometimes,
with leftovers, such as the 1403, keeping the old number.
Then there is the 3850 mass storage subsystem that doesn't
seem to fit in the number system.
http://en.wikipedia.org/wiki/IBM_3850
Also the 3800 printer.
A large list if numbers and devices is in:
http://en.wikipedia.org/wiki/List_of_IBM_products
-- glen
Peter Flass
I believe they were used on a number of non-IBM systems. At a time when
the most common terminal was still a KSR-33, they were faster and
offered full letter-quality printing.
Rob Warnock
+---------------
| TrailingEdgeTechnologies wrote:
| > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
| >> The 2714 is a printing terminal using a selectric typewriter as
| >> its print mechanism, and possibly connected to some DEC systems.
| >
| > That was the 2741 (non-buffered) and 2740-1 and 2740-2 (buffered).
|
| I believe they were used on a number of non-IBM systems. At a time
| when the most common terminal was still a KSR-33, they were faster
| and offered full letter-quality printing.
DCA[1] supported the IBM 2741 on its "SMARTmux" terminal networking
system (along with the usual ASCII terminals) which could front-end
PDP-10s, PDP-11s [and -20's & VAXen with PDP-11 front ends], and
IBM 360/370 systems[2]. Bells Labs bought a large configuration
from us to use on their PDP-10s in Murray Hill(?), largely for
document preparation with RUNOFF.
At 14.1 char/s [using RS-232 at 134.5 Baud, start bit + 6 data
bits + parity bit + 1.5 stop bits], the IBM 2741 was only slightly
faster than the 10 char/s KSR-33 [20 mA current at 110 Baud, 7 data
bits + parity (or mark)], but the quality was *MUCH* greater, since
as Glen noted it used a real IBM Selectric typewriter as its base.
But that same base caused some "interesting" problems with using it
as a terminal on a PDP-10. For one thing, the 2741 is half-duplex,
not full-duplex as most PDP-10 terminals were. For another, like the
3270 block-mode terminals the keyboard "locked" (physically, in the
case of the 2741!) from the time you hit a carriage-return until the
host sent an "unlock" code. You could also send a partial line (and
lock the keyboard) with the "Attention Key", which was also the only
way to unlock the keyboard if the host failed to. [E.g., to interrupt
a runaway program you needed to hit Attention, wait until the keyboard
unlocked, hit Attention again (IIRC), wait until it locked the keyboard,
typed "_" & backspaced over it, then unlocked the keyboard again, and
then type "c" followed by Attention once more to send the ^C.]
We spent a *lot* of effort making our 2741-to-ASCII conversion work
as "right" as possible with such inherently non-line-oriented programs
as DDT & TECO, e.g., letting you type only "123/" (no <CR>!) and then
recognizing that the host was about to output something, locking the
keyboard, outputting the data, and then unlocking the keyboard again.
And don't even *ask* about TECO and ESC & ^U & ^O!! [^C covered above.]
We handled them, even made them *almost* convenient for experienced
users, but the internals of getting that right were *UG*lee!
[Yes, DEC also had a 2741-to-ASCII module for the DC76... but ours
worked *much* better, IOHO!! ;-} ]
-Rob
[1] Digital Communications Associates in Atlanta circa 1971-85,
not to be confused with the U.S. Defense Communications Agency.
[2] Via either discrete serial ports ["milking machine" mode] or via
an Auscom channel adapter plus our own code that emulated an IBM
2701 Communications Controller with Type III Telegraph Adapter
(better known as an RS-232 async serial port!!).
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock
| >Heh! Did you see my article here last summer about reverse-engineering
| >the APIs between the PDP-10 Algol compiler and ALGLIB, and between
| >ALGLIB & ALGOTS? ;-}
| > Newsgroups: alt.folklore.computers
| > Date: Fri, 18 Jul 2008 07:02:19 -0500
| > From: rp...@rpw3.org (Rob Warnock)
| > Subject: Re: CLIs and GUIs
| > Message-ID: <76KdnUnQVPPWGx3V...@speakeasy.net>
| Missed that the first time round.
| The Algol calling sequence was a little more complicated than
+---------------
Aha! That explains something I never figured out at the time! ;-}
+---------------
| When you have to deal with all the potential type conversions
| between formal and actual parameters thunks could get to be
| fun, indeed. IIRC some of that information was encoded in the
| accumulator field of the XCT instruction used in some thunks.
+---------------
Plus, as I forgot to mention last time, ALGOL-10 used Iliffe vectors
<http://en.wikipedia.org/wiki/Iliffe_vector> for array storage, and
made *very* good use of the PDP-10 pointer indexing+indirection
capabilities. Quoting myself yet again[1]:
...made array addressing almost trivial -- no multiply
instructions (which were slow) were needed whatsoever.
For, say, a three-dimensional array, if A, B, & C were already
in the proper registers, then "FOO[A,B,C] := FOO[A,B,C] + 1"
could be done in *one* instruction!! (No joke.)
What, you don't believe me? ;-} Here's the code:
MOVE T1,A ; Load up the array indices
MOVE T2,B
MOVE T3,C
AOS @FOO(T1) ; Increment FOO[A,B,C] (and don't skip).
-Rob
[1] Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 09 Mar 2007 07:18:03 -0600
From: rp...@rpw3.org (Rob Warnock)
Subject: Re: The Perfect Computer - 36 bits?
Message-ID: <xoWdnZz3fssWw2zY...@speakeasy.net>
Dennis Ritchie
"Rob Warnock" <rp...@rpw3.org> wrote in message
news:opmdnSeADbso5NTX...@speakeasy.net...
...
> DCA[1] supported the IBM 2741 on its "SMARTmux" terminal networking
> system (along with the usual ASCII terminals) which could front-end
> PDP-10s, PDP-11s [and -20's & VAXen with PDP-11 front ends], and
> IBM 360/370 systems[2]. Bells Labs bought a large configuration
> from us to use on their PDP-10s in Murray Hill(?), largely for
> document preparation with RUNOFF.
It wasn't Bell Labs in MH. I don't think there was ever a PDP-10 here.
Western Electric's ERC in Princeton was a PDP-10 shop though,
an conceivably the Piscataway operation, though they mostly
worked on front-ending job entry for IBM and Univac mainframes.
However their document-processing was troff.
We did make 2741s and their ilk work on Unix here, at least for
output--I don't think we ever bothered with input.
Dennis
cjl
> cjl wrote:
> > On Jun 28, 9:38 pm, Johnny Billquist <b...@softjar.se> wrote:
> >> cjl wrote:
> >>> On Jun 28, 9:06 am, Johnny Billquist <b...@softjar.se> wrote:
> >>>> If you say that you need n 8/a to get a timesharing system and/or a
> >>>> virtual machine running on a PDP-8, that just isn't truye, Charles.
> >>> No, I am not. Again, as I posted above, context is what matters. The
> >>> best and most effective systems are not the same as theoreticals where
> >>> performance is being totally ignored. With the basics and pure
> >>> emulation, in slow motion "it works" etc. Look at the code in RTS8
> >>> [formerly SRT8] for an example of what "works", albeit barely.
> >> Ok. I must have misunderstood you. It looked like you were claiming that
> >> you needed an 8/a to do this stuff.
>
> > No, to do it far better than without! This was for competitive
> > systems of this ilk.
JB: Over the years you have repeatedly made it abundantly clear you
do not understand my points, and your responses just go off into a
tangent as you try to evade what I said instead of asking for
clarification. I'll cut through all of this part real quickly.
Emphasizing:
As I already stated, the context of all of my points are time-era-
specific. I am not entertaining any form of notion of discussion what
might be good, bad, or anywhere in between. By your own admission,
you have no information to go on, just some largely irrelevant
experience with one of the oldest of these, and none whatsoever with
the newer ones, as such that is at the least ignorant, and you should
defer a bit more to soneone else's experience, not what you have
stumbled on, and somewhat recently at that.
Here, in talking points form, is all everyone needs to know:
1) The first attempt at a system such as this was written for rather
primitive and expensive hardware, namely TSS/8. There never were all
that many customers due to the expense.
2) As the years went on, it became abudantly clear that in order for
anything useful to be developed, the products had to be a commercial
success, else it would be largely abandoned.
3) DEC did indeed abandon this market. There are various forces at
work as to why:
a) It became largely pointless to even bother creating a time-share
system that made each user pretend to have a personal ASR-33 teletype-
based PDP-8 system with the sloth of time-sharing. Instead, PDP-8
systems became largely available to many people who wanted to have
them where they needed them. Time-sharing systems became largely
pointless.
b) Those who wanted to pretend to be on a machine via such a limited
vantage point, instead went to more powerful machines. This was
inevitable.
c) PDP-8 systems became clearly more useful if they had features a
time-share version is hopelessly outclassed by. A console terminal
limited by era-specific modems became a joke. It would be years
before we had commonly available decent-speed dial-up modems while
local terminals on the PDP-8 became faster; a modem would be much more
than a major bottle-neck.
d) DEC became irrelevant; your example of MULTOS8 just proves that.
Employees of DEC too close to TSS/8 had no contact with the
competitive market, and usually couldn't grasp the influence of forces
beyond DEC [a company that, just like many others, was infected with
"not invented here" syndrome, a factor that also led to them not
embracing P?S/8, despite it being offered to them not once, but twice,
and the "charge" was to make an academic donation, something they had
already done once, on a limited basis, and worse, were suckered into
doing to less-qualified others who contributed far less to anything
DEC would ever care about, however were represented by various silver-
tongued snake-oil types who basically overloaded DEC's limited
budgetary resources for this marginal purpose. [Companies perform
write-offs, etc.]
e) MULTOS8 was part of a tiny commercial market where each sale
represented a lot of money; there would be fierce competition between
a small number of players. Each system sold to the customer best
convinced that what they had was the best available. The actual
nature of this is the common "leap-frog" effect as still-better
products become available.
f) I was only peripherally connected to the one that became the clear
winner. My participation was to aid in producing a far higher-
performance product than had been available, and that includes fast
transfer speed, large-block transfers, and large size. These are key
features that make the difference when writing such a system.
g) The best of the best was to not be stuck with the all-DEC solution
that was mediocre and then inferior as the better-still hardware came
along, and only the winner supported it, partially because you had to
be a portion of the small circle of companies I was part of that
designed all of the relevant parts.
For example, the DEC 128K solution involved using slow PDP-8/a RAM
that was prone to unreliable timing because the Omnibus allows this
mediocre memory when you use the mediocre PDP-8/a CPU. Once you use
the PDP-8/e faster CPU, this memory is not allowed, and instead you
have to use the more cumbersome core-stacks, which would fill up your
-8/a box with lotsa core stacks just to get to 128K and it was
expensive. [My own machine has two of these for 32K, and I like the
fact that it is core, so it maintains contents, etc.]
The CESI memory was static-RAM without stall, thus it made the -8/a
CPU run at full-speed, just as the Core memory did. Better still, it
was 128K on a single board. Better still, using the CESI controller,
you got 512K support, which was the key feature that made this system
stand apart from all of the previous ones. There was a lock-in: You
had to use the CESI SCSI card to get the system to support more than
128K, but in the process you got a disk sub-system geared to the
requirements you needed, so while a lock-in, it was a good "marriage"
of the various hardware, etc. Really good ability to perform in the
real-time sense, a matter that is crucial in these systems to allow
multiple users to run at decent speed, etc.
Thusm this entire small niche industry was simply driven by the
"better mousetrap" phenomena. And theirs was the best. Thus,
discussions of simplistic obsolete competitors that depended on low-
performance hardware is merely of curiousity value. The PDP-8 was
able to get around many of the restrictions that had hamstrung it up
until then, namely the really poor-to-mediocre peripheral performance
associated with DEC-designed peripherals for the PDP-8, which
generally got the "short end of the stick" whenever DEC brought out
some new peripheral, and generally the third-party market put them to
shame in the "better, cheaper, faster" sense as well, but usually not
useful to the PDP-8, while in this instance, the -8 got the proper
attention for a change.
>
> The problem here is that you are talking about one specific system. A
> system that I know nothing about. And you seem to think that that is the
> yardstick we are comparing to.
Again, you know nothing about it, by your own admission, thus there is
no "we" to apply to.
>
> You are. I am not. Different systems are designed with different goals,
> leading to different compromises, and different results.
Again, a generic unfocused comment, and based on presumptions created
in ignorance, by your own admission.
>
> > By its nature, all of these systems can be brought to their knees
> > using perverse small programs. These systems were meant to be
> > cooperative at some level. System usage logs would reveal abusers,
> > but only after-the-fact; they got kicked off and their companies
> > penalized for mischief, etc.
>
> Well, no. All the systems you seem to be talking about, yes. But not all
> concievable systems. MULTOS8 (again, seems to be my favourite argument)
> will not allow a user to lock others out. Always nice with a counter
> example.
No, not an example, merely a failure. All of these systems ultimately
didn't crawl all that bad when mischief makers tried to make it so.
The crawling was real, but contained by the scheduler making their
jobs lower priority merely because they got "too large a slice of the
pie" in terms of real-time spent in support of their job. This is an
obvious design point on a commercial system. The solution to that non-
problem was solved after TSS/8.
>
> And as *I* seem to be talking about time sharing systems on a PDP8, and
> not some special system for a specific customer, which designed a system
> for some specific goals, in which you seem to talk a lot about
> cooperative multitasking, we are obviously talking about different kinds
> of systems here.
I cannot help it if you cannot follow me, go back and re-read what I
posted. When I am talking about commercial time-share-trap-based
systems, I am not talking about the higher-performance needed and
achieved for a dedicated application system where cooperative multi-
tasking is the proper way to solve that problem, totally unrelated to
creating stand-alone system illusions via dial-up.
>
> >> Sure, you can design a system where you are not allowed to allocate more
> >> memory than physically available. That's another design decision.
Spoken by someone totally guessing and presuming. The point is that
these systems were performance-oriented. You put it whatever made it
more profitable. If a system had a somewhat more initial cost, but
could realistically handle a far larger user load, it more than
justified to extra cost. The design was driven by the sales goal. By
making far more memory available, your suggestion becomes inside-out.
By having all that physical memory available, you just got efficient
allocation. The lesser system created a lot of overhead by trying to
skimp on memory. Again, the goal was to create 32K PDP-8
virtualizations, something that is far easier to do when you have 512K
available, and intend to make it work for something like 15 active
users at any given time, and more users making it gracefully slow
down, but do far better than the older, now non-competitive systems
that would overload with far less [paying] users.
>
> > But when each virtual job gets 32K actual RAM, your point is moot.
> > The system does not emulate either the TS option nor hardware to
> > support the extra stuff beyond 32K. This is largely a brute-force
> > approach, but it does work.
>
> No, my point is not moot. If you allow each user to allocate 32K of
> memory, and you have a KT8A to help you out, you can not have more than
> three concurrent users (one bank must be left for your OS to live in,
> which leaves less than 32K free in that bank).
> So it's a design decision, and it have a real impact.
Again, you don't understand.
Why bother with 128K when you can have 512K. The KT8A is a statement
of mediocrity; better stuff made it largely unmarketable, especially
to this niche market. Theoretical discussions about abandoned
products is sort of like trying to find out why the dodo bird became
extinct. The PDP-8 would have had yet another market for it go away
if it were not for the third-party hardware that helped eliminate
problems traceable to DEC's shabby treatment of the product line.
Your response here is just because you understand nothing about what I
said.
A stand-along system's handlers are by definition totally unsuitable
for the standard image of a slightly modified system designed to run
under an emulating environment. The handlers are "faked" by using
feature only available within the environment, instead of attempting
to slavishly emulate handlers instruction by instruction. The design
of P?S/8 and OS/8 allows the device to be non-"real" and only
available in the contrived environment, and as a result the software
runs far better.
However, to make a truly useful system, you have to prevent the
underlying file structures from using the stand-alone system's code as
well. You must write kernel-aware routines to perform work-alike
operations. See the source code of RTS8 to perhaps get a partial
understanding of this.
Once you commit to code that is environment-specific, you can support
all devices and filestructures you wish. Even TSS/8 supports the DMS
DECtape format. But it doesn't using the CODE from DMS to accomplish
it!
Thus, the mark of a well-written system is that the handlers are
consistent with the goals of the user-environment, and the underlying
code does in real-time what the standalone "real" system would do, but
with totally different code intimately aware of the underlying system,
and not the stand-alone version of the system you are trying to create
a multi-user variant of. [If OS/8 itself is even used, it's just a
loading program for the real-time system. In my experience, systems
such as OS/8 actually get in the way!]
>
> What MULTOS8 do, is prevent several users creating files on the same
> structure at the same time. So it still adheres to the OS/8 paradigm,
> but extends upon it, so that it is still true even when in time sharing
> mode.
I already addressed that. It's the obvious and only way to make it
work. That's why you cannot use OS/8 to do the job of multi-tasking
something that looks to any one user just like OS/8. The underlying
system has multiple files open, etc. It can be accomodated, just not
by OS/8 itself.
> It is usually not a restriction that any user suffers because of, since
> each user have a "private" home disk, which is SYS:, and where most of
> the playing of each user takes place.
Your point is obvious; this is a system that gives the illusion of
privacy, by definition.
> And each user can simultaneously be writing to his SYS: without a problem.
Who would do it any other way, what is the point of stating the
obvious?
>
> >> If you want to talk about a specific customer (or customers), then
> >> obviously they might have very different and specific requirements and
> >> needs. But that don't mean that all have the same ones.
Again, there is no point here, since you are rambling on a
presumption. Cooperastive multi-tasking is a lower-overhead way to do
what you can do within that specification. All of the other
commercial usages have the same general goals, other than some small
frills that some may have asked about, but in the main, the common
mission constrains the design, namely performance issues, perhaps
measured in how many user hours/day could the owner reasonably expect
to sell to his users.
>
> > Your theoretical reasoning was not a factor to this customer segment.
> > They always offered custom mods, but it really was never a factor,
> > other than some more minimal stuff if at all.
>
> I don't understand why you call it a theoretical reasoning. There is
> nothing theoretical about it at all. The software already exists.
Again, you don't have a grasp on the conversation. Your reasoning is
what is theoretical. That it exists is a manner of the history of the
ultimately unsuccessful. It's matter of historical fact that specific
operating owner customers requests for custom features was a nice
sales point, but never a major factor for any of them. That is not
theoretical, it's historical fact. I don't need to resort to
theoretical reasoning of a subject you have already admitted you
largely don't even know much about.
>
> >>>> Oh, and HLT is about the same as logging out of the system. :-)
> >>> An obvious frill!
> >> Well. For a time sharing system, logging out is rather essential.
Logging out is not the same as logging out via a frill. A better
system reports a console message when the system halts, and gives you
options, such as saving your program, aborting it, ignoring it
essentially continuing past the HLT. And, oh yeah, perhaps logging
out. Merely logging out is rather piss-poor and unprofessional, and
certainly not a feature the commercial operators of such a system
wanted.
> Just
> >> as logging in is. Back in the old days, you actually charged for the CPU
> >> time used on time sharing systems. So loggin in and out served many
> >> purposes, and was definitely not a "frill".
Your generic comment about what was not the point can be understood.\
>
> > No, logging out at all yes, that with a HLT is a frill. I think that
> > many people would want it NOT enabled, or at least only goes to a
> > prompt with default to not do so.
>
> > Whether or not you are aware of it, OS/8 has some internal HLT
> > operations! Go search the code if you want.
>
> Indeed. But executing a HLT means you won't be doing much more anyway.
> A HLT is not something you normally would be executing anywhere, anyway.
> So, having a HLT in the time shared system log out out is pretty reasonable.
Again, a generic and misleading remark. You missed the entire point:
If you run a copy of OS/8, and this is beyond the scope of handlers,
there are HLT instructions because the design of OS/8 is far less
clean than you apparently give it credit for. If these HLTs execute,
it's because of the general problem of the fact that OS/8 has some
flakey points. I'll expand on the problem as an example:
Every call to the OS/8 system handler has an error return. This is
fine if you have a reasonable ability to deal with the consequences.
Unfortunately, due to problems in the design, the calls that take the
error return have no code space to gracefully deal with the
consequences. Thus, these are where these embarassing HLT operations
come in.
Thus, you wouldn't wnat to be running a shared-image of OS/8 for all
users of a multu-user system where it might execture a HLT and you are
logged off. You might want to get a handle on why it halted, because
it would indicate a problem somewhere else.
In P?S/8 in 4K, the system handler, by design, has one designated HLT
location. By definition, pressing continue retries the latest
operation. It has a chance to recover, such as a flakey tape data
error or perhaps a flakey tape search failure because the tape cannot
be read, or merely a write-protect error; pressing continue on the
latter after write-enable will make the latest write succeed.
When you enable the logical console overlay on a machine with at least
8K, P?S/8 then literally has NO HLT operations. The IOPS4-like
critical error handler takes over. OS/8, because of the "ugly" points
I mentioned, cannot accomplish this. [When you run the P?S/8 BIN
program, you have user control as to where to start, and any HLT at
this point is under control of the operator of the machine, meaning
front-panel control. The default for not specifying a starting
address is a "safe" HLT by design, a designated address within the
loader, etc. This is not a "protected" environment by design, since
this just a CPU and a loaded program, not a trapped environment. If
you wish, you can enlist the aid of P?S/8 ODT to maintain breakpoint
control on your binary user program. [It's a proper superset of OS/8
ODT including a table of 16 breakpoints instead of only one, and has
various memory dumpout options added as well, etc.]
Thus, a P?S/8 adaptation for a multi-tasked version would create a
trapped version of the stand-alone environment, meaning at the point
where your binary is in memory, and the O/S is already kicked out.
For all other operations, there would be no "surprise" HLT
operations. [And of course, some P?S/8-alike multi-tasking routines
would be needed to access the directories, etc.]
>
> >> (I'm deleting all the stuff about the KT8A here. Suffice to say that I
> >> was way off the bat. I totally misremember what the KT8A did, and how. I
> >> read through the manual again now to refresh mysef, and noticed that
> >> it's not that useful after all. You basically have to do the same thing
> >> as with the KM8E, unless you want to limit your time sharing system to
> >> only allocate memory that you know you have physical memory for.)
>
> > No, because you could have 128K physical memory, but the objective is
> > to only allocate 32K maximum because only the extended memory of 32K
> > is being made available, not the KM8E instructions or KT8A
> > instructions at all. Thus, you don't quite mean what you said.
>
> I definitely mean what I said.
> Having a limit of max 3 concurrent processes is (in my mind) a rather
> severe limitation.
> Oh, it is definitely good enough for some situations, and some problems,
> but it's definitely not good enough for a more general purpose time
> sharing system, where you'd want a few more concurrent users.
> MULTOS8 for instance can have up to 6 concurrent users.
Again, a misunderstanding of the problem. Wallowing in the precise
definition of just how little an obsolete system was capable of is to
short-sightedly distort the subject.
In short, by the time the KT8A was about a year old, all of these
systems were irrelevant.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
cjl
jmfbahciv
> On Mon, 29 Jun 2009, Mike Ross posted:
>> You forgot the 3340; the *original* 'Winchester'. 30-30. And yes I'm
>> *still*
>> looking for one!
>
> Go to any gun store. :)
>
> For the benefit of those who didn't get the joke, .30-30 is a popular
> caliber for deer hunting, and thus a Winchester .30-30 would be a
> typical deer rifle.
>
buck.
/BAH
Rob Warnock
| > system (along with the usual ASCII terminals) which could front-end
| > PDP-10s, PDP-11s [and -20's & VAXen with PDP-11 front ends], and
| > from us to use on their PDP-10s in Murray Hill(?), largely for
| > document preparation with RUNOFF.
|
| It wasn't Bell Labs in MH. I don't think there was ever a PDP-10 here.
| Western Electric's ERC in Princeton was a PDP-10 shop though,
| an conceivably the Piscataway operation, though they mostly
| worked on front-ending job entry for IBM and Univac mainframes.
| However their document-processing was troff.
Probably Princeton, then. I did the installation [with one other guy],
but it was so long ago I don't remember which city it was! ;-}
And it well could have been "troff"-- I just assumed that it was
RUNOFF 'cuz it was a PDP-10, and I didn't think "troff" ran there.
Sorry for the confusion.
+---------------
| We did make 2741s and their ilk work on Unix here, at least for
| output--I don't think we ever bothered with input.
+---------------
DCA's converter would have worked on Unix hosts, too, since it
just made the 2741s look like ASCII terminals to the host.
[We had a card that I'd designed, the DCA SMARTmux-205, that
plugged into a Unibus and pretended to be 1 to 16 8-port DZ11s,
but was really a Z80 running our multiplexer code. Customers
used them on VAXs, -11s, and the -11 front ends on -10s & -20s.]
But it worked "better" on the PDP-10s [connected using a DA10 clone],
since on the -10s we installed a modified SCNSER on the host that
gave us better hooks into the terminal state [e.g., whether the
host job was waiting for TTY input or not, so we could know whether
to unlock the 2741 keyboard or not]. On TOPS-20 or VAX/VMS (or Unix)
hosts, we just pretended to be DZ11s with ASCII terminals on them
and faked up the 2741 keyboard state the best we could.
-Rob
Peter Flass
Didn't Multics support them also?
Walter Bushell
wrote:
A 16 point buck would get all the doe.
2 bits 4 bits
6 bits a buck
All for JC [1]
Stand up and f---.
[1] my alma matter.
CBFalconer
> Johnny Billquist <b...@softjar.se> wrote:
>
... snip ...
>>
>> No, to do it far better than without! This was for competitive
>> systems of this ilk.
>
> JB: Over the years you have repeatedly made it abundantly clear
> you do not understand my points, and your responses just go off
> into a tangent as you try to evade what I said instead of asking
> for clarification. I'll cut through all of this part real quickly.
This may have some connection with your habit of writing 500 line
responses to 2 line enquiries.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
cjl
> cjl wrote:
> > Johnny Billquist <b...@softjar.se> wrote:
>
> ... snip ...
>
> >> No, to do it far better than without! This was for competitive
> >> systems of this ilk.
>
> > JB: Over the years you have repeatedly made it abundantly clear
> > you do not understand my points, and your responses just go off
> > into a tangent as you try to evade what I said instead of asking
> > for clarification. I'll cut through all of this part real quickly.
>
> This may have some connection with your habit of writing 500 line
> responses to 2 line enquiries.
Actually, no. However, if you are saying that I should cater to the
sound-bite generation, go away.
JB and I go back many years; he usually has the ability to separate
out the issues fine, albeit with disagreements coming out anyway.
In this instance, there was far more than an admitted confusion over
the two inter-twined issues: PDP-8s used in larger-scale applications
than most, and that there was a fork in the road.
A sub-theme is that you should use the right tool for the right job,
and not merely because it's "convenient" or "the company supports the
base" or other tommy-rot that some others foolishly used. This
arguments transcends pdp-8s and even discussions of DEC per se.
I never had any personal interest in pursuing making a better
mousetrap of a multiple-terminal commercial-worthy dial-up PDP-8
system that was reminiscent of what you would get if you had a
somewhat limited PDP-8 configuration in front of you [compared to what
you could reasonably expect at the time from a stand-alone system
serving one application/developer/user at a time]. I also didn't have
to, because I was indirectly acquainted with one of the best of these
systems, which in turn indirectly depended on diagnostics, support
programs, and handlers I wrote in support of what is arguably the
highest performance -8-compatible peripheral that was ever sold by
anyone.
And in the unrelated alternate thread, I described how I chose the
proper tool to implement an alternate application, where the mission
was to get the application job done, not to have any claim of
compatibility with anything, only the hardware that could be
supported. In the original implementation, the disk was the RK8E/
RK05, and the software exploited everything that the disk hardware
could do. Handler code space is a non-issue in a custom system
written from the ground up.
There are parallels to that in the underlying support system that
creates the illusion of the stand-alone systems for those paying
customers on the time-shared systems. What you write is not
constrained by the conventions of what you are attempting to emulate.
Once your application-specific system is in memory, it is a stand-
alone base to make the illusion work. There is no particular
advantage [or disadvantage] to having an OS/8 system that loads in the
real-time application base; it's irrelevant. It could be brought up
by a paper-tape load or whatever you wanted to.
However, in the implementation of what I did as an application system,
it was quite clear that no existing development/small application-
oriented PDP-8 system was suitable, in part because it required in-
context utilities that were hopelessly divorced from OS/8 or any other
system. The requirements of the application demanded a high-
performance directory system that has never otherwise been standard on
any other PDP-8 system of any description, although the concepts have
been done elsewhere. Additionally, the internal file format demanded
that the files were stand-alone complete, so that the directory could
be rebuilt, since the running multi-user system needed a directory to
access the files quickly, but it was not the only way to get at the
data; that was imbedded within the files themselves, etc.
Sorry if any reader here cannot keep in their heads more than one sub-
topic at a time, but sometimes you have to be able to sort out two or
even [shudder!] three.
cjl
jmfbahciv
> On Jun 26, 6:08 am, Tim Radde <tra...@excite.com> wrote:
>>> 2) TSS/8 was totally forgettable. As the principle author of a
>>> system that actually runs fairly effectively on a 4K PDP-8, I can tell
>>> you that you cannot do much without more memory. On the other hand,
>>> what I was able to do in 4K is surprising. But having all of the
>>> overhead to simulate a 4K environment seems more than pointless.
>>> Simply put, TSS/8 didn't do anything useful for anyone, especially
>>> given the choices, shopping around, not all DEC all the time.
>>> cjl
>> I find I have to disagree with your first comment that TSS/8 was
>> useless.
>> Back in those days computers were still fairly expensive, especially
>> for
>> small colleges, and forget high schools. If it were not for TSS/8
>> running
>> at the local community college and providing connectivity to most of
>> the local (county) high schools I would probably never have gotten
>> exposed to computing. So you had a virtual 4k pdp-8. I found it
>> fascinating and could do quite a bit with it. It was pretty amazing
>> (I think)
>> what a small computer wiht 32k of core could support user-wise. I
>> believe
>> our system supported 12 to 16 users. Mostly over dial up modems.
>> But they were spread throughout the county and most of these schools
>> would never have had an type of computer program without TSS/8.
>> Well, it helped that Mass had some sort of program to help the
>> college defer some of it's costs for providing such service. But for
>> it's time I think TSS/8 was a good thing for what it did using the
>> little
>> it had.
>
> Your response is out of time context for what I mentioned.
>
> By the time that what I wrote applied, no one would care about time-
> shared anything for the most part, other than for far larger systems.
That is simply not true. People expected a print request to work
in the background while they did more editing or email or something.
> The whole point is that you could have your own unshared machine.
Which required some flavor of time-sharing so you didn't have to
wait for the last computing service request to finish.
> And
> for a quite small audience, you could have time-shared versions of
> that as well, which was a whole lot more than TSS/8 ever offered in
> its useful lifetime, which had long ended at that point, unless you
> swallowed the Koolaid of all DEC all the time.
>
You are losing credibility with me. DEC was in the hardware business;
you keep assuming that DEC was supposed to provide all software
for everything all customers needed.
/BAH
jmfbahciv
> In article <h2cs2...@news2.newsguy.com>, jmfbahciv <jmfbahciv@aol>
> wrote:
>
>> Mark Crispin wrote:
>>> On Mon, 29 Jun 2009, Mike Ross posted:
>>>> You forgot the 3340; the *original* 'Winchester'. 30-30. And yes I'm
>>>> *still*
>>>> looking for one!
>>> Go to any gun store. :)
>>>
>>> For the benefit of those who didn't get the joke, .30-30 is a popular
>>> caliber for deer hunting, and thus a Winchester .30-30 would be a
>>> typical deer rifle.
>>>
>> It might be a long time before anybody could aim at a 16-point
>> buck.
>>
>> /BAH
>
> A 16 point buck would get all the doe.
Oh, <groan> Very good :-).
>
>
> 2 bits 4 bits
> 6 bits a buck
> All for JC [1]
> Stand up and f---.
>
> [1] my alma matter.
/BAH
Bill Marcum
I'm reminded of the song about "da turdy point buck". Here's a link to
a video: http://www.youtube.com/watch?v=9Utt_XgcWv8
Here are the lyrics (watch out for wrapping):
http://www.lyricsforall.com/display/lyric/782212288/151738821/Bannanas+at+Large/Turdy+Point+Buck/
It isn't clear whether the original artist is Bannanas At Large or Da
Yoopers, or maybe those are two names for the same group.
van...@vsta.org
> This may have some connection with your habit of writing 500 line
> responses to 2 line enquiries.
In my opinion, cjl's responses have been some of the most informative
postings I've ever read on Usenet.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
Walter Bushell
wrote:
> Walter Bushell wrote:
> > In article <h2cs2...@news2.newsguy.com>, jmfbahciv <jmfbahciv@aol>
> > wrote:
> >
> >> Mark Crispin wrote:
> >>> On Mon, 29 Jun 2009, Mike Ross posted:
> >>>> You forgot the 3340; the *original* 'Winchester'. 30-30. And yes I'm
> >>>> *still*
> >>>> looking for one!
> >>> Go to any gun store. :)
> >>>
> >>> For the benefit of those who didn't get the joke, .30-30 is a popular
> >>> caliber for deer hunting, and thus a Winchester .30-30 would be a
> >>> typical deer rifle.
> >>>
> >> It might be a long time before anybody could aim at a 16-point
> >> buck.
> >>
> >> /BAH
> >
> > A 16 point buck would get all the doe.
>
> Oh, <groan> Very good :-).ta
Why groan, it's a simple statement of fact, about as directly s
True too, that's why Bambi's father only looked in on his mother and him
rarely. Something the Disney did not go to the trouble of making this
explicit. Bambi's father and the father of nearly all the fawns would be
the same.
Eric Chomko
> In article <h2cs2311...@news2.newsguy.com>, jmfbahciv <jmfbahciv@aol>
Wait, wait, don't tell me...
Larrry Flynt University, home of the "Hustlers"
Walter Bushell
<d8429f0c-3397-48bc...@37g2000yqp.googlegroups.com>,
Eric Chomko <pne.c...@comcast.net> wrote:
Juniata C
Freddy1X
( cuts )
>
> I'm reminded of the song about "da turdy point buck". Here's a link to
> a video: http://www.youtube.com/watch?v=9Utt_XgcWv8
> Here are the lyrics (watch out for wrapping):
>
http://www.lyricsforall.com/display/lyric/782212288/151738821/Bannanas+at+Large/Turdy+Point+Buck/
> It isn't clear whether the original artist is Bannanas At Large or Da
> Yoopers, or maybe those are two names for the same group.
Da Yoopers did "The Second Week of Deer Camp"
Bananas At Large did "da turdy point buck"
Similar sounding themes.
Freddy,
( has the Da Yoopers album )
--
Do not put child in bag
/|>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\|
/| I may be demented \|
/| but I'm not crazy! \|
/|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<\|
* SPAyM trap: there is no X in my address *
cjl
From a dial-up somewhere else? I rather doubt they expected to drive
30 or more miles down the road to go pick up their output.
The target audience were dial-up customers. This software was a niche
product for a specific set of users.
For the bulk of developers, they would go get something printed on one
machine, walk two feet over to another machine and continue there with
their files on a diskette now placed into the drive on the second
system.
The systems used by one-off people have nothing to do with I have no
idea what you think was relevant to the larger audience. If TSS/8
could do this, so what? It still served only a small few number of
people. That is historical fact, not theory.
I admit that there never developed a slightly larger-scale PDP-8
system with a print-spooler; this is why I have pondered a "real"
PDP-8 16 requiring at least 16K and preferably more, with applications
that would require interrupts on. Unfortunately, the way the DECmates
work, a lot of the performance would go away due to the emulation,
which makes a lot of the system's time in a paused state while a lot
of cycles are run inside of control-panel memory.
An alternative would be to write a DECmate-specific one-off system
that in fact expected to run embracing the DECmates, all of which have
32K. However, that would lock out all of the "real" PDP-8's where
normal interrupts apply. Perhaps there needs to be two new
systems :-).
>
> > The whole point is that you could have your own unshared machine.
>
> Which required some flavor of time-sharing so you didn't have to
> wait for the last computing service request to finish.
Again, to what specific implemented PDP-8 system are you referring?
The capabilities of all of the sparsely used PDP-8 systems was fairly
similar in thast regard. The user environment is quite limited in all
sorts of ways. What I would want to see would be more like what RT-11
eventually became. Single-user, but multiple "jobs" running, etc.
>
> > And
> > for a quite small audience, you could have time-shared versions of
> > that as well, which was a whole lot more than TSS/8 ever offered in
> > its useful lifetime, which had long ended at that point, unless you
> > swallowed the Koolaid of all DEC all the time.
>
> You are losing credibility with me. DEC was in the hardware business;
> you keep assuming that DEC was supposed to provide all software
> for everything all customers needed.
If so, then I am doing my job. The over-arching point I made is that
in fact DEC provided very little software that was really useful. To
get anything useful, you had to write your own, or be a customer of
someone who did [and I am a member of that latter definition]. But to
a lot of drones, they thought that what they got with the machine was
the be-all/end-all.
Apparently, back in the day, you would have had the ability to
understand why I am championing that very point, since I was *never*
in the promotion of DEC software business. When I attempted to help
them improve what they offered [and I was part of a substantial group
of people doing this; the software is an outgrowth of software written
at a school; all we were asking was DEC donating stuff to that school,
this was not a money issue whatsoever!], they first rejected the group
[many of which at the time were then DEC employees. The second time
around when it was demoed to prove that their claims were not hype in
the slightest, and the DEC "suits" were converted from scoffers to
believers, they still rejected it, but only for reasons that make no
good business sense, especially given what DEC was doing at the time,
etc.
cjl
>
> /BAH- Hide quoted text -
cjl
> In alt.sys.pdp10 CBFalconer <cbfalco...@yahoo.com> wrote:
>
> > This may have some connection with your habit of writing 500 line
> > responses to 2 line enquiries.
>
> In my opinion, cjl's responses have been some of the most informative
> postings I've ever read on Usenet.
Thank you for confirming that at least one other person on this thread
can actually "read" as opposed as the verb form of "to sound-bite".
I freely admit I answer complex subjects with appropriately complex
answers. Quite often, a lot of sub-threads interact into a whole of a
proper contimuum on some subject. Spoonfeeding out all of the "parts"
is actually more to wade through that one central coherent posts.
Some of my posts are meant to be self-contained subjects possibly
entitled "all the things you ever wanted to know about the TD8E,
aren't you glad you asked" kinda stuff. That no one has to ask any
followup questions attests to that.
I would like to hope that alt.sys.pdp8 [again, for those hopefully
little head count of readers who might still not know this], a group I
personally created, should eventually be looked back on as the place
to go read the archives of for all things PDP-8 and related. Perhaps
someone wants to create some form of chronicle of the postings here
[or any other well-organized focused usnet group]. That's not
something I'm good at, but I do have a lot of material to provide,
etc.
And just so you know, I do more than "merely" PDP-8 stuff; if you
really care, do some appropriate search mechanism. But my knowing
stuff about multiple subjects, the "knowledge base" is improved. For
example, I have posted about how PCs have some really good utilities
for appropriately-configured machines to support DECmate diskette
stuff. [Primarly because the machines themselves cannot format.
Thanks to some good work there, DEC letting us down has been conquered
in this area.]
cjl [negative followups to alt.soundbite.short-replies-only]
jmfbahciv
> In alt.sys.pdp10 CBFalconer <cbfal...@yahoo.com> wrote:
>> This may have some connection with your habit of writing 500 line
>> responses to 2 line enquiries.
>
> In my opinion, cjl's responses have been some of the most informative
> postings I've ever read on Usenet.
>
biz worked in other areas.
/BAH
jmfbahciv
From the system they were working on. If people were 30 miles away
from the main site, they would have had a remote printer within walking
distance. Waiting for a print, or any other computing service request,
to be completed before typing another character to their terminal wasn't
acceptable after 4S72 on the mainframe. That's why remote stations
were sold.
>
> The target audience were dial-up customers. This software was a niche
> product for a specific set of users.
A lot of our customers installed remote stations for their users who
were far away from the computer that was used as the main work horse.
>
> For the bulk of developers, they would go get something printed on one
> machine, walk two feet over to another machine and continue there with
> their files on a diskette now placed into the drive on the second
> system.
and timesharing would have eliminated that sneaker transfer of work
site.
>
> The systems used by one-off people have nothing to do with I have no
> idea what you think was relevant to the larger audience. If TSS/8
> could do this, so what? It still served only a small few number of
> people. That is historical fact, not theory.
That is historical fact in your work area. There were lots of other
people at other computer sites who solved the problems a different
way.
>
> I admit that there never developed a slightly larger-scale PDP-8
> system with a print-spooler; this is why I have pondered a "real"
> PDP-8 16 requiring at least 16K and preferably more, with applications
> that would require interrupts on. Unfortunately, the way the DECmates
> work, a lot of the performance would go away due to the emulation,
> which makes a lot of the system's time in a paused state while a lot
> of cycles are run inside of control-panel memory.
To have a print spooler in your work area, you probably would have
needed a network set up which would have transferred the file to
be printed to the remote station. The remote station would then
have run the software that would receive the files and handle
the print requests.
Since the work you described was in the era of DECmates (which is
a lot later in calendar time than the times other people were
talking about to you), you could have used a network setup for
the computing service requests that did not have to be right now.
>
> An alternative would be to write a DECmate-specific one-off system
> that in fact expected to run embracing the DECmates, all of which have
> 32K. However, that would lock out all of the "real" PDP-8's where
> normal interrupts apply. Perhaps there needs to be two new
> systems :-).
I'd have had to see your computers' footprints to see the best methods.
Even a cheap LAN would have served.
>
>>> The whole point is that you could have your own unshared machine.
>> Which required some flavor of time-sharing so you didn't have to
>> wait for the last computing service request to finish.
>
> Again, to what specific implemented PDP-8 system are you referring?
It doesn't matter which PDP-8. My comment had to do with the fact
that timesharing was alive and well and a requirement even if it
was hidden.
> The capabilities of all of the sparsely used PDP-8 systems was fairly
> similar in thast regard. The user environment is quite limited in all
> sorts of ways. What I would want to see would be more like what RT-11
> eventually became. Single-user, but multiple "jobs" running, etc.
Sigh! And that is timesharing. I liked IAS much more than RT-11.
>>> And
>>> for a quite small audience, you could have time-shared versions of
>>> that as well, which was a whole lot more than TSS/8 ever offered in
>>> its useful lifetime, which had long ended at that point, unless you
>>> swallowed the Koolaid of all DEC all the time.
>> You are losing credibility with me. DEC was in the hardware business;
>> you keep assuming that DEC was supposed to provide all software
>> for everything all customers needed.
>
> If so, then I am doing my job. The over-arching point I made is that
> in fact DEC provided very little software that was really useful.
We provided all the tools necessary for you to do your work. Editor,
DDT, a monitor that will get you started and serve as an example
of how to write that code, and other CUSPs that we found useful,
such as PIP, spoolers, and login/logout handlers.
> To
> get anything useful, you had to write your own, or be a customer of
> someone who did [and I am a member of that latter definition]. But to
> a lot of drones, they thought that what they got with the machine was
> the be-all/end-all.
>
I went to a couple of DECUSes. I never met any "drones". One of the
reasons DEC did well is because the customers were allowed to do
anything they wanted with the machines they bought. This was one
of the selling points over IBM in the late 60s and early 70s.
> Apparently, back in the day, you would have had the ability to
> understand why I am championing that very point, since I was *never*
> in the promotion of DEC software business. When I attempted to help
> them improve what they offered [and I was part of a substantial group
> of people doing this; the software is an outgrowth of software written
> at a school; all we were asking was DEC donating stuff to that school,
> this was not a money issue whatsoever!], they first rejected the group
> [many of which at the time were then DEC employees. The second time
> around when it was demoed to prove that their claims were not hype in
> the slightest, and the DEC "suits" were converted from scoffers to
> believers, they still rejected it, but only for reasons that make no
> good business sense, especially given what DEC was doing at the time,
> etc.
And _exactly_ when was this? If it was in the 80s, then DEC was
rapidly turning into Digital with an IBM middle management
mentality.
By the way, it takes a whole lot of money and manpower to take software
from outside the company and put it on a software distribution tape.
So your assertion that it would cost no money is completely not true.
/BAH
jmfbahciv
And this is the attitude I have a problem with.
/BAH
Peter Flass
>
> By the way, it takes a whole lot of money and manpower to take software
> from outside the company and put it on a software distribution tape.
> So your assertion that it would cost no money is completely not true.
>
That's why there were groups like DECUS and SHARE.
Johnny Billquist
you mean well, and you have a lot of knowledge that can be helpful to
people.
But sometimes it just becomes too much.
I do understand your points most of the time, I just don't always agree
with them. But for some reason you seem very unable to recognize that
there might actually be another view that is just as valid.
I'll make this really short. I know you'll disagree, and probably write
a very long response trying to prove me wrong, but I will probably not
bother answering that one.
1. You wrote: "1) It was not relevant to add non-DEC hardware to get
anything you
needed to work properly. However, that meant it had to be in a PDP-8/
a box because the hardware would be the KT8A or possibly the CESI
replacement for it that was software incompatible, but could be
configured to up to 512Kwords of memory, which is more important. But
even the DEC card got you to 128K. With 512K, you could mostly forget
about swapping out users unless you truly had way too many of them."
I disagreed with this, I *know* you didn't need an 8/a box to tay with
DEC and yes get to multi user and timesharing. You later claimed you
didn't say you needed an 8/a, but the above, quoted paragraph,
definitely shows that you did say so.
More specifically . "...it meant it had to be in a PDP-8/a box because
the hardware would be the KT8A..." is in direct denial of the fact that
any machine with the user mode option can do anything needed. We then
seemed to spin off on what a KT8A can and cannot do, and by the end it
appears that you don't like the KT8A anyway, so we can just as well drop
it right away.
2. I claimed that you can do, and people did do time sharing on PDP8
systems. You claim it's just theoretical speculations by me. Well, I
even posted a link to existing software that will do this for you, and
you still claim it's only theoretical. I pointed out that this software
works, and handles a lot of issues that might pop up, and you just try
to ridicule the designers decision that HLT will log you out, and so on.
And you even go on about time frames which seems totally irrelevant. I
suspect you haven't even looked at the link I posted. MULTOS8 was/is wa
piece of software *not* written by DEC, so leave DEC out of this.
MULTOS8 was a commercial product however, showing that your software,
written for one(?) customer wasn't the only player around. MULTOS8 have
dates in the source saying 1979, which is way past TSS/8, and way past
when DEC was running full steam on PDP-11s, and had even started moving
on to VAXen, and still this product was being developed, and sold.
There is simply nothing "theoretical" about it. You might not like it,
but that won't make it go away. And it's a counter proof to some things
you are claiming. Live with it.
3. This whole thread has spun in many directions, but my responses have
been centered on the issues and questions regarding time sharing and
virtual machines. MRC noted that the sbc6120 didn't have user mode, and
thus it would be difficult to get a time sharing system running on that
hardware. And he also touched on the difference between VMs and time
sharing. This is where I stepped in, as I had an example of software for
the PDP8 which had aspects of both VM and time sharing, namely MULTOS8.
Why do you have such a problem with this?
4. I noted that performance on a system employing user mode, and virtual
memory (which is required if you want to allow programs to allocate more
virtual memory than physically available, and there is no way you can
wiggle your way out of that one) will cause performance penalties. But
for some people those penalties are acceptable. It's a simple fact of
life. Different people have different priorities, causing them to accept
different compromises. On the up side, such a system will not allow one
user to lock out another, nor have one user being able to modify the
context of another user.
5. MULTOS8 really makes it appear for each user as if he is running a
virtual PDP8, with his own copy of OS/8. Really. Every user will be
running his own copy of OS/8. The one thing which differs from a
physical machine running OS/8, is that MULTOS8 will change the device
tables, and device drivers for your OS/8, the rest is left alone. In
fact, what happens is that all devices will always appear to already be
in core because of this, and they all go somewhere in the top page of
field 0, where the system device driver is. This isn't something OS/8 or
applications have any problems with.
You can deny reality all you want. It won't go away anyhow.
If anyone would like to play with time sharing on a PDP-8, I think that
MULTOS8 would be an excellent starting point. It works, it's nice. A bit
primitive in some areas, but since the sources are there, people can
expand on it. And it requires nothing more special than a PDP-8, with
the user mode option, a minimum of 20K (just checked), some type of
clock, and disk. I think it might require an RK05, but it might work
with other system disks as well. The documentation in there is pretty
okay, but don't exactly reflect the state of the code. For instance, the
documentation says a maximum of four users, but the code says six. Of
course, more memory always helps, but MULTOS8 don't try to use anything
like the KT8A.
van...@vsta.org
>> In my opinion, cjl's responses have been some of the most informative
>> postings I've ever read on Usenet.
> They are very good. He has some confusion w.r.t. how the computer
> biz worked in other areas.
The cool part is how many of the original folks are around on Usenet
groups. These groups and their archives are going to end up being a
very important resource for computer history.
Andy Valencia
Eric Chomko
I just looked it up. Seems to be somewhere near Penn State. Are you
guys the "Cubs"? Allegheny Cubs?
Rob Warnock
+---------------
| cjl wrote:
| > From a dial-up somewhere else? I rather doubt they expected to drive
| > 30 or more miles down the road to go pick up their output.
|
| From the system they were working on. If people were 30 miles away
| from the main site, they would have had a remote printer within walking
| distance. Waiting for a print, or any other computing service request,
| to be completed before typing another character to their terminal wasn't
| acceptable after 4S72 on the mainframe. That's why remote stations
| were sold.
|
| > The target audience were dial-up customers. This software was a niche
| > product for a specific set of users.
|
| A lot of our customers installed remote stations for their users who
| were far away from the computer that was used as the main work horse.
And DCA[1] ended up selling a bunch of such "remote stations" as a
result, especially on PDP-10s & DEC-20s. We had a remote mux that would
handle 12 async 9600-baud terminals on a single synchronous 9600-baud
trunk line (using a Bell 209 modem or eq.). We also provided software
for the hosts to support serial line printers *and* a serial card reader(!)
so the mux plus a printer & card reader could be a whole "RJE station",
compatible with QMANGR & friends.
-Rob
[1] Digital Communications Associates in Atlanta, not the ".gov" one.
cjl
> >> This may have some connection with your habit of writing 500 line
> >> responses to 2 line enquiries.
>
> > In my opinion, cjl's responses have been some of the most informative
> > postings I've ever read on Usenet.
>
> They are very good. He has some confusion w.r.t. how the computer
> biz worked in other areas.
An interesting theory. Mind giving any concrete examples?
cjl
>
> /BAH
jmfbahciv
And even that cost money and manpower. Think about it.
/BAH
jmfbahciv
Dumping all the knowledge I have is the reason I work in these
newsgroups.
/BAH
jmfbahciv
/BAH