Charles Lasner, a legend in the PDP-8 community, spent Friday at the RICM. His visit to the RICM concluded a multi-day trip through New England visiting PDP-8 enthusiasts.

We tried his latest version of his PQS8 operating system on our DECtape only PDP-8/I. PQS8 has a much more modern console interface than OS/8, is much more capable than both OS/8 and DMS, and still runs in just 4k of core. The only reason I can think of that DEC would have rejected offering this OS on the PDP-8 is that it would have continued to make the PDP-8 a competitive product compared to the newer PDP-11.

Charles also gave us a preview of a PDP-8 software development environment that he is working on.

Charles reminded me that the correct spelling for his operating system is P?S8 not PQS8.

I was waiting for this. I knew he would.

On 5/14/17 9:24 AM, Bob Eager wrote:

>> Charles reminded me that the correct spelling for his operating system
>> is P?S8 not PQS8.
>
> I was waiting for this. I knew he would.
>

Maybe this is a clue has how you're supposed to PRONOUNCE P?S8

A composite reply to you all:

1) P?S/8 for SIMH will be released shortly.  Look for announcements on the group I created pepswin.  [The product is known as the P?S Extended PDP-8 Simulator for Windows.[

The biggest obstacle at the moment is legal issues because I use a few third-party things that are useful to the package.  Thus, the consensus opinion is to end-run around the problem documenting things such as this:

a) Download and install the relevant Windows shareware/ freeware application and install it in the default way.  Retrieve from that application a stated file and  copy it into a designated directory wihin the PEPS installation after the fact to make that part of it whole; repeat for all affected files.

One of them comes slightly nagwared.  I can't "officialy" tell you how to get around it, but I do mention another great freeware utility you can also install in Windows [and add an icon to PEPS's main window because independently of this, it is just useful.]  If you can put two and two together, I never you how to, and let your conscience be your guide [I an not a policeman.[  Of course, I CAN officiallr ecommend you pay for an upgrade to remove the nagware, and THEN follow my documentation [when I get a chance to write it!] which is then a "clean" situation no one can complain about, etc.  [The rest are just copying freeware files, but I think this is also dnoate.Paypal-ware, etc.]

Issues like that aside, all documentation is in some need to be updated, some more than others, but on balance, it is pretty good [or at least once I crank out all the intended edits on the to-do list].

Beyond that, I am still testing the product out on all the supported systems.  An earlier version was tested on Windows 7, and while it worked [and I contemplate no additional problems with the newer stuff added] I do have to document registry patches that are needed to restore a feature that was fine in Vista and XP, that a prelimary version was released with two different binaries, one for 7 and one for Win08, but now apparently it has been updated to one patch for at least both of them with a claim of still untested but could work on Win 10.],  So, when I get back to testing it there, I don't expect any problems otherwise, and have to document the then-current status of the reg patch author's work, etc.


It just works fine on XPm and I am in the death throes of testing it on Vista, which did have some unexpected problems.  [I did a generic workaround, but there was a problem that likely only affects 64-bit Vista, but don't hold your breath about expecting MS to fix ANYTHING that far back [in their minds, "old" is more than six months ago, but the new one!].

Unknown on 8 or 10 at this point.  Check in pepswin group for details as they are available.  [I will let anyone in, but you do have to request to join, that's google groups for ya!]

?Here is the true story of the name and enough of the P?S info so you can avoid filling out the 30-page official P?S questionaire [that no one to date has ever gotten even close to finishing.  It includes requiring the requester to pose some type 3 questions of their own, etc, and we were told some people were just in tears trying.  [But then again, that was because the P?S was hacked by another group!]

In any case, this is documented in the PEPS user guide and/or one of the P/S/8 manual files.

P?S is symbolized by a large question mark that was typically applied to royak blue sweatshirts as the "official P?S uniform" typically.  I may be able to get someone to photograph an aughentic one, but it is somewhere between the Riddler version used by Frank Gorshin on the 1966 Batman TV show, and the one in the comparable icons I use throughout the package.  [Actually the one in the icons is a bit closer to the authentic ones, so I am comfortable using that one within the Package.  this is of course a cosmetic consideration, but authenticity should be used wherever feasible.

That said, the pronunciation is as if spelled  pee-kew-ess as is explained in one of the manuals.

When using file names and other contexts where you have to avoid wild-card characters, only then should you substitute PQS for P?S.

DEC had a long marketing tradition of terms such as PS/8 for the original release of what was later called OS/8 [and originally was known by some acronyms not acceptable in mixed company.  For those familiar with some OS/8 sources, there are some references to the "BLEEP! monitor".

For those who want more info, contact me by e-mail.

Un any case a salesman demanded a name change to OS/8 claiming he couldn;t sell a customer on a "programming system" so he wanted the name change to sell them on an "operating system" with no other issues relevant, etc.

In reaction to this, some of us packaged up the R-L Monitor System [P?S/8 is a direct descendant of RL] and submitted it to DECUS as MS/8 to thumb our noses at marketroids in general.  Thus, when it came time to distinguish it, the bame became P?S/8.  [So, you can pronounce it as pee-kew-ess-ate .]

And of course, DEC had at least THREE ATTEMPTS to adopt the software, and did not. It had nothing to do with anything related to the -11, rather merely because they insisted on having ANY system need more memory!  They DICTATED that <bleep> HAVE to require 8K, and the quick-and-drity hack that was written in 48 hours will full intention to be scrapped in favor of another system REASONED by all of the PDP-8 programming community at large NEVER HAPPENED.  Tus, OS/8 has a lot of needless internal crap that can never be used [and it shows].  [I have the dubious distinction of being OS/8's oldest and most knowledgeable critic, and I was the FIFTH person to turn DEC down, telling Richard Lary that instead I and others would be developing the R-L Monitor System [which was in fact what is still going on today, as again I am actively working on it NOW!].

The second attempt I was literally rejected because it doesn't REQUIRE 8K.  "It might lower memory sales" is an exact quote from that particular "suit" at the time.  [Note:  P?S/8 CURRENTLY just about completely works in 4K.  But many things are compromised and dynamically check for more memory.  For example P?S/8 PAL can assemble small programs in 4K, but it can use as much as 20K to allow a 4096 symbol table. [PAL8 can use up to 24K for the identical reason.

I have source programs that cannot be assembled in less than 16K; does that mean OS/8 "requires 16K"?  The idiot just asked the wrong questions.

Worse wtill, the era of the PDO-8/A with small memory configurations was just emerging.  Many of these systems had no extended memory controller [and some didn't even have 4K total RAM!].  It would have been ideal if for no other purpose but in support of that set of projects.

After the third time, the idiot manager just ignored everything his programmers [the active people lobbying for it] so I just sold a limited license to Intersil so they could use it on their Intercept I, a somewhat better but comparable to the VT-78 system.  They renamed it Intercept Floppy Disk Operating System [IFDOS] and it needed 8K, not 4K.  [They have no legal hold on it, I own it outright and can release binaries to the world, and that is what is happening now; they cannot sue me, etc.{

Date handling in P?S/8 is slightly kludgy currently, but far less kludged than OS/8.  The internal implementation is that the date starts in 1960 and must be updated by a series of patches every 8 years with a three year grace period.  This must be done until it fails completely in 2099 because the code is ignorant of the four-hundred year rule, but it is Y2K and two-digit year complaint.  basically, you define what 10 decades you want to allow the two-digit form of the year, so this is even better than the usual fix of demanding a four-digit year, which also works.]  In 2000, you didn't mind that 1900-1909 was lost in terms of twi-digit years, but for each passing decade, this becomes more of a problem.

In any case, the current release is a patched-up version of the last full release in 1988 with the patched programs actively worked on through 1992 when in general I stopped working on it [first for economic but the health reasons until about 2013 or so. Now that I am "retired" I am spending all my "spare" time on all things 12-bits, etc.]

There is a one-word patch that must be applied to not crash the SIMH simulator for unknown reasons, but with it restored, it should work on the RICM 8/I. [Mike has to test it, we didn't while we were there due to some tape formatting problems he has to work on, etc. All of the relevant stuff is documented in the systen ECO log for P?S/8 Version 8Z as released in 2017.  This includes how to update the date handling, which will work currently until 2026.

I am working on a few programs primarily to either be work-arounds for OS/8 and/or PAL8, or to provide ASCII paper-tape support because of SIMH. Once that is done, I am onto the next release, P?S/8 Version 9A.

This is a cleanup release to allow a bunch of new minor features most users cannot even notice for most purposes, but is essential for further work, namely the P?S/8 SHELL which will obsolete OS/8 completely. [Note:  I could have scrapped the present P/S/8 in favor of another system that merely replaces OS/8 in major ways, but it was pretty trivial thing to just allow it "in there" and as such, the SHELL concept is used, and it is a totally modular OPTION.  Turn it off and you have the system pretty much as it has been for decades.  With the S?HELL enabled, this will be quite familiar to OS/8 users.  When done, OS/8 diehards will just be those with bad habits.  [All useful OS/8 CUSPS can be slightly rewritten for P?S/8 SHELL compatibility].

As part of the update, the date handling will be extended to a full 18 bits.  Thus the date will be valid [without kludges] from 01-Jan-1900 through 31-Dec-2411.  [I will be asking for suggestions as to what year starts the 100-year 2-digit preference years, or dare I call it "favorite century"?]

The reason for the OS/8 involvement is that presently my spec on creating P?S/8 is to avoid the P?S/8 PAL extensions and a reasonable release of PAL8 should allow OS/8 to generate the system from scratch from the source files.  While this presently does work [there are a couple of wrinkles to work on] the process is frustrated because the next step requires the use of the DTORG directive which is defective in PAL8.  [A white paper explanation of why is is not is the subject of another topic.  The sufficient answer is this: If you attempt to use it, ABSLDR cannot load the binary!]

DTORG was [foolishly, not smartly] added for the benefit of Typeset-8.  P?S/8 is also based on logical 128-word blocks which can be used so both methods of system generation can co-exist easily and allow me to migrate into a less-kludged environment.  But I have to have that fixed first, and I have an all-P?S/8 solution to the problem that allows OS/8 users to take advantage of P/S/8 PAL, namely a binary conversion program between the two systems.

There is already OS8CON, an ASCII file conversion program between the systems.  [P?S/8 also supports l6DCON, a bi-directional file conversion program between LAP6-DIAL/DIAL-MS and P?S/8, something that doesn't exist for OS/8.  [There is a broken one-way program, but it is flawed, the P?S/8 one is not, and then use OS8CON to get it to OS/8 without loss.] [Note: L6DCON only runs on P?S/8 for the modified 4K LINC-8, the unmodified 8K LINC-8 or the 4K PDP-12.

Thus, BINCOM can help my agenda, and also make certain things better in OS/8, etc.

P?S/ command formation is essentially near but not lockstep CCL without the overhead of software faking software as is the case in OS/8. [Official DEC position was CCL was NOT recommended for use on TAPE-based systems[].

However, P?S/8 commands "flow" in either of two directions, the one familiar to users of TOPS-10 and OS/8:

.PAL bin<source

and also

.PAL source > bin

Both forms work equally, use your own preference.

The SHELL will thus use CCL-like [and familiar] commands which also add the notion of traiking appended options [such as :DEBUG; the syntax is not cast in stone, but the notion is to modify the way executables are run.

Only one exit [to the standard 07600] is required, but the executable will indicate whether or not to save memory at exit.  Thus, the foolhardy notion in OS./8 of ALWAYS requiring potentially dangerous write-enable will be eliminated [as the vast majority of all execution in both systems writing is superflous.  P/S/8 creates core images by a different method, restarts are just restarts, but the SHELL will support it both ways, thus it covers all bases.

The system debugger will essentially be an adaptation of P?S/8 ODT which in terms is a 100% compatible superset of OS/8 ODT with memory dumps and multiple breakpoints added.  It will also be more like DDT so that a proper assembly can be better debugged.

While technically, the SHELL ought to at least come up in 4K, realistically it cannot do much.  [Transplanted OS/8 cusps will likely need 8K for example, but it is essentially a system that really can use 32K, but at the same time dynamically uses whatever you can give it; memory management has more "decisions" than OS/8 due to the optional components such as the Logical Console Overlay, a concept OS/8 never will have [that P/S/8has had since the 1970s].  Those familiar with ADSS/9 will at least be familiar with the concept.]

The current release is only for TC01/TC08 DECtape on TU55 or TU56 drives.  Most of the source code for the other supported configurations is available so I can create a system for such as RK8E, RX01, PDP12 LINCtape etc. and I am currently working on the TD8E with the MR8E-C ROM [because Mike rescued a surviving DECtape of it.  some of the sources were split off from the main collection and have to be recoverd while fortunately most are available completely.

The easiest one to release real soon is either the PDP-12 version or the RX01 version for 8K.  [Note:  P?S/8 supports an advanced concept:  If the system cannot run in 4K, then it requires an additional 1K of code to be loaded into the HIGHEST field of memory available, NOT always field 1.  Virtually all OS/8 12K-requiring handlers are compromised, and frankly the overall quality of aLL OS/8 handlers isn't all that good.  Proper technique and/or performance and most importantly ERROR RECOVERY is quite bad in ALL OS/8 handlers.  If you are at all familiar with the OS/8 sources, you will often seen the excuse comment "clear the world".  The polar opposite is the P?S/8 RX01 handler, which handles ALL cases of all things RK.  It doesn't handle double-density format because to do that needs the dual-identifiable trick of the OS/8 RX02/03 handler, and I have to write that code into the SHELL, but I could write one for the older RX02-only format that existed previously, just never did it.  But the RX01 handler correctly identifies the error condition of single-density command got an error because the media is double-density, etc.  Now that I have SIMH, I will revisit to support both of them eventually, etc.

Some P?S/8 handlers need a whole lot more than two pages for a system handler, so a total of nine pages does not seem all that far-fetched.  [P?S/8 does the neat trick of supporting the RK8E to the nearest logical half-sector without loss.]

The SIMH that I have includes a hack added by Dave Gesswein.  ANY 12-bit size of DECtape length is legal!  Actually all I initially wanted was to support the semi-standard 3300 block format that is sonewhat popular on premium length DECtapes, about 1/3 of tapes back in the day were capable.  This was even documented in Bob Hassinger;s OS/8 newsletter back in the day, etc.  [Bob is still around, but I don't seen hin participating in anything 12-bit.]

In any case, the SIMH of both OS/8 and P?S/8 can name their own ticket as to the claimed length of the tapes, and I am using that to advantage to assemble very long source files.  However, in the next release a feature will be implemented that makes it easier even with only standard-length DECtapes.  But it would me nice if SIMH could designate the length of a currently mounted logical DECtapoe file.

Mike has the correct release of the moment.  If you think you can use it without documentation then you don't have to wait, but bear with me, it will be worth it.

cjl

I'm just coming across this posting after having built my PiDP-8.

Back in 1976, when I was in high school, someone did a site visit to the school (Choate Rosemary Hall)
and gave us a copy of the then-current version of P?S/8 to run on our 16K single TD-8e PDP-8m.  We played with it for a while, but being high school students, we got interested in other stuff.  We lost contact with the Polytechnic Question Society, and later talked the school into buying us an ETOS system that held our interest for a very long time.

I'm very interested in reconnecting with P?S/8 and getting it going on my PiDP-8.

Alas, googlegroups does not show me a pepswin group, or I would join.

I've so far not found a P?S/8 image for simh.  Where should I look?

More power to you, Charles...

-Bill Cattey
CRH '78

On Tuesday, June 27, 2017 at 1:05:14 AM UTC-4, William Cattey wrote:
> I'm just coming across this posting after having built my PiDP-8.
>
> Back in 1976, when I was in high school, someone did a site visit to the school (Choate Rosemary Hall)

Bob Harper?  [Or perhaps Vince Perriello?]

> and gave us a copy of the then-current version of P?S/8 to run on our 16K single TD-8e PDP-8m.  We played with it for a while, but being high school students, we got interested in other stuff.  We lost contact with the Polytechnic Question Society, and later talked the school into buying us an ETOS system that held our interest for a very long time.
>
> I'm very interested in reconnecting with P?S/8 and getting it going on my PiDP-8.
>
> Alas, googlegroups does not show me a pepswin group, or I would join.

It appears there are some search problems with certain groups.  This is beyond our control.  That said, I will send you an invite to the P?S/8 and pepswin groups.  This discussion is a good topic for discussion on the former group directly.  [It comes as no surprise you cannot find the former, yer I was able to create it!  That the latter is also a problem just doesn't make much sense.]

>
> I've so far not found a P?S/8 image for simh.  Where should I look?
>
> More power to you, Charles...
>
> -Bill Cattey
> CRH '78

I need an open copy of an e-mail address to invite people in; apparently there isn't any other way to do this.  [Anyone who knows some admin trick I don't have a clue about, please help me out here for the benefit of other would-be group members.]

Anyone else here with the same desired, please also post your e-mail address here, or just send me e-mail to:

CLASy...@gmail.com

I have no problems disclosing my e-mail here, but Google "management" does a pretty good job of isolating us in that regard by default.

I will look here shortly to see e-mail addresses for any and all that apply, and then send out invites.  [Invite form has always worked in all cases]

cjl

On Saturday, July 29, 2017 at 6:18:40 AM UTC-4, cjl wrote:
> On Tuesday, June 27, 2017 at 1:05:14 AM UTC-4, William Cattey wrote:
> > I'm just coming across this posting after having built my PiDP-8.
> >
> > Back in 1976, when I was in high school, someone did a site visit to the school (Choate Rosemary Hall)
>
> Bob Harper?  [Or perhaps Vince Perriello?]
>
> > and gave us a copy of the then-current version of P?S/8 to run on our 16K single TD-8e PDP-8m.  We played with it for a while, but being high school students, we got interested in other stuff.  We lost contact with the Polytechnic Question Society, and later talked the school into buying us an ETOS system that held our interest for a very long time.
> >
> > I'm very interested in reconnecting with P?S/8 and getting it going on my PiDP-8.
> >
> > Alas, googlegroups does not show me a pepswin group, or I would join.

According to the group roster, you are already a full member with normal privileges since July 7.

Just search for Google Groups and check your current list of groups.  Should already be there.  I sent an invite for the P?S/8 group; other members had no problems from that vantage point for it as well.

Thus may just be a matter of finding groups by the proper method.  From the search it should be obvious.  [Google does keep changing things, that much is known.]

cjl

In order to get hooked into the P?S community, I opened many channels in parallel.  This thread was one of the earlier ones.  You found me on a later thread and added me to the pepswin and altpidp8 groups at that point.

For some reason, you were shown this earlier outreach at a later time.

The name Bob Harper rings a bell.  I'd not testify to 100% certainty that's who visited, but
that name sounds quite familiar in the old "Choate PDP-8 historical" bits of the dusty corners of my memories.

On Saturday, July 29, 2017 at 6:18:40 AM UTC-4, cjl wrote:

On Saturday, July 29, 2017 at 8:05:53 PM UTC-4, William Cattey wrote:
> The name Bob Harper rings a bell.  I'd not testify to 100% certainty that's who visited, but
> that name sounds quite familiar in the old "Choate PDP-8 historical" bits of the dusty corners of my memories.

You can confirm it as he is also a current group member

cjl

That was me, with Vince, visiting in 76 or 77, if I recall correctly.  I don't remember anything apart from having visited.  It would have been -8 related.

On Tuesday, March 13, 2018 at 12:51:33 AM UTC-4, bobh...@gmail.com wrote:
> That was me, with Vince, visiting in 76 or 77, if I recall correctly.  I don't remember anything apart from having visited.  It would have been -8 related.

Once it was with me.

cjl

On September 15, 2018, both me and P/S/8 will be "appearing" at the RICM learning Lab annex building.  P?S/8 will be available running on their 4K PDP-8/I with TC01 and some TU55 drives.

Also, I will be deoming it on the PEPS for Windows advanced SIMH package at the same time.  f I have time, also on RX01 hooked up to their PDP-12.

cjl

P?S/8 for RX01 was transferred to RX01 single density media on the PDP-12 and worked the first time, including the P?S/8 version of the LAP6-DIAL LINCtape formatter, which, while it did run, was not successful at tape formatting, an old problem.  This version is difficult to run on a PDP-8-based system because it uses DIAL memory conventions.  Normal loading is into such as 4000-nearly 7777.  The trick is to relocate the binary normally loaded into 7400-7777 to 3400-3777.  Program starts in 7400 with a check to see if the machine is actually a PDP-12.  If not, issue  "I am not running on a PDP-12 kind of message, etc.  [The message is 100% P?S/8 conforming and thus, even works on DECmates].  Once proved a PDP-12, a move routine is run from 4000 to move 3400-7777 to 7400-7777 and start at 4020, [also can be restarted].  Of course there is now no operating system, but at least the program is operational and DIAL was not used at all.

The main difference is the PDP-8-oriented tape format is 128 words/block not 129 words/block.  No one asked for the 129 word format; it serves no useful purpose whatsoever.  Clearly miscommunication between those who should know and those who don't care.

Both the OS/8 and P?S/8 device handlers for LINCtapes have to be perverted to support the potential destruction of a word past the caller's buffer should the tape be 129 words because the automatic TC12 tape subsystem will do either and not care and no easy way to know.  Thus, assume the worst case, save the potentially destroyed word, do the DMA of a single block transfer in the controller, then afterwards restore the potentially destroyed word, then continue, perhaps performing another block transfer, etc.  Total nuisance.

Moreover, if this word is present, this means the tape transfers tape longer, seek time is longer because each block being traversed is needlessly longer, and also means that the ultimate maximum length of the tape is foreshortened,  ?Not so with this version.

The tapes produced are generally 3300 blocks long, same as the extra-long DECtapes.  The difference is that the inherently more space-efficient LINCtapes are nearly certain to produce this length.  [DECtapes are inherently needing more tape because LINCtapes can only block search backwards, while DECtapes can transfer in reverse as well, etc.]

Thus, this is the essential source of the secondary standard of extra-long tapes.  Very select LINCtapes have been created that are 4000 blocks long, but that requires another patch and admittedly appropriate media is much harder to find, etc.

To use the longer tapes requires a one-word patch to OS/8 PIP and a tiny patch in P?S/8 that can be implemented by either P?S/8 BLKODT or P?S/8 DUMP taking advantage of the control input file command language that can automate the process.  As of P/S/8 Version 8Y [latest full release is 8Z] DUMP command files are completely supported to allow all DUMP operations [DUMP, ZAP, TRANSFER, etc. to be fully automated[.  Thus, it is actually easier to perform the P?S/8 analogous use of the increased space, etc.

I was going to put in an automatic reboot via a tape read operations, but there are two problems with this:

1) Might not be running from tape [in this case, from RX01].

2) The tape might not be working [it isn't; this system will hopefully help in that regard, but there is a lot of work to do beyond P?S/8 availability].

It was necessary to restore this version as it hasn't been available since around 1989, etc.  Now that the source matches the intended binary, improvements can be done.

Most likely, add new code in 07400 to move 07600-07777 to somewhere safe, such as 0400-05777 and place a move routine in 0200.  Thus, restart at 0200 and restores the system kernel and boot normally.  [Easy to do once you are sure you have source code!]
Note:  With slight rework, this can also run from OS/8.

cjl


>
> cjl