Subject: Re: DECmate: what is CLI????

From: lasner@.unc.edu (Charles Lasner)
Date: 20 Sep 1994 05:00:35 GMT

In article <[email-masked]>,
David Bell <[email-masked]> wrote:
>I recently got a decmate!
>however it's lacking a APU and XPU it's a DECmateIII

So, it doesn't have the optional APU!  There's more to the world than 
CP/M-80 and the ability to run DECspell and footnote formatter from WPS :-).

DECmate III doesn't ever have XPU, just a vicious rumor, never sold by DEC.

>
>I found the boot disks on sunsite but when I go to run the 
>games disks, I get CLI not loaded so I need to know how 
>to load the CLI (which I assume is the Command Line Interpreter)
>and then run the games disk. 

There are no "boot disks" for the DECmate III, which has no hard disk.  
Instead, each of several O/Ses runs from its own diskette.  In the case 
of OS/278, there are data-only diskettes (non-system), but the games disk 
is not meant to be used that way, i.e., it's an actual stand-alone 
bootable system unto itself, and must be used that way.

BTW, the message should be about CCL not loaded.  You're not too far off, 
but that's actually an option to the command interpreter.  OS/8 follows 
the original DEC-10 notion of the Concise Command Language on top of 
specific commands.  Thus, the following commands are identical in 
performance:

To run the PAL8 assembler to create the binary file BAR.BN from the PAL 
source file FOO.PA, you can type

.R PAL8
*BAR.BN<FOO.PA

Or you can use the CCL alternative (with more overhead)

.PAL BAR.BN<FOO.PA

In this case, the same net result is achieved, but at considerable 
overhead.  So much so, that on DECtape-based OS/8 systems, CCL was 
recommended to be disabled!  In any case, the first form is always 
supported while you need CCL enabled to perform the second form, etc.

>
>Thanks
>
>The DECmate faq doesn't seem to answer this question, 
>it there a users manual on the net?

Again, the problem is that this is a versatile machine that has lots of 
unrelated  operating systems for it.  The hard disk machines even have an 
"umbrella" system to coordinate which system is desired called Master 
Menu.  Some of these systems are independently documented, others not so 
much, etc.

>
>Thanks
>
>David
>
>
>--
>----------------------------------------------------------------------
>David Bell			|E-mail: [email-masked]
>School of Physics		|Phone : +61 3 344 5451
>The University of Melbourne	|Fax   : +61 3 344 4783
>Parkville, Victoria, AUST, 3052 |

cjl

---

From: [email-masked] (David Moisan)
Date: 22 Sep 1994 19:13:44 -0400

In article <[email-masked]>,

>supported while you need CCL enabled to perform the second form, etc.

Hmm.  I tried running PIP that way, like I used to do on the other
DEC systems I used, RT-11 and RSTS, but got this:
 
.R PIP
BAD IMAGE

There are several commands in the CLL that use PIP (as specified in the
helptext), and they worked fine.  I infer that PIP.SV wasn't meant to
run alone, but must be invoked by the CLL.  Too bad, really, I was very 
accustomed to the DEC way of doing things in the -11 series.  I really
should snarf the OS/278 source off of sunsite and look at it.

>>it there a users manual on the net?
If I didn't already have two FAQ's to write (the GE Superradio FAQ and the
RTTY/FAX FAQ), I'd take on this one.  As Charles says, there are several
operating systems available for the DECmates, but there is still room
for a basic FAQ with pointers to Charles' stuff, basic hints on OS/278
and CP/M (the most common OS's you will see, especially if you're a hacker :)
and basic care and feeding suggestions.

Dave
-- 
| David Moisan, N1KGH    /^\_/^\   [email-masked]      |
| 86 Essex St. Apt #204 ( o ^ o )  [email-masked]                |
| Salem. MA 01970-5225     | |     [email-masked]    |
|                                                                 |

---

From: [email-masked] (Charles Lasner)
Date: 30 Sep 1994 08:04:04 GMT

In article <[email-masked]>,
>>>it there a users manual on the net?

Indeed PIP is nothing special in theory; all OS/8 CUSPS are meant to be 
able to be run from the ".R xxxx" form of the program where xxxx.SV is 
the executable file name, etc.  CCL format was added as an aid to making 
things easier, not more difficult!

And there are always compelling reasons to *not* use CCL since it is 
neither efficient nor a panacea, etc.  Thus, the .R and .RUN DEV forms 
are always necessary, etc.

Or so we thought!

Someone at DEC years ago dreamed up an alternate notion we've heard 
elsewhere - less is more.  OS/78 V1 was created to fulfill a debatable 
need, namely a downsized system lacking features standard to OS/8, and 
also deleting the ability to support the standard syntax for no clear 
definable reason, other than modestly shortening the documentation in an 
otherwise redundant manual.  (The point is that if the manual is 100% 
redundant, you can't justify it on a cost-cutting basis.  Clearly *not* 
producing an OS/78 manual in addition to an OS/8 manual is cheaper!)

The actual implementation was that an unused JSW bit was defined as the 
"don't run this program" bit.  Thus, only CCL chaining to the program was 
allowed, i.e., starting it via a chain operation at one higher than the 
stated standard starting address, etc.  CCL chaining is of course normal, 
but the standard starting address becomes unreachable.

The overall mechanism is controlled by whether or not the system is 
considered to be in "OS/8 mode" or in "OS/78 mode" which is indicated in 
memory by the state of the extraneous bits that can be .OR.'ed into the 
contents of location 07604, which is normally 7402 or HLT.  There is 
actually room for two such bits, since the instruction can be expanded to 
OSR HLT, CLA HLT, or LAS HLT.  (This location is the error return for the 
attempt to save memory called at 07600.  This is one of those parts of 
OS/8 where the error return isn't handled well; there are a few such sore 
spots, etc.)

Thus, if any particular program is saved with the particular JSW bit set
*AND* location 07604 indicates other than "OS/8 mode" ("VT278 mode" and
"OS278 mode" have also been defined, although not quite clearly.) then the
program cannot be executed, sometimes with a bizarre error message such as
"bad image" etc. 

The bulk of OS/8 CUSP's were shipped with the JSW bit set.  In essence, 
OS/78 V1 is just a selected subset of OS/8 V3D with the mode set using 
the command "SET SYS OS78" to prevent the R and RUN commands, etc.  The 
restriction can easily be removed merely by using "SET SYS OS8" to return 
to the full system, etc.

But something happened as OS/8 "decayed" into OS/278 V2.  Somewhere along 
the way, the code got broken.  In OS/278, a lot of the particulars of 
what constitutes a core image are mishandled.  Some of this is documented 
in the Kermit-12 .BWR file.  In particular, the bit designated to be the 
"don't run" bit no longer functions as such!  Worse still, other 
important bits with specific meaning are being misinterpreted as the 
"don't run" bit!

For example, a program may indicate that it neither loads nor runs in 
field 0 or field 1 0000-1777.  This allows various optimizations if 
feasible, etc.  Thus, a program such as ABSLDR may have bits 0,1,10,11 
set (JSW is 6003).  According to OS/8 V3D (OS/78 V1) this would be varied 
to 6103 to make it abide by the OS/78 restriction, etc.

Yet, in OS/278 V2, clearing bit[5] in the JSW has no effect!  The mere
combination of those other innocent bits renders the program as
non-executable!  By removing the bits indicating the program doesn't
require swapping for field 0 and 1 0000-1777, use of ABLSDR becomes
possible with the R and RU commands, but all ABSLDR operations suffer
needless inefficiency in the process, etc. 

It appears that some code somewhere in the monitor is now badly flawed. 
Fixing it will restore the former system, and again allow PIP to be run as
intended, etc. 

Note further that the command "SET SYS OS8" is specifically forbidden in
OS/278 V2!!  The reason for this is rather complex and diabolical, but
repairable. 

The problem is that code has been added to prevent the change of system 
type!  Unfortunately, the delivered system is already set for "OS278 
mode" and thus the R and RU commands won't work on most image programs, 
etc.  Clearly, if the system were patched to the OS8 mode, we would be 
caring less about it, but the system cannot easily be patched as 
provided, etc.

The reason in turn for the prevention of the command being changed is 
because attempts to use the SET SYS commands are fatal to the system!  
Literally, any SET SYS command corrupts the system and makes it 
non-bootable next time!  If performed on the hard disk, the problem is 
permanently fatal as distributed; on diskettes, there are band-aid 
commands available to repair the effects of the "illegal" command!

The code is in (of all places we were discussing!) PIP itself.  Should a 
system head be rewritten by calling the handler, the head becomes 
non-bootable.  In the specific case of the RX50 diskette, there are 
non-device-independent (read kludge!) options to transfer the head of 
another system onto the broken system, thus restoring its boot 
capabilities, etc.  But hard disk volumes stay broken!

Thus, the attempt to change the SET SYS to any value is met with a 
warning message, essentially telling you that having succeeded in 
rewriting the header, you will be denied the benefit of the change, and 
additionally you are warned your system is either an about-to-die hard 
disk volume or a needs-to-be-repaired diskette system, but in either case 
is now non-viable!

Thus, savvy users avoid (and curse!) the mechanism, and just put up with 
the restriction.  (I use the inefficent ABLSDR so I can type R ABSLDR :-).)

The underlying explanation as to *why* the need to prevent the command, 
i.e., what destruction it causes is in turn solvable, or at the minimum 
is manageable.

The underlying problem is a "feature" of the DECmate II, III, III+ ROM's 
themselves.  DEC created a specification for how bootable volumes arrange 
certain header bytes for all of the machines with RX50 as well as some 
other devices, etc.  No particular care was taken to assign values to the 
DECmate-specific volumes as to whether the presence of the designated 
areas would cripple the boot process of the affected system!

As such, the OS/278 system faces a bizarre dilemma:  Values are required
in the header that must be written in 8-bit mode, i.e., the same values
*cannot* be maintained when writing in 12-bit mode, yet the DECmate
bootstrap convention is to *read* this same data in 12-bit mode! 
Additionally, OS/278 addresses all of its logical records in 12-bit mode,
thus attempts to write on logical record 0000 of the system will corrupt
the ability for this vital (in 8-bit mode!) data to be present.  (And of
course, the mechanics of the SET SYS command precisely affect writing out
of this area of the system.  Since the design philosophy of OS/8 is to be
device-independent, there is no rational way to prevent a program such as
the SET command from corrupting the system by realizing to perform a
device-dependent routine to write out the system header record when
updating a part of it, etc.  Note that the code in PIP is a
device-dependent kludge that bandaids the problem only for RX50; the hard
disk volumes' analogous problems aren't even addressed!  Proliferating 
all OS/8 programs with private device-dependent routines for all known 
problem devices isn't a solution!)

Actually, there is a solution to the problems!!!  By changing *ONE WORD* 
on the hard disk volume, it is possible to change the volume header so 
that it passes the ROM checks in the actual machines.  (Note: the DEC 
convention is then violated; it appears that the ROM only implements a 
cursory check of the DEC requirement!  Had the ROM writers been more 
diligent, this fix wouldn't be possible!)  There is a similar patch to 
perform the same fix on the RX50.  Should there be any software on any 
system tight-ass enough to check this ill-conceived convention, a 
specific program can be written to "export" the diskette by using the 
original, albeit flawed, header data, and to "import" the diskette by 
changing it to the value that passes through the ROM check, etc.  
(Clearly, there won't be any software on any machine policing whether 
hard disk volumes on a DECmate are obeying this artificial convention!)

In earlier posts I explained the underlying hardware reasons for all of 
this; interested readers are referred to the archived back pages of a.s.p 
for more details.

In any case, doing all of the above merely sets the stage for the 
actuation of the fix.  Once repaired, a SET SYS command *could* work 
harmlessly.  The kludge code added to PIP could be removed as it then 
becomes unnecessary, as well as ruining PIP (it makes PIP 
device-dependent and also requiring 12K).  It is still necessary to 
remove the warning code from the OS/278 monitor so that it functions as 
originally intended, i.e., to allow the user to set the option any way 
chosen, etc.

Additionally, the bugs associated with the save image header mishandling, 
especially the incorrect JSW bits accidently enabling the R, RU 
restriction, have to be corrected as well.

Once all of this is done, the problems of PIP, as you raised, will be 
eradicated.  (A lot of work undoing the cumulative damage, but it's a 
high priority issue!)

cjl