Is there such a person as Charles Lasner?

[wwtra...@gmail.com]

Is he live or is he Memorex?

[Stephen Jones]

<wwtra...@gmail.com> wrote:
>Is he live or is he Memorex?

I know that Charlie is 'live' and is no where near being 'memorex'
(although you may find him on dectape). He has made some changes which
may include not reading a.s.pdp8, but I don't know that for a fact. I'm
sure he would reply if he was reading and if you had a specific -8
question. :)
--
..!sdf.org!martians / SDF Public Access UNIX System / http://sdf.org

[van...@vsta.org]

Stephen Jones <mart...@sdf.lnoonsepsatmar.org> wrote:
>>Is he live or is he Memorex?
> I know that Charlie is 'live' and is no where near being 'memorex'
> (although you may find him on dectape). He has made some changes which
> may include not reading a.s.pdp8, but I don't know that for a fact. I'm
> sure he would reply if he was reading and if you had a specific -8
> question. :)

I'm in touch with him on a semi-regular basis (as are a number of
PDP-8 enthusiasts). He mostly doesn't read Usenet, but has dropped
by within recent memory. If you have anything specific in mind, I'll
be sure to mention it to him.

--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[cjl]

On Friday, October 5, 2012 at 2:48:24 AM UTC-4, wwtra...@gmail.com wrote:
> Is he live or is he Memorex?

Actually, I am available live, on DECtape, on LINCtape, RX01/RX02, RK05 and some third-party compatibles [and a bit on RX50's on DECmates II, III, III+.

I think I actually have some Memorex medie [likely .5 " magtapes or maybe some disk cartridges for non-DEC compatibles.

I have my "loyal followers" fielding questions to me while I concentrate on developing PDP-8 [and other] software [yes, seriously].

cjl

[Josef Moellers]

I haven't been able to locate you any other way ...
Eons ago, I sent you a couple of DECtapes.
Can you please contact me?
My email address consists of josef followed by a dot followed by
moellers and I am with gmx followed by a dot followed by de.

Danke ;-)

Josef

[cjl]

Any claims of my premature death are greatly exaggerated. But I have very limited time talking on forums because I am writing large amounts of new 12-bit code. Announcements will be made is due course, but not imminently. I promist it will be worth the wait.

This is the 50th anniversary of the R-L Monitor System. And P?S/8, unlike OS/8 can set today's date correctly.

[Klemens Krause]

cjl wrote:
...

> This is the 50th anniversary of the R-L Monitor System.
> And P?S/8, unlike OS/8 can set today's date correctly.

I wonder, if I'm really the only one in this world, who faced this problem
in 1999, nearly 20 years ago?

.
.VERSION
OS/8 - KBM V3Q - CCL V1F

.DA 7-MAR-17

.DATE
TUESDAY MAR 7, 2017

.DIR SYS:CCL.*,FOTP.*,DIRECT.*,PIP.*,PAL?.*

07-MAR-17

CCL .SV 18 03-DEC-13 PIP .SV 11 03-DEC-13
FOTP .SV 8 03-DEC-13 PAL8 .SV 19 03-DEC-13
DIRECT.SV 7 03-DEC-13 PALX .SV 19 03-DEC-13

6 FILES IN 82 BLOCKS - 1578 FREE BLOCKS

.R PIP
*SCREEN.TX<PTR:
^

[Johnny Billquist]

Wow, Charles... Long time no see. Nice to see that you are still around.

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]

On Tuesday, March 7, 2017 at 8:00:01 AM UTC-5, Klemens Krause wrote:
> cjl wrote:
> ...
> > This is the 50th anniversary of the R-L Monitor System.
> > And P?S/8, unlike OS/8 can set today's date correctly.
>
> I wonder, if I'm really the only one in this world, who faced this problem
> in 1999, nearly 20 years ago?

No, we all suffered through the REAL problem, this is some lame problem that obfuscates the real problem.

>
> .
> .VERSION
> OS/8 - KBM V3Q - CCL V1F
>
> .DA 7-MAR-17
>
> .DATE
> TUESDAY MAR 7, 2017

I never tested the defective code to see if it could be even worse than we knew.

First layer of the problem [which your printout below confirms, not that the junk output is even meaningful].

OS/ ONLY supports the date in the range of 1970-1977. This is inherently partof the design and CANNOT BE FIXED. Delusions aside, this is the absolute fact.

Now to the delusionary add-ons.

I know the people who did this design personally, I was nearly suckered into working on it, and fortunately I refused because inside of DEC back in that day, the idiocy of managers reigned. the inherent short-sighted mediocrity was baked in and non-removabe. [For those who don't know me well, I am a glass is definitely half-empty person, unfortunately, if you are the other half, you suffer for it when it comes to OS/8.]

Various heavy users of OS/8 who even liked it [as opposed to people like me who merely tolerated it and also did something about it to get around much of the problems, in fact it grew to be a model of what NOT to do] warned my lazy friends about the upcoming problem because on TOPS10 they had their own expiration issues known historically as DATE75. By scrounging bits in the various directory formats, they were able to give a "new lease on life" on their analogous problem to work far into the future.

But despite all that warning, the initial reaction was just ignore it and it will go away; it didn't.

A PROPER fix to this problem is about a 4-layer issue:

1) What became OS/8 was initially a literal weekend hack [we as a group are night-owls and binge-workers, but a week-end is still a week-end.

A few good ideas, lots of really crap ones, and a lot of crap code to bind it together into something that LOOOKS good to show to the dim bulbs in charge who among other incredibly stupid things they did was to just not listen to anything about the R-L Monitor, also written by Richard Lary, who did most of the week-end brainstorming. I had the dubious distinction of meeting one of these "brains" some years later at a DECUS symposium hoping that he had an open mind; instead I found a large absence of one. What I was there for was hopefully he had had a favorable reaction to the R-L Monitor because what I am known for, the alternate O/S for the PDP-8 is P?S/8 the outgrowth of the R-L Monitor System and maybe setup some dialogue, etc.

Unfortunate, he revealed something quite embarrassing which I won't embarrass the guy by naming him. In essence, he was hung up on the relatively trivial "modifications to the DECtape Library System" which is just about the most unimportant topic in this area you could think of. This is a "system" that lacks what anyone can call a "file system" at its core; these were just kludges to make it slightly better and modestly more functional than the original, which is just a core-image saver, literally nothing more.


Details aside, the point is this pathetic "manager" was incompetent to understand ANYTHING about the R-L Monitor [which today can can be likened to a "diamond in the rough" so to speak. I actually wrote a small part of it, the support for passing input files to FOCAL, 1969 as the redirected input from the console during the phase of reading the contents of the files, and then when all the files are read, reverting to the usual FOCAL input from the 03/04 console, etc. It was a nice effort, but no big deal, but I get my two-cents worth of claim about the R-L Monitor System, the rest of it is the work of people far better than I was at the time, etc.]

And later, so much of this historical stuff is told in hindsight, I found out indeed R-L was rejected by this gut and has buddies, all of whom were pretty bad, and as must of us know, DEC's downfall was supremely bad management, and I'm sure many can cite their own examples of same, etc.

Thus, instead of being able to attempt to introduce him to what progress had been made in severely improving R-L on the way to being P?S/8, it was obvious it was hopeless, and frankly I was dumbfounded and didn't know what to respond, so I just thanked him for his time and left.

Why bring this up, because he was a typical example of a small group of small minds that did this: The demo done over a week-end was Richard Lary's direct work in that short a time, with encouragement and some suggestions from his four friends who are hands down the best PDP-8 programmers there ever were up to that time, bar none. And I studied only part of what they did. Richie did many things for DEC, many not even 12-bit oriented.

The point is the demo was supposed to be nothing more than, uh, a demo! They came prepared to scrap the short-work and have a second system that would LOOK like the demo, but be a lot better. These idiots rejected that and insisted the demo be maintained! [This is monumentally stupid! As a manager of talented people, you should take their advice; instead they over-rode the best technical minds available, but enough on the stupidity of bad management for the moment.

As a result of this, the other four refuses to work on it knowing just how much was wrong with it.

Soon thereafter, I got a phone call from Richie [we all knew each other because we were all within two years of each other at Brooklyn Poly; the common threat was the original straight -8 there: 4K and a single TU55 on a TC01, etc.]

He wanted to recruit me and I turned him down. He couldn't fault my logic: I told him we [there were some others at the time, and they are also early contributors to P?S/8] were starting over from scratch in terms of the source code and making R-L even better, documenting it [the first system documentation varied from extremely poor to non-existent. In fact one of our first efforts was to write some stopgap documentation on how to use it; we had learned from Richie and each other, no manuals at all!] And then it was renamed MS/8 and submitted to DECUS; you should be able to get a copy of it; it can run on the SIMH simulator as is, etc. but for me, it is the "grandfather" of more recent P?S/8, although a few things we retained compatibility here and there, and in no way made it worse, etc.] So, even at that point, Richie could not fault me for working on his unpolished gem of a work instead of the new thing forced to continue the piss-poor demo. Yes, I was tipped off by one of the four of them; we all periodically spoke to each other consisting of trips to Maynard Mass or one or two of them coming to the school and we went out for Chinese food, etc. This is the camaraderie of a group of friends, all of whom are connected by the PDP-8, etc.

Eventually, some of the group did go to DEC to work with Richle on PS/9 later renamed OS/8. The rest stayed in the New York area, became employees and/or consultants on various projects perhaps some have heard about, etc. But we all did work incrementally on P?S/8, although eventually it all fell upon me to continue with it and eventually it was virtually all my work, etc.

The demo had a good idea and a bad implementation of related portions.

The OS/8 directory started out with the boon-doggle notion of a linked-list directory, sounds good in theory, but because of the half-asses nature of the design, this is what you have:

a) the linked list is superfluous. The actual physical sectors are sequential. The linking is implicit. The structures are redundant to the inherent limitation of the design and only lead to inefficiency maintaining the superfluous nature of the structure.

b) The length allocated for the directory is neither fish nor fowl. If you have a small DECtape directory and all of your files consist of just a few relatively large files that fit on a DECtape, it is cute to be able to print them out on a piece of teletype paper and stick it in the DECtape cannister, but if you have applications that require tons of modules as say some Fortran projects and the like, etc. You cannot likely get all of them on the DECtape. Certainly, you cannot get them onto larger devices such as the RK05. OS/8 has the dubious distinction that for many people, the DIRECTORY runs out of slots BEFORE the underlying storage!

c) The directory links must be maintained as is. As such, as a practical matter, the size of the directory can neither be shortened nor lengthened. The DEVICE length can be defined, and even then only by a klduge; a table maintained inside of OS/8 PIP, but the directory HAS to be just what it is, and nothing else.

In the directory structure, there is a potentially acceptable feature called the Additional Words count. The default is one word. This is used to hold the 12-bit value of the date, which for the period 197-1977 is perfectly fine, and worthless if you want to make the date "lifetime" larger.

Many people faces with the storage going to waste due to the small capacity of the directory opted to remove date support completely. This got a few more files, but clearly this was out of desperation.

Since this short-sighted "feature" was never thought through, the directory could not get anything other than 12-bits at a time more.

Now let me show you the P?S/8 alternative which is 18 bits:

In P/S/8 one 12-bit word also stores the low-order 12-bits of the directory, and is essentially comparable [with some lessor improvements, smaller issues, etc.] but more importantly there are six more bits for the upper range of the date.

This allows the P?S/8 Version 9A [the up and coming release] to handle any date in the range of 01-Jan-1900 through 31-Dec-2411.

This is better than just about any other computer system you can name [including unix which dies in 2039, which now doesn't seem all that far away, does it.]

The fallacy is that with just a few more bits, so much more can be accommodated; no excuses allowed. [Note: P?S/8 date handling is undergoing revision, the current version is Version 8Z; it "only" goes from 01-Jan-1960 through 31-Dec-2099; but I found a better way to implement it.]

So, back to OS/8, simply no excuse; the directory needed to be modified and they had over two years to fix it; they didn't fix it, they instead kludged it to fool people for awhile.

Scrounging could only yield TWO bits. Thus, in theory, that means the date can be from 01-Jan-1970 through 31-Dec-2001. This is mythical but the cosmetics as part of the kludge do support that.

Apparently there are more bugs in implementing this than I know, but I never tested what you attempted. Back in the day the smaller issue was the Y2K problem and indeed some OS/8 programs print out badly past 31-Dec-1999, but if bug-free should work to the end of 2001. BUT NOT MORE THAN THAT!

But let's go back to the actual kludge and what you get as a result.

in the original system it was clearly uniquely and non-anomolously 01-Jan-1970 through 31-Dec-1977.

This was COSMETICALLY modified to obfuscate the problem:

All of the new programs concerned with the date created a fiction:

All dates are DECLARED to be either this year or one of the previous seven years.

In 1974, COS-300 was created as a form of "shell" over OS/8. COS-300's user interface is based on the DIBOL-8 user interface.

However, DIBOL-8 IS IN FACT the R-L Monitor with the names of the commands hacked up to allow what in P?S/8 we call concise execution commands. this is a simplfied "cousin" of CCL but it has no overhead, and in fact is quite similar to some newer systems from DEC released past OS/8, which was hopelessly and slavishly imitating the growing pains of TOPS-19.

Thus, by the time COS-300 came out it was in fact imitating P?S/8. [Remember, we all knew each other and at best this was a friendly rivalry; my lazy friends knew I was doing a better design than they were just heaping mediocre code on top of, but they didn't care, unmotivated largely because of these incompetent managers; good and talented people have to be motivated; when you don't, you get OS/8.]

COS-300 was aware of the same problem, but a different kludge was done. They changed the base year to 1974, thus in 1978, no important change occurred there, and the VT79 had come out, and the marketroid nonsense of OS78 and other hijinx. thus, to the user clueless user, it SEEMED to be fixed, after all if you set the date to 1978 it worked, right?

WRONG!

We were first developing P?S/8 on TOPS-10 and that was in 1967-1971. In point of fact, the real date of our early files could NOT even be properly represented in the original OS/8, much less after the kludge; our 1970 dated files DID NOT fair well in this kludge.

So, on 01-Jan-1978, we had files that appeared to be IN THE FUTURE because they were really from 1970 and not 1978 at all!

As the years wore on, the deferred consequences of the ugly kludge got worse, not better.

Today, when I have to archive OS/8 files, I have a caceat: OS/8 is NOT capable of an accurate rendering of the date of these files. That said, some people have PERSONAL KNOWLEDGE of the actual date or approximately thereso such that we can PROJECT them, and as such, an OS/8 directory was taken and then EDITED to become something OS/8 is incapable of, but is more ACCURATE than OS/8 and just based on the format of the output of the OS/8 DIR command.

And depending on the system, actual file dates are provided, but because of widespread use of MS-DOS/Windows, dates prior to 1980 are known to be incorrect. as such, the date is set to 01-Jan-1980 at 2 seconds into the day. This is the minimum practical date in Windows and will lead to a printout where the date is left out; best that can be done there.

This is why it is so important for P/S/8 to support that much wider date range. Files that are from the dawn of the 12-bit computing era [generally considered 1960 with the introduction of Seymour Cray's CDC 160] can be accurately files on P?S/8's new SHELL directory [a work in progress; the point is this aspect of it is perfected, not hatched like OS/8. never paint yourself into corners!].

The problem is now properly discussed, and I know most never expected that it would take this much detail to debunk this and remove all of the obfuscation.

this would not have happened if two more dim bulb managers hadn;t made more bad decisions.

While around 1967 these fools rejected the R-K Monitor out of sheer incompetence, the R-l/P?S/9 "story" was told in-house by those from Brooklyn Poly who told their colleagues in the 12-bit development group. All of them, as was I, cut their PDP-8 "teeth" on that system, and eventually there was a desire by the programming staff to have a chance to work with it. One of them arranged a demo of the then-current P?S/8. I came to DEC and demoe'd it and they were quite impressed by it.

However, the arrogant manager [I am tempted to name him as well, but I won't] asked me ONE question about it:

P?S/8 is a system that runs in a MINIMUM of 4K. Various programs and optional modular components can take advantage of more, even up to a full 32K if available.

I honestly answered 4K. He refused to talk to me further and was rather nasty, because he felt that his staff had "totally wasted his time". I later found out the real reason:

He only liked OS/8 because it forced the sale of more memory. Remember, many of the earlier models were hard to get to 8K with the extended memory controller upgrade, etc.

Thus, his official internal decision was that he didn't want it because "it would discourage memory sales".

Many of you know that depending on the program, even 18K may not be enough; the minimum memory is a worthless yardstick. And moreover, when the PDP-8/A came out, a lot of machines night have even less memory [or some ram/rom combinations]. Clearly a smaller memory footprint system to act as at least a program loader would be useful for that part of DEC's markiet. That was the FIRST time.

Somewhat later, i organized a "shootout" demo where I showed them P?S/8 running on a few TC08 TU56 drives. I said they can use OS/8 on the RK8E. Some of the snarky ones laughed at me. [Later they weren;t laughing].

I gave them the choice of source file; I asked them to put it on an OS/8 non-system DECtape. I believe it was a current work-in-progress piece of CCL, etc.

Then I assembled it to produce binary and a listing and we agreed I could turn off the listing output to save paper, and time the demo as up to when the LPT output started [the printing time ruins the comparison, and we agreed that was fair.]

The results were this: OS/8, despite running on much faster media [RK05 drives] took one half the time to get the result from PAL9 as P?S/8 and P/S/8 PAL did on DECtape despite the much slower media. [At this point, one of the snarky ones was no logner so snarky].

Then I turned the knife in the wound. I asked them to time loading the binary file just assembled into memory with ABSLDR. The time stars from the commend-deooder prompt and typing the file, start when you hit CR to start the loading and ends at the dot prompt afterwards.

Using the P?S/8 equivalent, while running on DECtapes, P?S/8 in fact loaded the same binary content into memory TWICE AS FAST as the OS/8 and RK05. At this point, Mr. Snarky had nothing to say and a bewildered expression on his face.

Then we went to the then-current manager; he hadn't paid attention, didn't care and refused to comment, just go away, I'm not interested. this of course was totally insulting to his programmers; great way to manage your people, idiot!

It was hopeless;

So, later I was contacted by one of Richie's comrades from back in the day; He had quit DEC but then worked as a consultant on many projects, including what became known as as 4K BASIC which is the basis for 8K BASIC, etc. and many other things.

He got me in touch with the project leader inside of Intersil that developed the IM6100 PDP-8 on a chip that later became the innards of the VT78.

Intersil had just produced a slightly better machine, based on static CMOS memory and a full-speed chip and capable of up to 32K in increments of4K each memory module having battery backup on board. This is known as the Intercept I and there is a kit form from Pacific CyberMetrix called the PCM-12 PCM12-A if wired, it's a semi-kit otherwise.] It used the DSD-210 superset of the RX01; it can handle up to four drives and can actually FORMAT 8" media, no DEC system can do that. [Note: Changing the media density to/from single or double is NOT formatting; it's just the misleading name of the associated OS/9 CCL command. Unless the media is already formatted, you cannot perform the OS/8 operation. The DSD-210 can format a magnetically wiped diskette and in fact that is recommended beforehand.] There is also an Omnibus interface for this hardware, etc.

Long story short, I signed a royalty agreement with Intersil for just the then-current P?S/8 configured for RX01/DSD-210 with up to 4 drives, which also supports the VT78 with up to 4 drives, and ON THE VT78, runs at least THIRTEEN TIMES AS FAST as OS/8. this is because on the VT78, OS/8 suffers from rotational latency; P?S/8 does not due to superior handler design [that necessitates it running in at least 8K, not 4K]. Typical Intercept configurations were 12K so the poor=performing OS/8 for RX01 could also be used, but that was outside of the license agreement. They got only then-current LPT listings on paper, no sources and no support whatsoever. Thus, I retain all rights to P?S/8 to this day.

And what did DEC do when they heard about this? They were going to SUE ME because they ASSUMED no one outside of DEC could have written another operating system, thus I "must have" stolen it from DEC [not in the slightest with the exception of FOCAL, 1969].

All potential customers of what Intersil called the Intercept Floppy Disk Operating System [IFDOS] were first required to either purchase or sign an agreement that they had in their personal possession not only FOCAL, but an entire kit of the "paper-tape operating system" which includes PAL III, EDIT, a copy of the BIN loader, etc.

DEC sold those kits to Intersil and Intersil sold them directly to customers so that lesser machines could do some software work, etc.

I documented that P?S/8 FOCAL is FOCAL, 1969 with a massive overlay to make it work with P?S/8 BINARy and TEXT files, etc. And it is created by first loading the FOCAL, 1969 binary followed by the binary output of the P?S/8 PAL assembly of this overlay code, then the result is written to the P?S/8 system device.

Further, I provided them with a copy of FOCAL, 69 captured into P?S/8 TFS [Tiny File System[ binary files and the binary output of the assembly of the overlay, and a short P?S/8 BATCH file that creates the system program P?S/8 FOCAL pragmatically for that particular configuration, etc. [Note: P?S/8 BATCH, like the R-L Monitor BATCh before it, runs in 4K. OS/8 BATCH is a kludge added on later than requires at least 12K, and worse, it steals 4 words from the system handler extension such as the RX system in question so the code has an added burden of requiring being written into a slightly smaller space than otherwise/]

Thus, these are already licensed users of FOCAL, and all other code has noth9ing to do with DEC.

Fortunately, one of the people in the group now working for DEC explained all of this to the lawyers, but what cinched it was they were told that DEC turned the software down, not once but twice! Thus, I never was actually sued, but over the years there were some sore points between me and bad managers; I simply do not suffer fools, etc.

In any case, that was 1978, and very active P?S/8 development continued into about 1990 when having the PDP-8 as the source of your livelihood was becoming economically impossible, and in fact I was mostly working on Kermit-12 for OS/8 to allow files to be interchanged more easily, and that has paid off to this day as there are people using my Kermit-12 utilities even now.]

But I stopped working on 12-bit code altogether in 1992.

In 2007 I had the start of some medical problems, that still plague me today. The short answer is it won't kill me. And about then I started writing notes to myself about how to expand P?S/8 once I got my act together again, etc.

By 2013, I started working with others on the SIMH simulator for the PDP-8 and actually started working on some new code, some foundational fragments, and some bug fixes and improvements on the last whole release of Version 8Z first released 23-Feb-1988 with a lot of small patches for a few years, the last incomplete work has a date of 1992 on it, etc.

More recently, I have made even more changes to P?S/8 and the first stage is fixing some bugs and making changes in preparation for a new release to be known as 9A, although I don't have an exact time-table, I do know most of the issues now, so this should be forthcoming, but I have a reason for delay:

while I have been working on P/S/8 as described above, I have also been spending a serious amount of time [I have time now, as I am "retired" whatever that means] on major improvements to not the innards of SIMH so much as the overall environment and peripheral utilities and components that transform SIMH as released into a serioud development environment that I can consider worthy [I have very high standards and as such I am my own worst critic]/. I see an end in sight, including I would say a pretty good amount of functional documentation. [My my own reckoning, it is superior to the equivalent in DEC's documents of OS/8 in terms of useful details.]

Thus, this will be a major "shot in the arm" for 12-bit productivity and addresses many very real issues a PDP-8 programmer faces; this was not on the minds of the writers of SIMH; what they did is great but it is not a total solution, just a great "heart" of something much larger.]

While I do not have an exact release date, it will be capable of elegantly running editing sessions in Windows, it is very much Windows-dependent, and passing files back and forth between OS/8 V3D with patches and extensions fro me and others, AND P?S/8 Version 8Z patched to date, which is an imperfect solution, but it is the last stable release, although there is a little more work needed on it; so it may be replaced later in newer still releases of the package, but the overall goal is to replace it first with 9A and then the next phase of P?S/8, which is the P?S/8 SHELL. But I will release 9A when the functionality is hardly different from the current 8Z, but all the prep work for the SHELL has been done, etc.

For those who are not familiar with the goals of the P?S/8 SHELL, here are a few particulars:

1) An alternate environment for ALL OS/8 CUSPs and P?S/8 basic's system programs. It is not binary compatible with either, but a reasonably short source code change will accommodate all such programs. [The internal goals are quite similar to the CALLS of OS/8, but not the implementations.]

2) A far superior and dynamically adjustable file system that can be scaled up or down as necessary.

3) Full 18-bit date support for all files.

4) Superior execution models to prevent the wasteful saving of memory when it is superfluous which is the vast bulk of the practical number of instances. Programs under development can set saving and debugging options. The debugger is expected to be a superset of P?S/8 ODT which in turn is a proper superset of OS/8 ODT plus features taken from DDT. As with P?S/8 basic, overlay structure will be defined.

5) As with P/S/8 basic, a superior command-line model that is based on concise command formation. The notion of CCL is superfluous if the system doesn't depend on a command-decoder routinely. However, one will be available for the few programs that make good use of the mechanism; but recognition that these programs are in the minority.

6) While in theory the SHELL runs in 4K, as a practical matter, most command will gracefully inform that more is needed; this is a fluid dynamic situation because available memory is defined from 4K on up to 32K and many points in between; this is in part due to the modular optional components of P?S/8 including the Logical Console Overlay, a conceptual feature OS/8 never could have and is already available in the basic P?S/8. No component of P/S/8 raises the minimal memory beyond 8K, but performance is generally more like 4K, and that may be inadequate depending on program requirements. Practical memory sizes suggest that 16K is a nice amount of memory for many purposes, and as much as 28K could be required for certain specific operations, and actually if all are enabled at once, 32K would be required.

7) SHELL filenames with be 12.4, and the filenames will be case-retentive, similar to OS/2. you can ignore the case in all contestx, but the original case of the name is ratained and can be used optionally for cosmetic purposes such as a "natural" option of directory printouts. Notice that this is exactly twice the capability of OS/8's file system names notwithstanding OS/8 is upper-case only.

8) Clever memory management means the actual SHELL is extensible and can be moidular if it takes advantage of the basic P?S/8 system program overlay structure. Indeed, SHELL will be a basic P?S/8 system program. Running it will be able to configure the SHELL [turn it on or off] as one of the ways to initiate it.

9) A new low-level monitor will be added shortly in 9A to prevent configurational loss of control. Pressing Control-D when the system is loading enters the low-level monitor instead of whichever system component would normally load. This will allow controlling Logical Console and Shell configurations including deleting either or both, and stop BATCH processing in progress thrown in for good measure [which is usually not a problem]. This is primarily needed to prevent problems such as moving a live P?S/8 system to where the required hardware for the Logical Console Overlay doesn't exist; it will no longer be either required to have the requisite hardware if relevant and/or stop the machine and make manual patches in memory in perverse circumstances if this was not disabled prior to the moving of the media/system, etc. [this was a small sore point; some Overlay configurations needed such as the VT8E, and by mistake the overlay was enabled yet the system was brought to another machine; the low level monitor prevents this from being a problem.

8) Far superior non-system handlers are used for all SHELL file operations. This eliminates a conceptual flaw of OS/8 I have had reports of actually happening:

In OS/8 FOOLISHLY ALL calls to all handlers are formed identically. To a newbie, this sounds like a great design. IT IS NOT!

All OS/8 handlers require an error exit handler. MOST situations this is useful, but not ALL. There is one that is quite fatal:

The last operation of OS/8 initiating execution of all programs is to act on a call places within the system kernel. If there is an error on that last read, there is a fatal HALT. There is no possible recovery. The system must be rebooted, and this is not generally known, which of course gives credit to the general reliability of most DEC hardware [at least when new; today more people are experiencing errors we didn't see before].

Thus, if this particular call fails, and you press CONTINUE, you may very well corrupt not only the system in memory, but actually damage the contents of the system device! There simply is no room for ANY form of error handler; how could there be since this is a very limited system kernel never designed to handle it!

P?S/8 fares differently on this same general problem.

All P/S/8 SYSTEM handler calls do not support an error return at all! Instead, when there is an error, there is an internal HALT within the system handler. As in the R-L Monitor before it, pressing CONTINUE is ENCOURAGED as this is a SAFE halt intended to be retried, and generally it recovers completely. the classic example is write-protect the DECtape drive, try to write on it, the HALT happens, enable writing, then press CONTINUE and it succeeds.

If the Logical Console Overlay is enabled, the system does not halt at all, instead a nice screen of particulars of the failing call is displayed on the Logical Console device [which may differ from the 03/04 console] and screen options exist to retry or abort/exit to 07600 to restart P?S/8. [Yes, we had that before MS-DOS, but actually it originates in the ADSS/9 system for the PDP-9/15. it's known as an IOPS4 error, but the cosmetics of the newer P?S/8 one are better, and judge for yourself who ripped off who :-). Some other aspects of P?S/8 were ripped off by CP/M-80 and MS-DOS.]

All of the operations of the SHELL internally use the system handler. It allows access to 128-word blocks 0000-7777 [or less if no more exist] on logical units 0 through 7, which on TC01/08 DECtape is all 8 DECtapes. The handler is always there, nothing to load, ever.

Admittedly, for any one logical unit, this is 1/2 of the storage space covered by a corresponding OS/8 device. [But then again, there could be 8 of them which is four times as large!].

But all of that is moot in the SHELL. The SHELL FILES are accessed by non-system handlers which are partially conceptual cousins of OS/8 non-system handlers with the following exceptions:

a) OS/8 non-system handlers must be loaded into field 0. P/S/8 non-system handlers can load into any available field as they are both page and field relocatable.

b) OS/8 non-system handlers are limited to at most two pages. P?S/8 non-system handlers can be as much as an entire FIELD long, although most are one-four pages. The RX01 P?S/8 handler is far superior to the OS/8 equivalent in many ways; it is three pages long.

c) The blocks are 128 words long, not 256 words long, thus the minimum buffer size is one page; in OS/8 it is at least two, and only multiles of two up to thirty are allowed. In P?S/8, one page is fine, and any number up to 32 is allowed. [This is because P?S/8 does not restrict access to any last page in any extended memory field. System kernel indicates will indicate the memory resources available; no program has to calculate it by itself, an annoyance in OS/8. At most, all of the highest field of memory is off limits, perhaps less. But any program can dynamically determine this. But other than that, assuming extended memory exists, all extended memory fields from 1 though that upper limit are 100% available to programs, thus you can have 31 or 32 pages available to a buffer when accessing a non-system device.

d) The call is organized only a partial in-line argument mechanism. The call points to the basic argument list; it can be useful to place this on Page Zero when performing practical reading and writing, minor but the right thing to do.

4) OS/8 can handle as much as 4096 records of 256 words each. While the basic P?S/8 system handler can only get to 4096 128-word sizes blocks, the P?S/8 non-system handlers can access up to 2048 times as much storage per logical unit. Assuming six-bit bytes, the conceptual scope of a P?S/8 non-system handler is up to about 32 GB.

As a practical matter, P?S/8 can handle all four RK05 drives as RK0:, RK1:, RK2: and RK#:. this is all from one handler. Each of them appears to be a set of 128 word blocks in the range of 00000-31277. OS/8 can only have one handler to address one half of one drive.}}

moreover, there is space in the handler to support the RKS8E modified RK8E/RK05 controller. I am seeking documentation on exactly how it implements the extra bit of addressing that gets support up to EIGHT drives. I also need to know how to tell the hardware is an actual RKS8E to avoid spoofing the handler, but there is plenty of room in the handler to dynamically figure this out. [But I do need a fool-proof method.] It would be nice if someone knows more about the full definition of the modifications. OS/8 plays it safe and just has lamer separate handlers, etc.

The OS/8 non-system TD8E handler can access at most two drives. But there is a definition for as much as four TD8E's in any one system, and back in the day I saw one of them four TU56s on the machine and four TD8E cards. The P?S/8 non0-system TD8E handler can handle all of them.

When you can have as much as an entire field for the code of a non-system handler, writing excellent handlers is readily possible, not that I encourage sloppy code or too-tight code written out of desperation with serious performance and/or configurational and/or error recovery issues. It's just that two pages is generally compromised for just about any device that needs more than one page, the TD8E non-system OS/8 handler comes the closest to not being cramped, but with a little more space I can do so much more.

That's a taste of what the SHELL can do. Currently there is only one non-system handler-aware program in the basic P?S/8 version 8Z; it's P?S/8 BLKCPY which is an excellent copy and/or compare program for any number of blocks copying from anything to anything.

Since P?S/8 non-system handlers each handle 8 logical units, there is generally far less need for handlers by head count. OS/8 effectively only has 14 handlers, because of the reserved SYS and proxy DSK handlers in the defined 15 maximum. I have often had to constantly reconfigure OS/8 and have mutliple aved copies of OS/8 BUiLD, etc.

But with each P?S/8 non-system handler inherently handling up to 8 logical units, it is easier to support far more handlers if need be.

In TOPS-10, there is the DTA handler and it takses logical unit arguments 9 through 7, and P?S/8 does the same. OS/8 treats DTA1: as a handler, and DTA0: is a different handler in that 14 maximum allowed, etc.

That is just a taste for now, but I wlll be releasing a system fairly soon [perhaps in April] P?S/8 by nature is always a work-in-progress, but here is something telling:

I mostly had to use OS/8 for the benefit of longer files; P?S/8 TFS files are only useful for small to medium projects; on those, P?S/8 is far more efficent to edit, but random access editing of files has to be gotten used to, and admittedly there are personal preference issues here.

But I am a "power user" and I must have files so large they tax OS/8. The source code of P?S/8 PAL overflows OS/8 CREF even with the "mammoth" option set, and this is after I did a concerted effort to "balance" the symbols to optimize to handle the CREF mammoth option quirk. [For those who are not familiar, OS/8 CREF has a forces half-point of the exact symbol named KGNNNN. Thus, you could have an acceptable total number of symbols, but too many in one "half" etc.]

But CREF cannot completely handle it, period. OS/8 has become too limited for me.

Routinely I use P?S/8 PAL exclusively, so now I hardly need OS/8 at all for my personal development usage, but it is still there for some minor quirks and stopgap measures [one of which will be shortly eliminated caused mainly because of the SIMH environment]

And I use host-environment editing and post-processing facilities. I can edit files in Windows using notepad, editpadlite7, or TECO as necessary. While I can use OS/8 TECO, it is actually more work to do so. Also TECOC for Windows is a slightly better TECO and I need some of its features for other parts of the package, etc.

Thus, after a "small interlude" I am back and more productive than ever. [There is a whole lot more, but this is just a warmup for some time later.]

cjl

[Bob Eager]

On Wed, 08 Mar 2017 00:25:53 -0800, cjl wrote:

> OS/ ONLY supports the date in the range of 1970-1977. This is
> inherently partof the design and CANNOT BE FIXED. Delusions aside, this
> is the absolute fact.

As an aside, DOS/BATCH was even worse; it could manage only 4 years, 3
months.

[cjl]

Really? 1980 first second of the year died less than five years after that?

In any case, it seems to be doing fine.

I maintain my files in Windows using the full-length names that the P?S/8 SHELL will support. In terms of notation, P?S/8 TFS files are 6.0, OS/8 is 6.2, RT-11 is 6.3 [and TOPS-10] and MS-DOS is 8.3. P?S/8 SHELL is 12.4 with case retention same as OS/2.

In any case, if the true nature of the file date is prior to 1980, I set it to 2 seconds into 1980 so that it comes back with a clear date at all. The readme file explains the reality.

If the files happen to have an OS/8 history, I use the OS/8 DIR printout hand-edited into what OS/8 could never actually accomplish.

You can find portions of this on the sunsite archive now at ibiblio.org that I maintain to this day in the

http://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/

area. Unfortunately, they shut down anonymous FTP for their definition of "security reasons" and as such I can take submissions as attachments to

las...@sunsite.unc.edu, the historic e-mail associated with the collection. [Actually it's now a gmail account with two-step verification; they insist, etc.

The "old" P?S/8 date was from 01-Jan-1960-31-Dec-2099 but I am upgrading it for the next release to anywhere uniquely from 01-Jan-1900 through 31-Dec-2411.

Unlike OS/8, I think that will hold us for awhile.

cjl

[Bob Eager]

On Fri, 24 Mar 2017 23:41:45 -0700, cjl wrote:

> On Wednesday, March 8, 2017 at 4:22:23 AM UTC-5, Bob Eager wrote:
>> On Wed, 08 Mar 2017 00:25:53 -0800, cjl wrote:
>>
>> > OS/ ONLY supports the date in the range of 1970-1977. This is
>> > inherently partof the design and CANNOT BE FIXED. Delusions aside,
>> > this is the absolute fact.
>>
>> As an aside, DOS/BATCH was even worse; it could manage only 4 years, 3
>> months.
>
> Really? 1980 first second of the year died less than five years after
> that?
>
> In any case, it seems to be doing fine.

I was using it in late 1973. We found it stored the date as a 12 bit
field. OK, you may think, but:

date = (year-1970)*1000 + day_in_year

So it broke around 6th April 1974. I think they found another bit to use,
then redesigned if it was still going. We patched it to convert to a 2
yera window either side, and re-patched every year.

[Johnny Billquist]

(year-1970)*1000 + day_in_year was also used in RSTS/E. I wonder if they
still do (I suspect they had to change it at some point around the year
2000...)
Paul Koenig would know.

I always found that way to store a date extremely bad, even if it was
simple to use. OS/8 is just as bad, but in other ways, as have been
covered here now. :-)

I wonder why DEC had such a broken approach to dates back then.

[Klemens Krause]

Johnny Billquist wrote:
...

> I always found that way to store a date extremely bad, even if it was
> simple to use. OS/8 is just as bad, but in other ways, as have been
> covered here now. :-)
>
> I wonder why DEC had such a broken approach to dates back then.
>

I think, this is caused by the expensive hardware (core-memory) and
limited storage media (RK05, DECtape) at that time. More bits for the
date need larger directory tables in memory and larger directory
entries on DECtape and RK05 disks.
A minimal directory entry under OS/8 uses 4 words for the file name
and one word for the file length. (No date!).
That means, in the given fixed length of 6 directory blocks on
a DECtape or RK05 disk, a maximum number of 288 files can be assigned.
If you spend one additional word for the date, the number of files a
directory can hold, is reduced to 240.
This is the standard in OS/8. In the 12 Bits of this additional date
entry, you can either encode the date in the way OS/8 does, using
4 bits for the month, 5 bits for the day in month and leaving 3 bits
for a period of 8 years.
If one would encode the date in full binary form, 4095 days from a
starting date, this would work for a little bit more than 11 years,
not really solving the limited date problem.
DEC "solved" the problem in OS/8 V3D, by adding a global date extension
in the system: 2 bits in memory word 07777.
This leads to the known "modulo 8" extension of the years to 4 * 8 years
with the constraint, that the OS/8 cusps don't accept and print out
years above (19)99.

When the year 2000 came in sight, I faced this problem and looked for a
simple way to fix it. And the simplest way at that time was, to add
an additional bit to the year extension in word 07777, giving a 8 * 8
year period. This is possible by the leapyear anomaly of y2k.

To accept this additional "year-bit", I had to modify the programs which use
the date: the command-decoder, DIRECT.SV, CCL.SV, PAL8.SV and some others.
This is not perfect, but it allows me, to get a directory or PAL - listing
with the actual date. If I'm still interested in OS/8 beyond 2033, I could
assign another bit in 07777, then reaching year 2097. :-)

The better way to handle this problem is naturally to add a second additional
word in the directory entries.
Having two additonal words in the directory entries instead of one additional
word for standard OS/8 date would reduce the number of possible directory
entries to 204.
The second additional word would contain the absolute year in 8-year steps
1962, 1970, 1978 ... thus allowing to date-stamp a paper-tape from 1960 correctly.
A system without this extension would simply ignore the second word, falling
back to the "modulo 8" dating.
And a user, who needs as much files per device as possible, can set the number
of additional words to 1 or even to 0 at his needs.

BTW: I once found a device driver for RK05-drives which partioned the cartridge
into 4 or 8 partions, to circumvent the restriction, that the directory is
filled up with 240 small files, leaving 2000 blocks unusable on the disk.


Klemens

[Rich Alderson]

cjl <clasy...@gmail.com> writes:

> I maintain my files in Windows using the full-length names that the P?S/8
> SHELL will support. In terms of notation, P?S/8 TFS files are 6.0, OS/8 is
> 6.2, RT-11 is 6.3 [and TOPS-10] and MS-DOS is 8.3. P?S/8 SHELL is 12.4 with
> case retention same as OS/2.

Hi, Charles,

Tops-10 (and TOPS-20 prior to v3? certainly before v4) is 6.3, not 8.3. Takes
2 words, SIXBIT filename in the first, SIXBIT extension in the left half of the
second, and the right halfword contains different information depending on
whether the file is on disk or on DECtape. (On disk, it's a pointer to the
location; on DECtape, it's 6 bits of zeros and the low order 12 bits of the
file creation date.)

Tops-10 had a DATE75 crisis: Dates were calculated as

((year - 1964) * 12 + (month - 1)) * 31 + (day - 1)

which gave a date range of a little over 11 years; this was solved by using
3 unused bits elsewhere in the file descriptor to extend the range by a factor
of 8. Old-style Tops-10 dates end on 1 February 2052, if I've done my math
correctly. (Later, Tops-10 adopted the same date basis as TOPS-20 and VMS--
Modified Julian Date 0 = midnight UT on 17 November 1858, which fits into a
single word--but this is not reflected in the file system internals.)

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[cjl]

On Tuesday, March 28, 2017 at 4:33:39 PM UTC-4, Rich Alderson wrote:
> cjl <clasy...@gmail.com> writes:
>
> > I maintain my files in Windows using the full-length names that the P?S/8
> > SHELL will support. In terms of notation, P?S/8 TFS files are 6.0, OS/8 is
> > 6.2, RT-11 is 6.3 [and TOPS-10] and MS-DOS is 8.3. P?S/8 SHELL is 12.4 with
> > case retention same as OS/2.
>
> Hi, Charles,
>
> Tops-10 (and TOPS-20 prior to v3? certainly before v4) is 6.3, not 8.3.

Yes, exactly what I wrote. MS-DOS is 8.3.

Takes
> 2 words, SIXBIT filename in the first, SIXBIT extension in the left half of the
> second, and the right halfword contains different information depending on
> whether the file is on disk or on DECtape. (On disk, it's a pointer to the
> location; on DECtape, it's 6 bits of zeros and the low order 12 bits of the
> file creation date.)

For those unfamiliar with PDP-10 and other machines' conventions, this is NOT what in all PDP-8 assemblers of some worth [P?S/8 PAL, OS/8 PAL8 and PAL10, which ironically RUNS on TOPS-10!]:

The TEXT directive stores two PDP-8 SIXBIT code characters per word. This is not the same!

Additionally, since PAL10 is somewhat out of date, only P?S/8 PAL and OS/8 PAL8 support the following needed features:

The DEVICE directive generates exactly two such 12-bit words. P?S/8 has some vague need for DEVICE, but it is present for compatibility.

The FILENA{me} directive generate the OS/8 6.2 file name in exactly four words of the same code, thus all three support the same six-bit format, but different from TOPS-10 devices.

[Note: I may have to have some way to change P?S/8 PAL so the FILEN[am] directive creates 8 words for P?S/8 compatibility [or just pick an alternate directive such as FLNAME with different rules, etc.]

Additionally, PAL10 lacks a feature that has been annoying programmers at least as early as Rick Merrill writing FOCAL, 1969. The TEXT directive always makes the string have an end pad of 00 in the last half-word. If the string is of even length, an extra word of 12-bit 0000 is autmoatically generated. Cute, but a disaster when you DO NOT WANT that!

Thus, both P?S/8 PAL and OS/8 PAL8 have command-line option switches to turn off the auto-gen of the fill word so you can do what you need without grief. Sophisticated use of the TEXT directive include creating upper/lower-case multiple line messages; you have to have it work less crudely. But they are option switches for retro compatibility.

Now to the code.

The code for TOPS-10 has the high-order bit inverted. This means slightly more work to read then store, but in exchange, just add (40) and you have ASCII code.

On the PDP-8, on input, just AND (77). Thus, the high-order bit is inverted and on output you have a little work to do, so each system is incompatible in terms of conventions and the way easily used assembler features are implemented.

P?S/8 PAL not only has the TEXT directive, it also has the SIXBIT directive, so you can do it either way, whichever floats your goat.


[Rich, are you aware of another 12-bit cross-assembler known as DIAL10 ?]

>
> Tops-10 had a DATE75 crisis: Dates were calculated as
>
> ((year - 1964) * 12 + (month - 1)) * 31 + (day - 1)
>
> which gave a date range of a little over 11 years; this was solved by using
> 3 unused bits elsewhere in the file descriptor to extend the range by a factor
> of 8. Old-style Tops-10 dates end on 1 February 2052, if I've done my math
> correctly. (Later, Tops-10 adopted the same date basis as TOPS-20 and VMS--
> Modified Julian Date 0 = midnight UT on 17 November 1858, which fits into a
> single word--but this is not reflected in the file system internals.)

Good to know; I am adding on in the next release of P?S/8 support from 01-Jan-1900 to 31-Dec-2411 in an 18-bit format.

cjl

[cjl]

On Monday, March 27, 2017 at 10:20:02 AM UTC-4, Klemens Krause wrote:
> Johnny Billquist wrote:
> ...
> > I always found that way to store a date extremely bad, even if it was
> > simple to use. OS/8 is just as bad, but in other ways, as have been
> > covered here now. :-)

Indeed, it is needlessly awful and then just got worse with the awful kludge that came later. And worse, when DATE75 was a big deal in TOPS10, there was an impetus to fix it, but they lazily waited to the VERY LAST MINUTE and did something quite unacceptable.

This is born out of a cross of sheer laziness and idiot managers just going along now having a clue, and the original problem of OS/8 being HATCHED and it was PLANNED TO BE SCRAPPED but earlier idiotic managers interfered and alienated some of us entirely, thus the demo and the poor design became stagnant and no one wanted to change ANYTHING. All of that was totally avoidable, but the idiots after all, where "in charge" etc.

I have the dubious distinction if being the fifth person to turn down a personal request fron Richard Lary, whose only fault was being too accommodating to idiots who were clueless. The other four just ignored the idiots; perhaps they should have forced their way into the situation to get the idiots to listen, but Richie never would. so eager to please.

Thus,instead I went back and spearheaded the movement to improve greatly his original masterpiece, the R-L Monitor System with Lennie Elekman, the first to turn Richie down. He actually quit DEC but came back later as a consultant to work on ONLY some bits of some of the various OS/8 BASIC "dialects" which while all similar, are not identical [Commercial BASIC, Industrial BASIC, etc.]

The other end of this massive labor-of-love work is P?S/8 still being developed.

But the point is, no one was inclined to change ANYTHING and at the end, hardly anything was, and it is still the same bad design as in the begiining. You only get support for 1970-1977 despite all the scuttle-butt, conventional wisdom and management/marketing lies.

> >
> > I wonder why DEC had such a broken approach to dates back then.

I don't wonder, I perfectly just know.

> >
>
> I think, this is caused by the expensive hardware (core-memory) and
> limited storage media (RK05, DECtape) at that time. More bits for the
> date need larger directory tables in memory and larger directory
> entries on DECtape and RK05 disks.

Actually, no, it's just the bad design meant to be thrown away.

As proof, I am making P?S/8 do FAR BETTER oin the same resources. Simply not true, but when you break up the best programmers for the PDP-8 from their camaraderie that made everything work, that's what you get. I;ve told them over the years all my ideas, admittedly better, but laziness and apathy so nothing ever changed. But the difference is I never worked for DEC and was a consultant to many in the New York area, often many all at the same time. As such, I was much more productive than say, later when they got moribund, than what all of them together were doing. Not that I was super-good, but the managers only had super-low expectations so they got much lower than I would have demanded from them, etc.

As we all know, DEC was killed by idiot managers and nothing else.

> A minimal directory entry under OS/8 uses 4 words for the file name
> and one word for the file length. (No date!).
> That means, in the given fixed length of 6 directory blocks on
> a DECtape or RK05 disk, a maximum number of 288 files can be assigned.
> If you spend one additional word for the date, the number of files a
> directory can hold, is reduced to 240.

Correct. And why, even if you wanted to allow TWO AIW words, look how many less files would be possible, thus they didn't even do that! That would have at least extended the date range to 32 years to 2001. Instead, just the awful lie of an ugly kludge which is arguably WORSE than had they done literally nothing.

One of the problems is that empty entries are a different length from file names. More need to squish more often and rile up a directory crisis desparately trying to get one more file name in and eventually crashing not due to storage space, but inadequate directly space for enough entires, which is rather pathetic.

> This is the standard in OS/8. In the 12 Bits of this additional date
> entry, you can either encode the date in the way OS/8 does, using
> 4 bits for the month, 5 bits for the day in month and leaving 3 bits
> for a period of 8 years.
> If one would encode the date in full binary form, 4095 days from a
> starting date, this would work for a little bit more than 11 years,
> not really solving the limited date problem.

Correct. And in P?S/8 we HAD a half-assed kludge that did partly solve the problem to this day.

P?S/8 has as its only serious weakness that the file system is far more efficient for small projects, especially with Richlard Lary's notion of direct-access editing. Conventional editing you must have essentially room for the entire existing file and another tentative file big enough for expected changes, say a good rule of thumb about another 1.5 times the existing file size to create a new file, process every character, then close it as the new file, and you can rename the old one as a backup, or discard it, whatever.

But with direct access editing, each portion of a text project has its own filename for a fixed-size chunk of the project. Since the files do not have extensions, the date issue is moot, however the system date is needed elsewhere, such as in the nice title pages of assembly listings, etc. Thus, we at least did that far better.

You do need to get familiar with which filename covers the area of editing you are working on, but that is trivial as you 'know" the characteristics of your own work. The WORST CASE is eventually a tie coupled with a lot of commands. The EXPECTED case can be over an order of magnitude better, and thus typically it works well even on DECtape.

Because the file structure is that primitive, the entire directory is in memory, or as they would say today 100% cached. Programs are not in the directory, they have their own. This is just for the user's files.

Occasionally, there is a need for a fixup, and it is a small PITA admittedly, but surprisingly infrequently.

In essence, you cannot put what you want into the file. OK, stop trying, save it back. Then bring it back into the edit buffer and erase about "half" of it; the commands lend themselves to that easily. Then save the half in the edit buffer into another file. Then load the original file, delete what wound up in the new file and save it back. then continue where you were stopped by the need to fixup. Note: Since the directory is 100% cached you can anticipate the need for some more files, pre-create/reserve them beforehand.

P?S/8 even added a command for that, just type EN{er} filename:unit

Unlike R-L, tje system device handler supports eight logical units, which for the TC01/08 DECtape is all eight DECtape drives, thus no need for a handler to be loaded, etc. Thus, all relevant commands take that optional :u [nit 0 through 7 appendage.]


Eventually, I dannled in the notion of a more "OS/8-like" directory with theoretically variable length files, but most of that was abandoned, except the essence of it.

Thus, P?S/8 suports the notion of a SINGLE extended-length file per logical unit. In the next release, all traces of the artifacts of a directory will be removed entirely and the blocks will be repurposed for a much needed feature [because you have to manage thngs OS/8 conceptually lacks such as the Logical Console Overlay and the SHELL extension being worked on currently]. Instead, *THE( extended-length file will be a small entry in unused space within the system programs directory. this actually runs FASTER because that directory has to be read in anyway, so that's when if the command parse needs to process an extended file, it already has it in memory, etc.

The extended file's name will be changed by some new SET commands added to make it cosmetically preferenced for the user. But since it "owns" the entire extended space past the Tiny File System of fixed-length files [TFS] the configuration should represent an appropriate balance so as to not waste resources overall.

Thus, if desired, an entire text file can be created elsewhere [such as in OS/8] and then brought back as an extended file on any logical device unit. this is already done using P?S/8 OS8CON which has extended-length file options, etc.

In fact, OS8CON has another usage: You can convert into OS/8 format a bunch of TFS files, and then immediately perform the inverse. this will standardize each of them to nearly full with an adequate amount of spare space for potential further editing. And it all may fit into perhaps less files [but of course never more! The utility states how many of the ones passed to OS8CON were actually needed.]

The original P?S/8 DATE format was something akin to what you suggested.

Assume each month has 31 days, so there are 11 full years of each year could be 372 days. Divide accordingly to get the relative day of year, relative year, etc. That does get you to just over 11 years. But it does something else important:

Assume for the moment a slight fiction: An imaginary word somewhere else has six bits worth of staring groups of 8 years. If you bump the number, you are into the next 8 years supported, etc.

Thus, the stated today's date can be an anomaly, and if you bump the group value by one, you can change the dates of ones past the first 8 years to now become part of the first 8 years, etc.

The reality is of course we didn't have such a word then!

So, we did the following:

A list was documented of where in all RELEVANT programs there was some internal location where this was stored, all were differently implementing the same exact thing, just "privately" etc.

You had to perform this as part of routine system maintenance, but you had a "grace period" of over three years to get it done.

if these values are set to 0 then the base year is 1960, if 1, then 1968, etc. Currently I have it at 2008 which means the date expires in two years, but since I will be releasing Version 8Z after all [as part of the extended for Windows SIMH package I wrote] I will change that to 2016 so it will be good until 2027 without changing anything.

Also, due to a bug, it will break down in 2099. [Leap century problems, not worth fixing.]

The next release, 9A will start all over again, I did find those six bits in the system kermel!

Thus, I will go with something more akin to OS/8 in the low-order 12-bits that is relatively only 8 years, but with the full 6-bit extension actually available, I have redefined the starting date to 01-Jan-1900, and that works until 31-Dec-2411.

When the SHELL file structure is implemented, there will ALWAYS be full date support per file.

Also, the structure supports a notion of "limited squishing" which is a variant on what the DS/8 people tried to do years back [also rejected by DEC!].

Each directory segment contains EXTRA empty entries of 0 length. Thus, if a file fragments the space, there is already another empty to be appropriated as an entry of the proper length past the just created file [which was in turn likely created when previous file was deleted, so this is a better way to recycle empty space in the directory yet there is no FILE squish operations needed [yet].

Of course if you don't maintain it, you wind up with the OS/8 norm, but as occasionally as you forget to do the reasonable low-overhead maintenance:

The limited squish restandardizes each directory segment to have the original recommended number of spare entries [likely something like 4-8 by default]. You read in the directory from the front, count how many extras are needed to restandardize, and them move down the entries in the last segment to some even higher directory block that had been nothing but the standardized entries. Then you work backwards until all entries are taking usually additional directory segments, but all are standardized back to the beginning.

Notice that no actual file squish needs to be done, and that can be the even more infrequently done OS/8-like squish, which will go a lot faster if you first perform the limited squish. That way, it is impossible to get into trouble.

Empties of zero length can have a creation date as a minor frill, etc.

The original problem of one size NEVER FITS ANYTHING will be elimiated. No space will be wasted with links to implied adjacent segments. Just data spans to the next, etc. The device will have appropriate sized directories and files starting wherever needed. Never any excuse for running out of directory before underlying storage, etc. Fixing up for poor planning will be possible, but will take a lot of time, and likely want auxiliary scratch space on another device to speed things up. No reason not to support literally thousands of files on a very large device.

Since this is a more powerful structure, each RK05 unit has ONE directory for the entire device for example. I suspect a directory segment ought to be about twice the size of the current single OS/8 record. But I can do it as small as 1/2 of an OS/8 record, because P?S/8 reckons 128 word logical blocks.

The smaller, the less the need for more spare empties, as it is not that bad to have to "borrow" from a neighbor, as long as you don't make a habit of it. [And proper maintenance restandardizes the directory which is low overhead and not really a squish.

One of the main obstacles in OS/8 is the slavish stupidity of saving memory ala the Disk Monitor System. The P?S/8 SHELL will be allowed to be all user space in 4K if need be [and even be swapable in future releases if it gets very complex]. Calls to the UFO [User FIle Operator sounds a lot better than USR] can be both page and field relocatable, and if need be could be nearly an entire memory field.

All of P?S/8 virtualized all of field 0 in all contexts. You don't need to stupidly routinely save memory every time, but I have allowed the notion of a program asking for it on a one-off basis. Exit is ALWAYS to 07600, and the kernel adapts to save if requested.

Program images can also be "rigged" for debugging as a related option. Something more than ODT and some DDT-like things, etc.

Note: Other than code fragments for the various forms of available execution, no actual CODE has been written! There's time for that as I put the finishing touches on the upgrade from 8Z to 9A which is required first.

But with a DESIGN instead of that which HATCHED, it will not be that much work, especially if no mistaken reworks are needed, etc.

One foolish NEEDLESS limitation of the OS/8 date is the bits are not in weighed order. This means you cannot easily write a directory or other option such as before or after a supplied date. First you have to do bit-twiddling to get the weighted order in memory every time, etc.

Of course also has to be a double-precision compare to 18-bits of precision [unsigned].

It's rather pathetic that a 4K system with a 128-word Kernel has more space for date bits than an 8K system with 256 words in 8K! Better design is why. And remember, I WOULD have been part of the input on how best to design a system had the stupid suits not interfered, and also those four guys far better than me at the time. [Over time, I have essentially caught up with them largely!]

cjl [I worked with the best of the best.]

[Rich Alderson]

cjl <clasy...@gmail.com> writes:

> On Tuesday, March 28, 2017 at 4:33:39 PM UTC-4, Rich Alderson wrote:

>> cjl <clasy...@gmail.com> writes:

>>> In terms of notation, P?S/8 TFS files are 6.0, OS/8 is
>>> 6.2, RT-11 is 6.3 [and TOPS-10] and MS-DOS is 8.3. P?S/8 SHELL is 12.4 with
>>> case retention same as OS/2.

>> Tops-10 (and TOPS-20 prior to v3? certainly before v4) is 6.3, not 8.3.

> Yes, exactly what I wrote. MS-DOS is 8.3.

Sorry, Charles! My eye skipped right over the brackets, and I read the claim
as "RT-11 is 6.3 and (Tops-10 and MS-DOS) is 8.3".

> [Rich, are you aware of another 12-bit cross-assembler known as DIAL10 ?]

No, I've never heard of it. From the name, I'd assume that it's LINC-related.

[cjl]

On Thursday, March 30, 2017 at 8:01:32 PM UTC-4, Rich Alderson wrote:
> cjl <clasy...@gmail.com> writes:
>
> > On Tuesday, March 28, 2017 at 4:33:39 PM UTC-4, Rich Alderson wrote:
>
> >> cjl <clasy...@gmail.com> writes:
>
> >>> In terms of notation, P?S/8 TFS files are 6.0, OS/8 is
> >>> 6.2, RT-11 is 6.3 [and TOPS-10] and MS-DOS is 8.3. P?S/8 SHELL is 12.4 with
> >>> case retention same as OS/2.
>
> >> Tops-10 (and TOPS-20 prior to v3? certainly before v4) is 6.3, not 8.3.
>
> > Yes, exactly what I wrote. MS-DOS is 8.3.
>
> Sorry, Charles! My eye skipped right over the brackets, and I read the claim
> as "RT-11 is 6.3 and (Tops-10 and MS-DOS) is 8.3".

All correct now :-).

>
> > [Rich, are you aware of another 12-bit cross-assembler known as DIAL10 ?]
>
> No, I've never heard of it. From the name, I'd assume that it's LINC-related.

Yes, it is a hacked-up PAL10 for DIAL-compatibility. I MIGHT have a copy of it [cross many fingers; thousands of tapes to look through.]

cjl