Intersil Intercept Models...

From: Charles H Dickman Sent: Wednesday, September 10, 2008 5:20 PM I forwarded these comments to Charles, who tells me he's been tied up with one thing and another for a long time now, and asked me to forward the following comments. If you don't have time to read all of it now, skip to the bottom for the _post scriptum_. Rich Alderson Server Engineer, PDPplanet Project Vulcan, Inc. 505 5th Avenue S, Suite 900 Seattle, WA 98104 mailto:RichA at vulcan.com (206) 342-2239 (206) 465-2916 cell ___________________________________________________________________ P?S/8 was created as an outgrowth of the original Richard Lary/Lennie Elekman system eventually sent to DECUS called the R-L monitor. Many people contributed to the original project beyond the priniciple two people; all of the work was done physically within Brooklyn Poly by people who met each other there in various academic phases, etc. I would estimate the R-L work to have been the work of a whole lot of individuals contributing their single-digit % to the project after they got it working after literally toggling in the original code. I mean it literally; merely hand assembling wasn't enough; this was hand entered on the straight PDP-8 console. Years later, the machine broke and went into disuse; fortunately at the time, we had a PDP-12 on loan from DEC courtesy of Jack Burness, then currently working on LAP6-DIAL and later the beginnings of PS/8 were starting to appear from Richard Lary, as well as Lennie Elekman working on what became FOCAL-12 for DIAL, etc. During this era, I was not only one of the people working on the -12, which was literally used 24/7 [we had a bed there!], but I was also repairing various aspects of the PDP-8 which eventually the EE department thanked me for repairing, etc. Leaving out all of the relevant details except one: I literally replaced every slide switch on the front panel of that machine as they had worn it out! Anyway, by the time it was submitted to DECUS, I personally had worked on the first fully-binary-compatible patch to FOCAL, 1969 to add access to the R-L system to FOCAL with literally only an overlay binary I wrote. The theory was to retain maximum binary compatibility to be as compatible to all the works of others as could ever be hoped for, working in little 'holes" of code that could be dispensed with. For example, by the judicious use of super-squeezed code and co-routines, I was able to place the file unpacking interface to the R-L system over FOCAL's high-speed reader interface [which we didn't have nor does it make sense to care about in an environment where FOCAL is running under an OS instead of the original design as truly stand-alone. Additionally, I took back any-model compatibility and reduced it to family-of-8 compatibility. Thus, key locations could be bummed back by removing PDP-5 and PDP-8/S compatibility. [Note that PS/8/OS/8 and R-L and P?S/8 all only run on family-of-8 or perhaps some subset of newer; only the Disk Monitor System attempts to use PDP-8/S and FOCAL could use -8/S and -5.] Still others contributed yet other stuff, but we had to start somewhere. Some months later, I and several other people started all over again to produce what started out as a functional superset of R-L which later became known as P?S/8. Please note that all of the people who had gone before me who went to work for DEC became an isolationist group with the unfortunate [to this day!] misunderstanding that P?S/8 is NOT the R-L monitor. Despite Richard Lary's tremendous start in R-L, we did not use one line of his code, and we were not slavish to his limitations that largely came about because ultimately the R-L system is quite expedient. We had the advantage of being able to actually develop our code on an OS [the running R-L monitor system], while they had to hand-assemble and toggle it in. Additionally, we had some intermittent contact with TECO and PAL10 at nearby Stevens Tech in Hoboken to occasionally get real lineprinter listings, as long as we stuck with PAL10, which eventually became a hindrance due to lack of total compatibility. Along the way, the sources were converted and developed on a mixture of PAL10 and later PAL8-on-OS/8 development, but only after I got Richard Lary to literally apologize to me for the sorry state of PAL8 as a language. [He had been pulled into many directions while working for DEC and was relying on others to work on stuff such as PAL8. To my knowledge, most of it was the product originally of Mark Bramhall modifying something dreadful such as the Disk Monitor PAL-D, but frankly, what was done was rather poor.] Richie spent several weeks working on getting PAL8 to nearly where it exists today, which is a major step forward, albeit still slightly limited in some galling [to me and some others] ways. If you look through my code for Kermit-12, there is a chart explaining the still lingering nagging differences between P?S/8 PAL, PAL10, and PAL8. At least we are at the stage where a single page describes the differences! But some of the differences are quite frustrating. Curiously, PAL10 has become worthless for meaning development and many P?S/8 and OS/8 source code cannot be assembled on PAL10 for the want of a few pathetic nails. It would be real nice if PAL10 could be modernized to fix these few relatively minor problems, but essentially they are fatal. [To be fair: Some of the features were the outgrowth of features I added to P?S/8 PAL and Stan Rabinowitz added to PAL8, he seeing the fundamental need for these features as much as I did; it really became indispensable for code that has to be developed on a system where stuff gets swapped in, etc. PAL10 predated any care for this; it does all anyone in a paper-tape environment would want, but that's not enough, etc. In any case, a PDP-10 guy armed with the spec for what is needed could fix this probably in a few hours, etc.] In any case, P?S/8 source code is limited to strictly whatever can pass through PAL8, while I have written applications that in turn can only be assembled by P?S/8 PAL taking advantages of the still-further incompatibility using features only P?S/8 PAL has. OS/8 can never get to this level without a total rewrite of PAL8, as it is conceptually flawed on many levels. The easiest way would be to modify P?S/8 PAL to support an OS/8 environment. In theory, that task could fall on me if I choose to do so, but for the most part, I did not want to divert myself from advancing P?S/8, which to this day is actually not complete, but is fairly viable. Actually, I recommend the use of P?S/8 on systems too small to support OS/8 in any meaningful way because it is impossible if not enough memory or just too tedious for everyday usage. On larger configurations, I use both interchangably to take advantage of the best of both worlds, etc. As the capabilities of P?S/8 have substantially grown, I find less and less dependency on the smaller subset of OS/8 I depend upon, but it is a finite number, thus I cannot completely "cut the chord" at this point. Getting together a large block of time may lead to a large dent in this remaining obstacle to total independence, etc. [To repeat, P?S/8 has had an amazing amount of effort already applied, and it is a far cry from the original R-L monitor; the reality of just how different it really is is inversely proportional to the fairy-tale conventional wisdom of what people who believe it must merely be the R-L monitor amounts to. The credibility gap is that vast! A personal frustration is that the isolationist group has gotten lazy over the years and are dead-set in their inadvertent prejudice. It is a fact that they are lazy, and I say that as their friend. However, I am not lazy! I resent being presumed to be as minimally productive as they are. Such is what happens when you work for DEC and related companies too long, etc. This is not to say they didn't accomplish something, far from that. It's just that the time they took to do it in doesn't justify the quantity produced that isn't mediocre. The environment they worked in allowed this to happen, etc.] Part of this disparity is because certain individuals only had contact with versions of P?S/8 that were as much as seven years of heavy development away from where I was at the time. Thus, their myopia is understandable; they needed to get back in contact with me to find out just how much they were missing. However, I have to tell you that I eventually gave up on trying to give it away to people who were essentially OS/8 bigots. That someone else could do something else that could possibly matter was outside their ability to understand. Thus, my "user group" consisted of not much more than a few close friends and some then-contemporanous employers I worked for on various basis, either as a consultant or actually as a full-time employee [and in one period of my life not only both, but multiple in both categories, all at the same time!]. Please note that there was never any actual monetary motivation here, just wanting to do a better job. From my vantage point, and I say this knowing that much of it was done by people I consider my personal friends, I have always found OS/8 to be quite mediocre once you get past the notion that the PDP-8 is an amazingly powerful little machine. While you could argue today this is orders of magnitude out of context, even back then there is always the notion of wasting resources. To be specific, considering that P?S/8 is designed to run just about anything it can do in 4K doesn't justify what they did requiring a minimum of 8K. Their designs are lacking in planning; a lot of it just hatched, and Richard Lary was not good at preventing others from causing design creep internally. OS/8 tends to have a whole lot of bases covered, just that many of them aren't covered as well as they should be. And along the way, it paints itself into a corner that no one wants to fix with the predictable results of a forced level of mediocrity. Please note that I say this without the benefit of hindsight. All hindsight has added is conformation of what I was saying all along; it was quite predictable, etc. Despite this, I have periodically called for an effort to get an "overhaul" of OS/8 so that it could again at least work as well on newer machines as the original version worked on older machines. [I am now speaking to the various problems of the micro-8 systems up to the DECmate III+ .] Along the way to where P?S/8 was later, there was an intermediate level that was contemporaneous with the development of the IM6100 by A. Thampy Thomas who went to work for Intersil to make his master's thesis into an actual product. DEC had no problem selling Intersil the PDP-8 paper-tape software copies, as long as they gave each and every original copy to their customers, not making Intersil copies of the tapes, etc. But it became clear that DEC was not going to be able to give them something to run on the micro that was more viable than paper-tape. At this point of the story, I have to introduce some hardware companies I was dealing with: while DEC was playing with various disk designs that were the outgrowth of the IBM System 3, most notably the Diablo model 40 series [various versions were found as prototypes on in-house PDP-11 systems within DEC], a company in Arizona emerged called Western Dynex which produced what was for then a rather remarkable product: A 5.0 MB fixed disk with a removable cartridge disk above it, also 5.0 MB. This is a disk based on alignable heads, much like an improved grade of RK05 disk, but is a top-loader for the top section. All DEC eventually sold at this point was the 2.5 MB RK05, which was merely better than the RK01 which was 1.25 MB and DEC only made the controller, not the disk drive or related electronics [anyone remember which company made the RK01 drive and electronics?] Not only much faster seeking, it was as good as 4 RK05s with sufficient flexibility to allow drive backup with some artful drive swaps. [I leave it to the reader to figure out how to copy the bottom and top disks onto a pair of backup empty disks, and then restore the disks to the state it was before the backup! The hint is that you have to destroy the original copy of the bottom disk along the way, etc.] At the same time, DEC had not gotten involved yet with micro-8 hardware, in part because of the obvious bad blood between DEC and Intersil over the IM6100. I had in front of me an internal DEC lawyer's position on the paper-tape software: The guy said that it was OK for Intersil to buy and then resell paper-tape copies of the software to its customers because they, not DEC, made the claim that the software was compatible, and as such, it was not a committment by DEC, etc. So much for the convoluted logic of lawyers, etc. However, eventually DEC did deal with Intersil's second-source company, Harris, who made the identical chip called the HM6100. However, when DEC attempted to make this into what eventually became the VT-78, a lot of performance loss occured. The VT-78 was a needlessly mediocre product; Intersil without DEC's heavy-handedness could do better. Intersil started a project later known as the Intercept. This was a totally-compatible system based on the IM6100 running at the standard speed [not the crippled 65% speed of the VT-78] and this was quite significent as it turned out. The IM6100 is quite slow compared to a PDP-8/e, that it is quite closely compatible with. [The differences are a small handful of added instructions that do not exist on prior models, and also the lack of an obscurity that only exists on the PDP-8/e CPU itself, which, while similar to, is not quite the same as the same instruction on the PDP-8/a CPU. See the source code of Kermit-12 for a complete explanation of all model-dependent differences, etc. All of the superset instructions of all processors are not generally used in any practical OS code, but technically, one of the ways you can tell it's an IM6100 is that an obscure extension of the PDP-8/e and a similar yet different one of the PDP-8/a is NOT present, while a superset instruction only found in the 6100 and up is present. Later the 6120 would add an additional instruction beyond this, as well as more general speed improvement, etc.] At this point in time, it was clear that the peripheral of choice on all of these small systems was based on the RX01 or equivalent. Indeed, a pair is slapped onto the VT-78 to make it more useful than merely a VT52 emulator, etc. despite it being built into the case of one, etc. The problem with the RX01 is that the code space within OS/8 only allows for a rather meager handler for the device. The first attempt at a handler led to a rather unique event: I think this is the only DEC handler that was summarily dropped due to impossibility of usage. In short it literally didn't work! Here is the problem: Media such as the RX01 cannot be practical without the ability to retry. It's just gonna fail periodically, generally recovering if you do some error recovery and then internally retry the read, etc. [This is common practice on just about any disk-type device you can name.] This defective handler had a retry count of three, which is fine. However, if you ever retry at all, due to the way the code is written into a corner, it is not viable. The reason is that while this works for a read operation, the "figure-8 loop" code is also used for writing, a common trick for handler writers used on all sorts of PDP-8 devices that do not use DMA, etc. However, if you in fact get an error while writing, pray that it fails three times! Because should it get one or two errors, it will APPARENTLY succeed to have written what you asked it to. However, what you actually wind up with is the contents of track 1, sector 1 are written out to the desired sector instead of what you asked to have written there!!!!!!! Yes, it destroys your system at random depending on phases-of-the-moon error situations. There isn't even enough room in the handler to setup a more-than-one chance to read while a once-only chance to write, which would at least not lie to you about the handler call completing successfully, albeit more likely to fail than in theory a better handler could be depended on. Thus, the only choice was to set the retry count to one and suffer a lot of transient read errors to avoid the possibility of write lies destroying your media in "interesting" ways, etc. The handler was dropped; it literally could not be fixed. What was done instead was to require OS/8 to need 12K, in the way that was at that time known as the "TD8E problem" because it was the singular nuisance case of this problem of a system handler requiring [most of] 27600-27777 as well as the normal [most of] 07600-07777. Apparently the RX01 doubled the "problem" and eventually more cases appeared to more generalize the approach as additional too-feeble disk devices were hatched later. There are some lame conventions here: In essence, instead of making a new handler, they had to insert "fake-out" locations whether the code needed them or not, so that, totally irrelevantly, no one had to go back and tweak Basic or F4 to know what to do with the handler. These were kludged to discover explicit constants in key memory locations as a magic signature of the TD8E problem. As necessary, the code in [mostly] 27600-27777 could be moved out of the way to x7600-x7777 where x is 3-7 depending on what the highest actually available field of memory existed. Clearly, what was needed was some alternate means for any program to be able to discover the "problem" more generically, but it was never written, thus requiring no mods to either application-type system program. [This is really quite sloppy, isn't it!] In any case, the RX01 was then supported with extraneous constants matching their same location in the TD8E code. In some cases, this needlessly [albeit slightly] compromised the code, but they did achieve something that worked acceptably on a PDP-8 machine with 12K. At least this handler didn't lie!! However, there is a major design weakness: The basic sector mapping algorithm is based on division by simulation using repetitive subtraction. Each sector, in a call for several adjacently mapped sectors, has to be recalculated each and every time. Please note that OS/8 records are generally two PDP-8 pages long each. That means even a single-record call needs to have the sector calculated 4 times! Depending on the call, this could be anywhere from 2 through 64 times for the full range size of OS calls available. [The minimum read is one page; the maximum is 32 pages. Each page takes two sectors.] This just about makes it on an RX01 if executed on a PDP-8/e. On lesser processors, you quickly get into a throughput bottleneck: The method attempts to map the disk so that on each track you first access all of the odd sectors, 1, 3,5, etc. up to 25 followed by all of th even sectors 2,4,6, etc. up to 26. This is the best you can do and represents a two-way interleave, etc. [Please note that on PDP-11 systems, this is a subset of what is done; their formats often included a stagger factor, meaning that on each subsequent track you use a more advanced starting point, but you do traverse all of the sectors in the same relative way. But you only start at sector 1 on the first track. You could be starting at sector 5 on the next track, sector 9 on the one after that, etc. as you moved up say 4 sectors per track in the algorithm to take advantage of the ability to avoid rotational delay. When you seek to the next track, the motor has turned some number of degrees. To always start at sector one means a predictable additional rotational latency which can be avoided. PDP-8 handlers never addressed this, at least not OS/8 handlers, etc.] I never bothered to calculate it, but I suspect that on the upper tracks of an RX01, you might fall behind somewhat, but it comes at least close, meaning that for most of the disk, the two-way interleave doesn't add any undue latency issues, etc. But on a 4.0 MHz IM6100, this is entirely another story. For all but the first few sectors, you are constantly spending way too much time in the division routine and many sectors fly by. What should be done in two revolutions is now being done in 26 revolutions! [Note: It gets even worse on the still slower VT-78; the crawl is only partially the slow CPU speed; it is mostly that all that disk overhead we put up with on higher-performance disks is now painfully obvious where most of the access is running 13 times as slow as an RX01 usually goes, etc.] There is another hardware company that has to be mentioned here: Data Systems Design. Working with Western Dynex, that wonderful disk was mated to an elegant hardware solution of an interface to the Omnibus. The DSD-240 controller allowed for DMA transfers initiated by DMA of a command in memory to read or write [or format or diagnostically check, etc.]. Once initiated, the controller literally did everything, interrupting the PDP-8 when it was all done [or there was an error]. Writing the handlers for P?S/8 and OS/8 was a breeze with room to spare. Minimal systems could handle this device easier than DECtape [the original PDP-8 benchmark peripheral; if you cannot make it run on DECtape, it is worthless!] Intersil worked with two companies: DSD and a company called Pacific CyberMetrix or PCM. They produced essentially a kit form version of the Intercept called the PCM-12 [later PCM-12a] that was totally buss-compatible with the Intercept. Both machines supported plugging in 4K CMOS memory modules, some with localized battery-backup capability. Both [in different ways] used control panel memory to in fact implement a front panel, including a built-in RX-compatible boot switch. DSD produced the DSD-210, a compatible superset of the RX01 that could physically house up to three drives in a chassis, but the standard was two. Their buss could also support up to 4 drives. [Note: The way the later VT-78 supported 4 drives differs, but the basic support for two drives for the Omnibus, VT78 and DSD versions is compatible after a power-on reset.] Additionally, the DSD-210 can FORMAT RX01 media!! No longer need we toss magnetically-dinged RX media, etc. An interface to this device was developed for both the Omnibus and the Intercept/PCM-12 buss; I have all three items. While one could run in 12K OS/8 on those mediocre RX01 handlers, please note that the drop of support for the 8K handler led some Intercept purchasers to need that extra 4K unexpectedly. Regardless, the performance is still rather bad due to that division overhead, etc. The machine is just so much slower than an -8/e that it really drags in a frustrating way. [I know from personal experience!] At about this time, various people in DSD were asked by Thomas and the other Intersil people for the availability of an OS that DEC had no control over. Lennie Elekman knew the same DSD people I knew, and they put me in touch with Thomas himself. I explained that not one line of code of P?S/8 was in the control of DEC. However, in order to be viable, P?S/8 FOCAL required one to have a binary copy of FOCAL, 1969, as what is on the P?S/8 disk is a composite binary created by first loading into memory FOCAL, 1969, and then overlaying that with a rather large patch I personally created, and then saving all of that to specific blocks on the system disk. Next to this area are additional blocks containing more of my code that is conditionally swapped in later as well, but this is beyond the scope of the DEC licensing problem, etc. Thomas explained this was not a problem because he could also sell the paper-tape software to his customers, which included FOCAL, 1969. Thus, we could demonstrate that if you hooked up a paper-tape reader on a teletype [supported by Intercept] and used standard P?S/8 utilities to read in the binary paper tape, it produced P?S/8 binary files of FOCAL, 1969. And if you wanted to, you could load FOCAL, 1969 into memory from a standard P?S/8 command, gaining no access to any additional features, but it would work exactly as expected. And then if you loaded it into memory along with what I wrote, you could then start it at an alternate location that would write out the modified/patched version and overlays that amount to P?S/8 FOCAL literally. Thus, it could always be demonstrated that not one line of code was used illegally in any sense of the word, etc. as long as the user either opted out of FOCAL entirely or alternatively had also purchased a legal paper-tape copy of FOCAL, 1969, etc. Thus was forged a royalty agreement between me and Intersil. They had an unlimited license to a specific copy of P?S/8 as it existed then. It was not a buyout; I continued to own the product, and they were not automatically entitled to any additional updates, but we could negotiate beyond the fixed agreement for any work to follow [actually it never happened in fact]. Also, they wanted to not have it be known as P?S/8, so I documented every place they could patch the system so that each and every printout of P?S/8 could be replaced by the same-letter-count IFDOS [Intersil FLoppy Disk Operating System]. This is the software that they sold for the Intercept, and I was also free to make deals with PCM or DSD if they chose as well. P?S/8 performance on the Intercept is vastly better than OS/8 on the same hardware. [This is over and above any level-playing-field comparisons on more powerful machines such as "real" PDP-8s or even 6120s where the speed is that much higher, etc.] Here is the reason why: The OS/8 scheme for a handler is to attempt to squeeze the code to entirely fit into 07600-07777 with various locations reserved. This will allow the system to run on an 8K machine. In part, some people believe that the fact that there is also a boot record that is not the actual handler that takes control first is an advantage in terms of making this code smaller. I have proved this to actually not be the case; it just makes it easier to write the code due to the separation of the functions. P?S/8 does the same job to allow the system to boot up in 4K. However, there is no boot record; the image of the handler is also the bootup code. This leads to a lot of thinking in terms of code defined in as many as three loading origins: One where a bootup put it, another where that consequentially loads, and a third where it eventually has to occupy 07600 onward in the general case where all three addresses are pages different but perhaps not relatively different on the pages. [Note: Due to expedient design, the RX01 fails this latter part. However, since the RX01 has at least two pages of live code to run in for the OS/8 situation, plus that additonal boot record, they have no problem. P?S/8 has alternate ways of providing even more code space, so this is not actually a problem, just an alternate way to solve the overall problem. I must admit that if P?S/8 could have run in 4K, this might have been a problem, but....] Suffice to say, that it is historic fact that the lack of a separate boot record has never been a hindrance to an otherwise one-page handler. But other than in the RX01 case, has it ever been anything but an OS/8 "crutch" etc. [The simple reason is this: Internally, both systems use a scheme first invented by Richard Lary: When the handler is being used to process files passed to a system program, a list is created in memory locations starting past 07755. This is a hardware restriction of the PDP-8 because locations 07750-07755 are reserved for DF/RF, magtape, and TC01/08 DECtape operations of three-cycle data break. As such, you could never reliably use them. They can only be used as temporaries, etc. Thus, parameters to be passed to programs follow these locations when the handler is being called during a loaded system program, etc. The nature of these lists is system dependent. Current P?S/8 differs slightly from a future planned re-write, R-L handles them still differently, and OS/8 handles it still differently. But the overall concept is the same: the binary form of file info is passed in this area. As such, there can be no permanent code in these words from relative 0150 onward through 0177. Thus, in any handler image, once-only code can live there for bootup purposes. This has proven to be generically successful for all known hardware attached to a PDP-8 machine that "matters" that can otherwise get the rest of itself up in 4K.] Thus, RX01, just as eventually discovered in OS/8, cannot be realized in a one-page handler for P?S/8. However, P?S/8 rules are quite different in this regard: If a handler cannot fit into a single page, then a sophisticated memory management model applies: The challenge of writing a one-page handler in P?S/8 is slightly greater than all other things similar in OS/8 because there are slightly more reserved words in that all important 128 total. One of these is the Core Control Word. It includes support for concepts beyond that supported by OS/8, but I will merely point out what is relevant here. [Yes, 12 bits holds a lot of data!] 3 bits of the word contain the physical largest field of memory actually available on any basis as calculated when the system booted up. In systems where the handler is one page, this number is copied to another 3 bits which is the largest AVAILABLE field of memory the system will unconditionally release to any knowlegable program. However, if this is a larger system handler type system, this number is then at most one less field than the physical maximum. [There are also 3 bits that represent the current user setting from the CORE command with an arg; the CORE command without an arg displays all of this, doesn't set it. Clearly this value indicates field 0 and some user added optional memory up to that largest available as selected by the user; this works the same way as in OS/8 exceptt CORE 0 through CORE 7 is legal while in OS/8 you must give CORE 1 through CORE 7 only.] Thus, in an RX01-type system or similar, an entire field is off-limits [on a COMPLETE FIELD basis] to all programs to protect the handler. However, the actual handler space is x6000-x7777 in this situation. Locations x0000-x5777 MAY be available to a knowledgeable P?S/8-specific system program. All of the standard programs know this; most take advantage of that extra 3/4 of a field if available! [Note: Beyond the scope of this writing is the whole concept of the P?S/8 Logical Console Overlay, which occupies x0000-x5777 when enabled. Thus, this area may already be off-limits depending, etc. But it is an option on all hardware where 8K or more is available, and can be configured for an open-ended variety of alternate devices. Just a simple example: P?S/8 can be configured so that the console is not the standard 03/04 device as usual, but instead could use say an alternate serial interface to a different serial device, such as a PT08 on device 40/41 or whatever. This also includes alternate LPT support logically as well; configurations include the VT8E which isn't actually a terminal, but actually a DMA device housed in a VT05 chassis that is orders of magnitude faster than the "Real" VT05, etc.] Thus, the minimum practical P?S/8 configuration for the RX01 is where the handler has 07600-07777 and 16000-17777 to operate in on an 8K machine. For the level playing field that allows OS/8 to even work at all on an Intercept you need 12K, so the handler is in 07600-07777 and 26000-27777 for P?S/8 in 12K. Contrast that with OS/8 merely allowing a subset of 07600-07777 and 27600-27777. Additionally, that is the TOTAL of x6000-x7777; there are no reserved/kludged words there whatsoever. Beyond the 8 additional pages of code to write a far superior handler, there are also two pages reserved on the system device for boot-up considerations. This is where the code is that figures out exactly what is going on, including on-the-fly determining what the highest field available is, and perhaps complaining on the system teletype console that there isn't sufficient memory if you only have 4K, etc. Additionally, once this code is located where it finally lands, it is never again moved. Additionally, techniques are used to avoid having to reload it wherever possible. That is the province of these two "extra" pages to not ever compromise the 8 pages from having to be anything but handler code. Their only requirement is to be field-relocatable by the two pages of init code, not by themselves. Otherwise, they are loaded at fixed addresses, just like any other system handler in P?S/8 or OS/8 etc. In a handler now 9 times as large as a "regular" handler [instead of two times as big as in OS/8] you can really accomplish all sorts of things! I was able to solve all of the handler issues in about 4 total pages of code. The code in field 0 is merely an argument passer; most of the work is done in the 4 pages. [Note: P?S/8 also supports a hardware-specific optional binary loader. Some systems lack the hardware to support it, thus the switch to opt out of it is forced on in those cases. However, the RX01 is a device that DOES want to invoke a hardware-specific binary loader. As such, some of the space for the loader optimization code is also part of the 8 pages. However, all told, it all could easily fit in 4 pages if it had to. Please note that this is also the size it takes to implement the P?S/8 version of the RK05/RK8E handler, which writes to the nearest logical record that is one/half of the physical record of the RK05 sector. Among other things, there is a two-page buffer to accomplish this feat within this handler, and the rest is two more pages of code to make it all work. Thus, to date, no device challenge has ever needed more than half of this available space, etc. Perhaps I will drop the requirement of the two extra pages to relocate the code and count up the memory space, etc. But presently, it works as described here, etc.] [Note: The way the RK05 problem is handled predates solving the same problem in CPM/80 for very-large sector CP/M diskette device support; the logical CP/M record is as small as 1/8 of the physical record, etc.] [Note: This is how P?S/8 can handle RX50s in full 8-bit mode on a DECmate II/III/III+ once I get around to finishing that code; but the point is that the space is already carved out, etc.] The P?S/8 RX01 handler is magnificently more powerful than all other code I have ever seen on a PDP-8. [Note: For compatibility reasons, it does not use the stagger factor like the PDP-11; there is an ongoing need to imitate the layout used by OS/8. However, additional handlers can be written to handle more sophisticated device structure layout, etc. if desired.]. All of the folowing are automatically supported: 1) Real RX01 2) Real RX02 [Note: The media must be single-density; OS/8 has the same restriction.] 3) RX03 prototype never released to the public [DSD did the PDP-11 version however![ [Note: single density media; OS/8 has the same restriction. However, double-sided media is supported.] 4) DSD-210 with up to 4 units. 5) VT-78 with up to 4 units. 6) DECmate II with up to 4 units. [Note: Requires a special bootstrap program that is a superset of the RX01/RX02 boot that supports the RX78 board itself. This is because on the DECmate, the RX01/RX02 is not compatible because of the presence of the RX50. Thus, you have to have something aware of the alternate interface spec of the DECmate II with the option card. This handler does it if you run the boot code that enables it. The standard in-the-ROM bootup only supports booting to the first RX50 which resembles a strange geometry RX01/RX02. My more general bootstrap will support both RX50 pairs [in case you have a second one] and the RX78 board with either one or two pairs or RX01 or RX02, even a mixed set of pairs. Please note that it is likely that OS/8's standard handler could be modified to deal with this same problem which is minimal, but there are a lot of other problems associated with the fact that a DECmate is not quite a PDP-8, and OS/278 has mucked up too much that has to be undone first. P?S/8 totally supports the DECmate and all of its quirks in a generic manner; OS/8 needs a strong dose of the same medicine if it is ever to run again on DECmates properly; OS/278 kludges are quite horrible and a lot of OS/8 never made it to their cut, etc. It can be overcome, but it's a lot of work, especially if you are trying to get your own OS to work on this, and no one else seems to have stepped up who knows enough to write crafty PDP-8-type code as well as I do, etc.] 7) Can work in any system with either the PDP-8 convention or the demented and illogical OS/278 convention with regard to flag up or flag down status before handler entry. [Once OS/278 is obsoleted, this becomes unimportant; the OS/8 and original P?S/8 convention is the only way it makes sense; the OS/278 convention was invented by daft people who don't understand that, unlike WPS, OS/8 is inherently a no-interrupt system, etc. In the larger scheme, don't inflict irrelevant conventions on one system just because you need them on the other, etc. Thank You LaBonte and company!] 8) Has complete and elegant error-recovery that does not perform needless and time-consuming error recovery methods where irrelevant and worse. Consider this: If you get a read error that is due to CRC error, all you want to do is reissue a read command to try again. Due to lack of space to determine exactly what to do, all DEC code just does a total hardware reset, which includes a recalibrate to track 0 on drive 0 and 1, then seek on drive 0 to track 1, then read in track 1, sector 1 contents into the sector buffer, then possibly get an error for that read, and then, hopefully, actually try to reread the sector which also means you have to seek back to where you already were. On a marginal disk, merely re-reading could complete the task. But with all of the ridiculous overhead that literally takes many seconds to happen, all that overhead could cause a fatal case where the reread also repeats the error! Thus, not only is time wasted, reliability could also suffer, etc. 9) Correct handling of the vestigial bit of the RX03 found in all RX02. [Note: A revision of DEC's RX02 handler eventually fixed this, but some earlier code could be confused under some circumstances. I read what they did and imitated it; it made sense at the time. I admit that the RX03 issue was largely an in-house thing, etc.] 10) Correct handling of the RX02 present bit documentation and conventional wisdom bug. Due to bad documentation, a lot of otherwise OK PDP-8 code will not run on any form of write-protectable RX01 properly because of implementing a fairy-tale. This includes some user-modded RX01 and possibly 02 and definitely the DSD-210 that supports diskette level and drive level write protect as standard features. The short version is that a bit is documented as meaning "I am an RX02 in double-density mode" which is incorrect. It MIGHT mean "I am an RX02 in double-density IF I am an RX02 AND in fact the drive is ready AND in fact the media is double-density". Some sloppy mis-interpretation of this has occurred ruining the operation of some code written by trusting naive coders who believed the lie. The REAL definition is: "I am an RX02 in double-density mode IF I am an RX02 AND in fact the drive is ready AND in fact the media is double-density" OR "I am an RX01 and the drive is capable of being write protected AND the media is not present OR it it present and it is write protected by whatever method of write protection is actually supported on this DSD-210 or modified DEC RX01/02 drive". Additionally, please note that double-density media in any single-density drive is the same as drive not ready; there is no way to tell the difference. However, you can tell if the drive actually is an RX02/03 and not a single-density drive and not fall into the trap. [And once you know it's at least an RX02, you can deduce whether or not it is actually an RX03 and not get fooled by an actual RX02 hardware quirk which is not really that this is an RX03 at all.] The overall effect is to really know your hardware, and do the right thing by the circumstance presented for all cases. However, it takes almost a half-page of code to do all of these things over and above the lame "just recalibrate, wait and hope for the best" everybody else does [primarily due to lack of space]. I thank the authors of various RX diagnostics for some of the ideas used here, etc. And saving the best for last: 11) Performance-oriented handling of the hardware so it doesn't fall behind on slow CPU-based machines. This is a two-fold approach: To eliminate almost 90% of the problem, the infamous divide routine is accomplished by a shift/rotate algorithm reminiscent of the way EAE performs an actual divide. Look at the documentation of EAE simulators to get a notion of what is going on, etc. Part of it is an optimization for the specific algorithm for the specifics of this particular divide. Basically, you create the logical sector you want to access by mapping separate discussion, but you get to essentially the same place]. Divide that number, not by 26, but by 13. The remainder creates an even/odd bit that basically tells you if you are accessing the 1,3,5,7,9,11 etc. collections as opposed to the 2,4,6,8,10,12 etc. collection. [Note: On DECmates, this is the heart of how to do the RX50 as well, but the geometry is different, but the concept is identical.] The quotient/2 is the track. This creates the basic physical track and relative sector information you need to operate on, etc. The rest proceeds as would be in most OS/8 code. However, each operation is time-out checked, status-checked, and if an error, goes through the proper gauntlet of what to do to handle all error cases correctly and efficiently. Retries do the correct thing for all cases; never is excessive error recovery invoked, etc. If a drive is write-protected, the handler quickly returns the proper error, not three iterations of a total reset later, etc. Same for not ready situations, etc. The difference is quite dramatic for all practical cases. [The only reason to actual reset the drive is in that very rare occurrence of an actual cylinder seek error!] So far, this accomplishes most of what we want to do. But to otherwise imitate the OS/8 notion wouldn't work on the very slowest of CPUs where even the EAE-like code could be too slow to sustain a two-way interleave. Enter part two of the handler: Once the INITIAL caller sets that initial track and sector, the EAE algorithm is abandoned. In its place, a predictor/corrector algorithm is used instead. It turns out that it is a trivial [and few actual instructions!] non-iterative technique to calculate the next track and sector you need once you already know the previous one! Even a VT78 can do that! Thus, worst case, the first call perhaps overloads a very slow machine; It certainly has no effect on an Intercept or PCM-12/12a where the CPU is running at full rated speed. All subsequent sector calculations [remember for any particular system call, there could be as few as two calculations or as many as 64] are done by the fast method which takes about 8-10 inline instructions and no more. [You basically usually add 2, occasionally reset to sector 2, and occasionally bump the track number by using simple comparisons against "magic" constants; it's really rather trivial! But again, no space in any one else's handler for this additonal elegance, etc.] So even on a slow VT-78, the drive keeps up with the two-way interleave. Needless to say, using this specific P?S/8 handler on these slower machines is dramatically different, as the rotational latency drops back to the normal PDP-8-like behavior, instead of running 13 times as slow as normal!!! Thus, foolish users of Intercept who bought 12K and used OS/8 spent more money to wait around a real long and quite noticeable time for their choice. Users of IFDOS could get away with 8K and it ran rings around OS/8 with 12K. Of course, this also means that they couldn't assemble as large a program as in 12K, but for such a small machine, I doubt if this was a serious consideration. In OS/8, due to the ugly convention of essentially making off limits the last page of each and every field, PAL8 symbol table handling had to use [almost] whole fields for the symbol table. Note that due to the almost problem, this means that this requires 24K instead of 20K. [If you can use literally all of a field, then 4 fields gets you 4096 symbols, the maximum amount. But if you can only use most of a field, you wastefully need a partial fifth field.] Thus, in 12K you can get to nearly half of this in [most of] fields one and two while in 8K [but not on this machine!] you can only get to [nearly] a quarter of that. In P?S/8, if you have only 4K [not in this machine!], you get only a rather tiny symbol table. However, certain of the assembler's language features are modular and can be eliminated to make more space [meaningless if more memory is available]: 1) LINC mode dual assembly mode [Note: A user implementation of an almost acceptable subset of LINC mode handling was added unfortunately to an ancient copy of PAL8 before Richard Lary apologized and fixed it. Thus, as a PDP-8 assembler in general, it's a rather poor item. Too bad they didn't do it over on the much later version!] This is essentially a proper superset of PAL12 and the PDP-10 program known as DIAL10 [a hacked-up version of PAL10]. It handles all the standard anomalies, including user redefinition of standard symbols. Consider the following: In PDP-8 mode, the SKP instruction is always the same. However, in Linc mode, there are three different instructions depending on whether you are assembling for the classic LINC, the LINC-8, or the PDP-12. The default I used is for the PDP-12. If the user's source code redefines the SKP instruction while in LINC mode, when you switch back and forth, I allow the standard symbol to be overriden as required; yet the PDP-8 mode SKP is unaffected. Without this feature, you have to use ugly straight octal values or a local definition of SKP just before you use it; generally the convention is to put all definitions at the top of the source code, not in the middle; thus, my method preserves all normal intentions and conventions, etc. Unlike DIAL, this assembler supports [optionally] literals as is normally defined in PAL8 and PAL10. However, when in LINC mode, all arithmetic is done in one's complement mode, instead of the normal two's complement. Thus, you have to be careful when using literals called from both modes. Amazingly, it actually works! The reason is that the literal table is binary-driven, not source-code driven. If you happen to express the numbers differently in the different mode, but the resultant literal is the same binary value, the location is reused! A portion of the field 0 space is used to hold the swapped portions of the symbol tables, thus further still cramping a 4K assembly in terms of user symbol table size. But you get back all of the space if you drop the dual-mode assembly option, etc. 2) Literals and generated links are an option. Delete for more symbol table space. Due to their dubious worth, generated links have to also have an additional switch thrown. By default they are turned off even if literals are enabled. The reason for this is that links sometimes conceptually cannot work. Consider the following: FIELD 0 *200 CDF 10 TAD OFFPAGE *400 OFFPAGE,. The assembler is ignorant that you have changed the data field. The code WOULD work if the data field hadn't been changed. How do you expect the assembler to know if [either statically or dynamically] you changed the data field? Of course it can't know! Thus, generated links cannot work in all cases. [Admittedly all JMP and JMS situations might work, but only in simplistic cases, etc.] Thus, no one should be encouraged to use the sloppy link generation feature as probably they also don't have a firm grip on just exactly what a PDP-8 is and won't understand the rules about when links do and do not work, etc. Better to leave the "feature" off and learn to avoid using it. Thus, better coding technique will be learned to do it correctly only if it works, etc. If generated links are disabled, no space is saved, just that you get literals and errors on attempts to bypass proper addressibility in impossible situations. Links are always flagged and tallied in all cases; you are on your own as to whether or not they actually work. 3) Disabling the listing cosmetic improvement and cross-reference feature package gets you some more space if strictly in 4K. Enabling it gets you neater line-printer-orientation [titles, page numbers, etc.] and is a pre-requisite for the cross-reference option which takes even more space away in strictly 4K. If field 1 is available [in our Intercept model it always is]. Then you get 3/4 of a field for a symbol table. thus, OS/8 would get 992 symbols in 8K [but not on an Intercept!] while P?S/8 gets 768 symbols on a perfectly viable 8K configuration that OS/8 cannot even run in. If you get field 2 implemented, then OS/8 does get to almost 1984 symbol capability while P?S/8 gets to exactly 1792, only slightly less. This is the only level playing field unless you go for more optional memory. However, PAL8 may take as much as 20 times as long to assemble due to sloth in PAL8 in general and that 13 times latency working against you simultaneously. Note: There once was a "battle of the systems" of a sort within DEC between OS/8 and P?S/8: The hardware was a 32K PDP-8/e with TC08 DECtape and 8 drives and RK8E and 4 RK05. OS/8 was allowed to run on the RK05/RK8E. P?S/8 was allowed to run on the DECtapes. They chose a significently large OS/8 source program to assemble. It was placed onto an OS/8 DECtape and I converted the source code to P?S/8 file format using P?S/8 CONVRT [a bidirectional conversion program at the ASCII level between both systems, etc.]. Since I had 4 drives, I left mounted the OS/8 tape, converted the source files onto another tape, had a binary tape to write the binary out onto, and the system [and P?S PAL] were on the bootup DECtape. We agreed to make a fair test, so we assembled the same file on OS/8 on the first pair of RK8E/RK05s [they opted to ignore the second pair of drives]. One test was to time until both systems just started the line-printer on comparable output but did not cross-reference because PAL8 doesn't directly support cross-reference. Instead it makes a printable file that has to be post-processed by CREF and then OS/8 would lose by a major amount of embarassing time, perhaps an extra half hour. Thus, we limited the output to a non-cross-referenced test, and to be fair, the race ended when the line-printer STARTED to print, as long as in the end the result was essentially the same. I also pointed out that OS/8 would probably lose by about an additional 20% of the listing time if I enabled the P?S/8 console overlay with its lpt buffering, but left the overlay off and just stopped the clock when the listing started, etc. The results were that OS/8 beat P?S/8 by a factor of two! They were really scared because they knew just how much slower DECtape was than RK hardware! It should have been by a factor of at least 20! But it was not. [Note: When you tell your manager you need in-house hardware because otherwise it's REAL SLOW, having someone show that all that hardware was only twice as fast as far less hardware ruins your credibility. Doubling your productivity isn't worth an extra $25K in the '70's not to mention the in-house field service costs, etc.] The final blow was loading the program and exiting to the OS. In that test, P?S/8 on DECtape WAS FASTER IN EVERY CONCEIVABLE WAY than the RK05/RK8E OS/8 attempt. The larger the program, the worse OS/8 looked. OS/8 ABSLDR is a truly crappy program. It could be rewritten to be probably about 4 times as fast; it never was. As I said above, OS/8 was written to do "everything" but not to do any particular thing all that well. The Intercept was an interesting machine. Nothing about it was kludged and it went out of the way to be compatible, including total TTY compatibility, not just a simple interface. But ultimately, there is just so much you can do with an IM6100. But it didn't help that DEC's was far worse. cjl ps: Note that I included only the requisite amount of digressions as expected :-) . -- "In the future, OS/2 will be on everyone's desktop" Bill Gates, 1992