Subject: Re: Format of .SV files?

From: [email-masked] (Johnny Billquist)
Date: 3 Jan 1994 15:59:21 GMT

In <[email-masked]> [email-masked] (Megan) writes:

>I have been unable to find a description of the format of a .SV
>file.  Can someone possibly post it?

>					Megan Gentry

>From the OS/8 Software Support Manual (typed in without permission):

Appendix A.

A.2.2  Core Image (.SV Format) Files

A core image file consist of a header by the actual core image.  The
header block is called the Core Control Block.  The Core Control Block
consist of the first 128 words of the 256 word block reserved for
that purpose.  The second 128 words are unused.  The Core Control
Block is formatted as follows:

Location       Contents                         Notes

          CORE CONTROL BLOCK

         +-----------------------------------+
       0 ! Minus the number of core segments !
         +-----------------------------------+
       1 ! CDF CIF (starting field)          ! <- 62N3 where N is the
         +-----------------------------------+    starting field
       2 ! Starting address                  !
         +-----------------------------------+
       3 ! Job Status Word                   !
         +-----------------------------------+
       4 !                                   ! \  Core segment control
         +-----------------------------------+ |  double words
         /                                   /  >
         +-----------------------------------+ |  (K is the number of
    2K+3 !                                   ! /   core segments)
         +-----------------------------------+
         /                                   / Remainder of block is
     377 !                                   ! unused
         +-----------------------------------+

The format of the Job Status Word is as follows:

Bit Condition           Meaning

Bit 0 = 1	File does not load into locations 0 to 1777 in field 0.
Bit 1 = 1	File does not load into locations 0 to 1777 in field 1.
Bit 2 = 1	Program must be reloaded before it can be restarted.
Bit 3 = 1	Program never uses above 8K. This is used when Batch
		processing is active.
Bit 10 = 1	Locations 0 to 1777 in field 0 need not be preserved when
		the Command Decoder is called.
Bit 11 = 1	Locations 0 to 1777 in field 1 need not be preserved when
		the USR is called.

The Core Segment Doublewords control the reading and writing of the
associated areas of core.  The format of each entry is as follows:

Location         Contents                       Notes

        +------------------------------------+
      1 !           Core origin              ! Multiple of 400(8)
        +------------------------------------+
      2 ! ! Number of pages ! Field   !      ! Bits 0 and 9-11
        ! !     to load     ! to load !      ! are zero.
        +-+-----------------+---------+------+
         0 1               5 6       8 9   11

The core origin must be a multiple of 400 (octal).  The Core Segment
Control Doublewords are sorted within the header block in order of
decreasing field and increasing oridin within the same field.  There
can be no more than 32 (decimal) Core Segment Control Doublewords in
any Core Control Block.

The Core Control Block for the program at the time it is loaded into
the core is always saved in words 200 (octal) through 377 (octal) of block
37 (octal) (one of the system scratch blocks) on the system device.
It is placed there by the GET and RUN operations, or by the ABSLDR or
LOADER programs.  This Core Control Block is used when performing a
SAVE without arguments.

		NOTE

	The R command differs from the RUN
	command in that the program's Core
	Control Block is not written onto the
	scratch area when using the R command.
	In order to SAVE a program that has been
	loaded by the R command all of the
	arguments of the SAVE command must be
	explicitly stated.

Hope this is enough, otherwise I'll have to dig out my
FUTIL manual, and start experimenting... ;-)

	Johnny

Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: [email-masked]       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

---

From: [email-masked] (Charles Lasner)
Date: 4 Jan 1994 12:53:30 GMT

In article <[email-masked]>,

>Bit 11 = 1	Locations 0 to 1777 in field 1 need not be preserved when

As I previously posted, some other bits have been defined.  I believe
bit[5] is the "no-R"  OS/78 bit, but it's become muddled in newer OS
versions, etc.

>      1 !           Core origin              ! Multiple of 400(8)

Don't expect much validity checking of this restriction!

>        ! !     to load     ! to load !      ! are zero.

Bits[0] and [9-11] *better* be zero!  They aren't checked!  Attempting to
use bit[0] set means that it writes on the file instead of loading it!

>can be no more than 32 (decimal) Core Segment Control Doublewords in

I think you'll find that many OS/8 versions are restricted to nine maximum!

>LOADER programs.  This Core Control Block is used when performing a

OS/278 is riddled with bugs in this area!

cjl

---

From: [email-masked] (Johnny Billquist)
Date: 5 Jan 1994 16:57:57 GMT

>bit[5] is the "no-R"  OS/78 bit, but it's become muddled in newer OS

Yes, I know. I was just quoting the manual. :-)
This is what the OS/8 Handbook Update says:

Bit 4 = 1	A core image file that was generated by LINK containing
		overlays
Bit 5 = 1	This program cannot be run by the R, RUn, or GET commands
		under OS/78
Bit 6-9		Unused and reserved for future expansion

>Don't expect much validity checking of this restriction!

:-)

>use bit[0] set means that it writes on the file instead of loading it!

Yep. This field is formatted exactly as the device driver wants it, and
those other bits also have meanings.
(If you set bit 11, and the device is a DECtape, it will run in
reverse... :-)

>I think you'll find that many OS/8 versions are restricted to nine maximum!

Haven't checked that. Anyway, I was only quoting the manual.
Strange that they should restrict this later.
I assume you mean bastardized OS/8's, such as OS/78 and OS/278
by the way.

>OS/278 is riddled with bugs in this area!

(. Software always have a way to improve itself... .)

---

From: [email-masked] (Charles Lasner)
Date: 5 Jan 1994 20:19:42 GMT

In article <[email-masked]>,
>Bit 4 = 1	A core image file that was generated by LINK containing

Which linker?  Macrel, F4, FORT?

>Bit 5 = 1	This program cannot be run by the R, RUn, or GET commands

In OS/278, there is confusion here, since the functionality of bit[5] is
still present, but occurs if some combination of bits[0,1,10,11] are set,
besides their normal function as stated.  For example, ABSLDR is subject
to the restriction unless you make it run more inefficiently by removing
at least one of the stated bits.  Thus, if bit[11] is cleared, "R ABSLDR"
is allowed!  Bit[5] has no effect either way.

>Bit 6-9		Unused and reserved for future expansion

Isn't one of the other bits reserved for batch purposes?
>(If you set bit 11, and the device is a DECtape, it will run in

Partially.  What you refer to is the "search forward first" bit for
DECtape and LINCtape.  This is one of the "features" I am attempting to
eliminate (because it's a conceptual waste) in OS/8 version 5.  All of the
affected devices can have "smarter" handlers written that don't require
the stupid bit; they can do the job better themselves.  The bit in turn is
more useful to be defined as the "^C abort" bit in 07601, although the
worst action taken would be to forward search first as a program exited, etc.
>(. Software always have a way to improve itself... .)

Yes, it certainly can!

cjl

---

From: [email-masked] (Johnny Billquist)
Date: 6 Jan 1994 02:55:22 GMT

>Which linker?  Macrel, F4, FORT?

Um, neither of those is a linker, Charles.
LINK and LOAD (and maybe ABSLDR) is linkers.
Since the manual said LINK in capital letters, this is most probably
LINK. The only program that I know of, which generate object code
for LINK, is MACREL.

>is allowed!  Bit[5] has no effect either way.

Well, I won't ever touch OS/78 or later, from what I've heard.
As long as I stick with OS/8, things work fine and consistently.

>Isn't one of the other bits reserved for batch purposes?

Hmmm, not that I know of. There is one bit for batch. Bit 3.

>DECtape and LINCtape.

Ummm, maybe, and maybe not.
To quote the manual:
"Bits 9 to 11	Device dependent bits, can be left zero.
		Currently only bit 11 is used;  on DECtape
		bit 11 determines the direction in which the
		tape is started.  If bit 11 is 0, the tape
		starts in reverse.  If bit 11 is 1, the tape
		starts forward.  All other handlers ignore
		these bits at present (except TM8E and TA8E)."

I'm not sure how this works out in life, and since my system with the
TD8E is at my parents place, I can't test it either...
I'll assume this just tells in which direction it should start
serching then.

	Johnny

---

From: [email-masked] (Charles Lasner)
Date: 6 Jan 1994 11:39:23 GMT

In article <[email-masked]>,

>Um, neither of those is a linker, Charles.

Macrel has an associated linker, as does F4 and FORT.  Each linker handles
(potentially) relocatable binary for its "family"'s files.

>LINK and LOAD (and maybe ABSLDR) is linkers.

LINK is the MACREL family linker apparently.  I think LOAD is the FORT
family linker (aka linking loader), and LOADER is the one for F4.  (Those
last two backwards?  Also, doesn't one of them have a library maintainer
called LIBRA?  Perhaps there is also a parallel program called LIBR for
the FORT family?  What is the equivalent for the MACREL family?)

ABSLDR is not a linker; it merely loads absolute binary paper-tape files
and does nothing that a linker ever does.  No image is created; merely,
memory is loaded wherever OS/8 allows it.  The SAVE command is used to
create an image file and must be used before any other commands wipe out
the image, etc.  Linkers have to deal with relocatable binary; ABSLDR
never does.  Linkers ought to have the concept of a library; clearly,
ABSLDR does not, nor can it since there is no relocatability (nor should
there be for its purpose).  ABSLDR also doesn't have the concept of
symbols or references or resolving or even designation of the "hierarchy"
of modules or even designating a starting address other than as an option
switch to indicate load-and-go as opposed to load and return to O/S. 
Thus, the basic function of something to link is absent.  All files loaded
by a *non*-linking loader such as ABSLDR have to be self-contained in terms
of no external references possible (except definable absolute ones like
the convention of calling the system handler at 07607, etc.).  It's just
that PDP-8 code, since it's designed for a fixed environment of generally
32K or 8K or 4K doesn't need any of these "features" unless you are
writing mindlessly regarding the efficiency of tight coding, etc.  (You
have to admit that by using MACREL, you have sacrificed certain ways in
which your code could be space-optimized; since there's often not much
space available, this can become counter-productive!  From the point of
view of a tight coder attempting to make a program fit into 4K or at most
8K to make it possible to run on all standard configurations, MACREL and
relocatable code generation seems to offer mostly negativisms!)

>LINK. The only program that I know of, which generate object code

I can believe this.  When MACREL was released, it attracted a whole
generation of sloppy programmers.  One of the reasons was because it
promoted the use of a supplied mechanism for swapping in code.  Thus,
programs that never needed to be written with overlays if properly coded
were suddenly swapping, but only on the system device.  This mechanism was
inadvertantly and illadvisedly applied to several OS/8 system programs
until a manager realized the inherent conceptual bug in the process -
namely that it meant that the program violated OS/8 standards!  Attempts
to use the program via the "RUN" command corrupted the system!  As a
result, budgetary money was wasted "de-MACREL-izing" some programs, and
some were just summarily dropped, such as RESORC.SV, which is not
available for OS/278!  (The problem is that the swapping macro, as
provided, merely shows a mechanism for allowing the user to more easily
write overlay-oriented code from MACREL.  However, it has *never* been
necessary to require either the macro or the code within it to allow
overlay-oriented programming; it's admittedly easier to do it this way of
course.  Unfortunately, the provided macro is more limited than would-be
users suspected it - it requires that the affected program reside totally
on the SYS: device, and must be invoked with the "R" command.  Thus,
commands such as RUN DEV: RESORC.SV become dangerous to attempt as they
fail to execute the intended program.  OS/8 doesn't provide even a
mechanism to gracefully prevent this from being attempted; I suspect this
bit you mention is a "band-aid" on that problem.  In any case, the
incorrect usage of MACREL has clearly caused backwards steps in the
development of OS/8.  Even now, it becomes necessary to waste development
effort correcting mistakes of the past.  Some are attributable to hardware
incompatibility such as the DECmate-induced debacle, but the
MACREL-induced issues were/are totally avoidable.  As a specific aside,
it's my understanding that there was a small "wish list" associated with
RESORC, and to avoid having to optimize the code (which was never
particularly optimal, thus it had much potential to be hand-bummed down in
size!), a manager was talked into allowing it to be "translated" into
MACREL and take "advantage" of the available swapping capability to allow
it to still be usable in 8K, implement all of the wish-list features, and
still have plenty of development potential for the future, etc.  From the
manager's standpoint, this sounds (too) good (to be true), because it
means that he doesn't have to have one of the tight-coders maintain the
program anymore, and can instead depend on a lesser-qualified person (to
write tight -8 code!) to produce an acceptable (albeit slower due to
swapping) utility.  But since there are no system safeguards against using
the program as documented (such as RUN RXA0 RESORC) but in ways that fail,
there was some "spectacular" form of crash as someone used it that way,
etc.  As a result, RESORC was dropped entirely because no one good enough
to repair it was available.  For myself, I still wonder why they didn't
merely recycle the previous PAL8 version?)

Anyway, I'm not really here to start a "religious" war against MACREL,
just to point out that sometimes TAASTAAFL.  The translation to MACREL was
promoted on a false premise, namely that unrestricted swapping was
available to these CUSP's, and that *nothing* else would change.  Clearly,
once stripped of the false promise/premise, the conversion offers little
to support it; for the most part, MACREL was abandoned by those involved
in such projects.  (Note: others continued to use MACREL!  However, every
one of them is associated with a project, such as WPS, where traditional
PDP-8 code-squeezing is never performed.  WPS requires 32K; Master Menu
makes the user wait for 4 memory fields to be loaded each and every time
it comes up; it even counts down "4 3 2 1" as it is being loaded. 
Considering just how much (or little!) the user interface in MM is, 16K
seems to be an awful amount of code to accomplish that function, etc. 
Additionally, each menu option causes additional disk I/O, so this cannot
be attached to the notion of just attempting to load the "entire" program
in, as ill-advised as that would be.  It just appears that MM is overly
modularized and thus runs slower than necessary, etc.)

>As long as I stick with OS/8, things work fine and consistently.

That's simply not true!  OS/78 is a mode of OS/8 V3D (internal version 3Q)
and not a separate O/S.  Later versions merely dropped the "OS/8" name and
officially became known as OS/78.  Here's the relevant history:

PS/8 V1		The original 1970 system
PS/8 V2		An upgraded system in various stages through 1973
OS/8 various versions before V3D which weren't stable.  Eventually we
realize that versions of system release and internal release versions
don't match!  The one that tends to stabilize is called V3D and internally
V3Q.  Various marketing schemes are applied to products all claiming to be
V3D.  One is an upgrade kit supporting TECO, but also includes an
alternate O/S head that supports the KT8A from the ODT command, and
includes some kludged utility to allow tedious extended SAVE operations
for memory beyond 32K and some form of support for the extended images
thus created.  (I think one of the programs was called SAVCCB) Another is
an alledged "different" O/S called OS/78, complete with its own variant
manual.  This package includes mostly standard release versions of the
CUSP's, although some are patched up to the latest revision level; someone
even suggested purchasing it to ensure getting the latest revisions!  The
only actual utilities included anew are the "symbiont" print spooling
program and its support routines.  Other than that, it turns out that the
KL8E handler has been "raped" so that it now only assembles correctly for
systems with VT-52 consoles (making changes produce either assembly errors
or misfeatures, or incompatibility with the SET command for console
functions), and that all of the supplied CUSP's now include a reservation
of location 00000-00002 to include an interrupt handler presumed to exist
in field 3.  (Each program has a place to save the PC on 00000; CIF 30 in
00001; JMP 0000 in 00002.  This only works if the machine is exactly 16K
such as a VT-78 *and* if there are no DMA disk devices!  Of course, the
system device of the 16K VT-78 is an RX, thus no problem on that limited
configuration!)  And of course, that fore-mentioned restriction on the
ability to use R or RUN or GET on the CUSP's.

At about this point, with all of the allegedly "same" versions that are
actually markedly different, something had to break!  In this case, it was
the software distribution mailing list!  What actually happened was that
the software distribution people switched to a PDP-11!  As a result, the
list was "accidently" mostly lost!  Virtually everyone who was ever on the
mailing list was now no longer getting the monthly updates and patches to
OS/8, etc. that had been reliably available up until then.  This situation
lasted well over a year despite numerous protests from angry users!  As a
result of all of this negativism, the managers alienated the entire
customer base - they decided to charge for updates!  One thing was done
though: a special "update" edition was published for the entire period. 
It was even fairly typo free.  (Note: these updates were often unreliable
because instead of using actual console output of ODT sessions, they had
secretaries with limited technical expertise transcribing the console
output!  Eventually, someone suggested a paste-up using a DECwriter
console printout!)  Several people were able to patch up a better working
OS/8 V3D system as a result, etc.  However, as late as 1980, DEC was
attempting to sell an overpriced (100's of % inflated price over the
previous V3D release!) package of OS/8 V3D which merely was the old
original with the programs at proper patch revision!  From a user's
standpoint, this was unconscionable.  DEC's managers were gouging the
users because they were responsible for complaining about management's
mistakes!

Somewhere in the midst of this, there was a release called OS/78 V2.  It
consisted of a one-page release note and some paper-tapes to update BASIC
and provide RL handlers.  (Whether there ever was a packaged "complete"
release I really don't know, but the update was quite meager!)

Eventually OS/78 V3 was released.  By this point, managers didn't want
anything called "OS/8" because of their self-induced (as a group) debacle.
Further, it become quite obvious that this release was a tossup as to
whether it was a step forwards, or a step backwards!  The key "features"
of this system seem to be:

1)	Support of the RL02 (which can be applied to V3D).

2)	Dropping support of all of the handlers other than RX, RK, RL,
TD8E.  This was proven to be a managerial manipulation.  All of the
handlers were stable; there was no reason to excise them!  However, there
were no machines available anymore to run them on just in case there was a
problem, etc.

3)	Dropping support for "pre-Omnibus" machines.  Since it is possible
to attach an RX to any -8, and specifically, many people had just recently
purchased DW8E's to attach the RK05 (w/RK8F, *not* RK8E!) to their -8/i,l,
-12's, etc., this was particularly offensive!

4)	Removing the ";" command support.  (Note: a feature of OS/8 V3D is
that if a command line ends with a ";", the command is not processed! 
Instead, it becomes input to an on-line editor.  The input terminates when
a line is typed that ends *without* a ";".  Then the entire file is passed
to BATCH, which in turn requires 12K to run.  If only 8K is available, the
process fails gracefully with a BATCH message to the effect of only 8K
available, thus wasting all of the user's typing.)

This system can have the OS/78 mode enabled or not, just like V3D (and
OS/78 V2, considering how little that contributes!), but cannot run
completely on -8, LINC-8, -8/i, -8/l, -12 because it is riddled with
defective constructs such as dependancy on OPR micro-coding where IAC and
rotates work as -8 and LINC-8 do not.  In fact, some ill-advised programs
were distributed with V3D such as the TC01/08 DECtape formatter modified
incorrectly to include CAF instructions which crashes certain models. 
(The instructions 600x behave differently on different models.  CAF is
6007 which pulses on all three IOP lines on an older machine.  On some
models, it enabled interrupts, on KF-12B-capable PDP-12 it enables API; on
the LINC-8 and PDP-8 it hangs!)  But in V3T (the internal version of OS/78
V3), the use of instructions that cannot run on older models became much
worse.

This wasn't merely an attempt to use BSW to create forced obsolescence;
there no longer were many people skilled in the art of not using extension
instructions!  As an example, there was a dialogue with one of the new
"developers" who assured us that he "knew what he was doing" and wouldn't
use anything that would be incompatible.  As an example, he showed us that
he knew how to code NL0002.  Unfortunately, he used:

CLA CLL IAC RAL

instead of

CLA CLL CML RTL

>From this point we realized that there was no hope!

Then they addressed the DECmate problem, and created the largely defective
OS/78 V4.  This release suffered from a lot of "surgery" and had out and
out problems not traceable to the incompatible DECmate hardware.  It also
had a large price tag, and was unpopular.

>From a long-term perspective, it was becoming obvious that DEC was
charging more and more for less and less, albeit likely because they were
involving more and more (but less and less skilled!) people in the
project, and pricing was based on costs, not quality of product.

OS/278 V1 was never released.  Many of us have self-start versions of it
which are the various forms of "install" RX50 disks for the DECmate II.  I
have an "enhanced" version of the System Test Diskette Version 2.4 which
restores the directory entries for deleted (but still present!) programs
including a lot of familiar CUSP's.  By renaming the startup program (from
OS/278 V2), you can gain control of the OS/278 V1 keyboard monitor. 
(Note: several versions of OS/8 support the feature of SET SYS INIT R
PROG.SV where PROG.SV is any system program.  On this particular disk, the
feature was enabled and all of the code is ignoring ^C abort attempts,
thus the disk can only be used for the intended purpose of a diagnostic
menuing system.  But by making the designated program unavailable, the
keyboard monitor complains that the file is not found, and provides the
normal prompt!)  Many of the CUSP's are just OS/78 V4 programs with no
changes, etc.

OS/278 V2 was released to DECUS, and is available on sunsite.unc.edu.  The
files were released as DM-101, and alleged "sources" as DM-111.  However,
the sources are not quite compatible with the binaries, and seem to be
about a half-generation behind the running binary.  Additionally, they are
incomplete!  Moreover, there are no sources to the part of the overall
environment that OS/278 V2 has to interact with, namely Master Menu, the
hard disk partition area, the ROM's, and the "slushware" (latest known
version = 422 aka "R").

Many aspects of OS/278 arbitrarily change some of OS/8 apparently to the
personal preference of some of the newest "developers".  Some bugs of
OS/78 were fixed; some were not.  Some were introduced!  A few are the
consequences of either dealing with the hardware differences in an
expedient manner, or not researching ways around apparent problems that
actually can be overcome with some effort.  (Note: I am making a
distinction here between OS/8 changes done to accomodate the hardware that
lead to different operation and OS/8 changes made because of misperceived
problems.  The former requires changes to the OS/8 structure; the latter
requires elimination of code added unnecessarily to band-aid problems that
can be better dealt with.  For example, the DECmate console hardware is
forever incompatible with the -8.  Only a new approach amenable to all
hardware will run on all machines; neither the traditional approach of
OS/8 nor the lame approach of OS/278 is acceptable.  However, OS/278 is
"broken" in aspects of the SET SYS command because of misperceived
limitations of the hardware, which can actually be worked around.  Thus,
the command's functionality can be restored to that of OS/8 without
dependancy on resolving the other hardware-specific problems.  The
developers of OS/278 applied their changes expediently because they knew
no way to resolve the hardware problem.  I have cleverly solved the
problem, thus making the changes unnecessary!  In fact, their expediency
isn't completely implemented, and as such is currently "risky" to use. 
When all of the changes are removed, this aspect of OS/278 will again be
OS/8 compatible!)

The tentative system I am working on to replace all of this mess is
called OS/8 Version 5.  It will be compatible with existing PDP-8
programs, but only if they are run on PDP-8 hardware.  CUSP's will have to
be rewritten to work with new conventions that are acceptable to all
hardware, but older versions will continue to work where possible, i.e.,
on pre-DECmate machines.  The new CUSP's will retain all of the
functionality of OS/8 regardless of hardware they are running on, etc. 
All of the personal-preference-induced changes of OS/278 will be
eliminated in favor of the original OS/8 settings.  In some cases, it may
be possible to support the OS/278 variants as user-settable options
subject to restrictions.  For example, OS/278 changes the prompt character
from "." to "}".  While this seems to be merely a cosmetic change, it also
affects the exact nature of BATCH operations.  Regardless of choice, BATCH
files from one era of OS/8 family existence are incompatible, etc.  Some
"latitude" may be necessary to correct this, etc.

>		these bits at present (except TM8E and TA8E)."

For starters:

The TM8E and the TA8E don't count!  These are *not* disk device handlers;
they are strictly non-file-structured device handlers ala paper-tape.  The
use of a non-file structured handler causes a totally different action to
be taken since the entire device is a single file.  (For example, only a
non-file structured device can take a "soft" error return meaning
returning to the error return from a handler call with the AC *not* set to
a negative value.  This means the device is at End-Of-File, a concept
alien to a disk handler, etc.)

No handlers for disk devices use bits[9-10] and only the DECtape and
LINCtape handlers are elegible to use bit[11].  In point of fact, OS/8
only has a few pieces of code hard set to enable this bit at all!  This is
in the few places where it's a certainty that the next piece of data
needed is further down the tape than the present position.  Thus,
searching forward first saves a turn-around, since the default (when the
bit is 0) is to search backwards first.  (Note: statistically speaking,
most searchs *ought* to start backwards, because the data cannot be
accessed forwards.  This is the nature of DECtape and LINCtape.  Once you
shut down the tape, it rolls over the data you likely next want.  Unless
the next data transfer is at least three blocks forward of the last
transferred block, searching forwards is guaranteed to be the wrong thing
to do, and will only result in a double-turn around as the tape first goes
forwards, then reverses, traveling back to before the intended data's
block by three or more blocks less, etc., then turning around again to
transfer the data moving forward again.  By starting the search backwards,
the "extra" turn around is eliminated.  However, loading a file that is
many blocks forward of the directory is a case where searching forwards
first will be beneficial.  Unfortunately, there are few cases in OS/8
where this bit can be statically presented and it's hardly ever set, etc.)

Regardless of the setting of the bit, the ultimate data transfer is always
forwards, and only the overhead of search timing can be affected in any
way whatsoever, etc.

However, dependancy on this bit is ill-conceived, since it's possible to
write alternate handlers for the TC08 (and likely TD8E) that fend for
themselves in this issue.  Thus, a "smarter" DECtape handler will always
search in the best direction without being "told" to do it.  Additional
optimizations dynamically occur that OS/8 wasn't able to pass to the
handler merely because they weren't statically calculable, etc.

P?S/8 TC08 and TD8E system handlers already do this.  I have written an
alternate TC01/08 OS/8 handler that supports this (and ignores bit[11]). 
By using some techniques already present in the P?S/8 TD8E handler, it
appears likely that the TD8E can be similarly upgraded.

On the LINC-8, either hardware changes or an additional field of memory
are required to run either P?S/8 or OS/8.  The handlers for P?S/8 in 4K
and OS/8 in 8K already search in the proper initial direction.  (I wrote
both of them.)  The handler for an 8K minimum LINC-8 P?S/8 LINCtape system
(without hardware changes) also searches properly.  I have never had
access to a 12K LINC-8 to develop an OS/8 equivalent.

On the PDP-12, the handlers for 4K P?S/8 and 8K OS/8 LINCtape do not
search forwards ever due to limitations of the hardware (which *always*
searchs backwards unless you do a lot of work-around coding to counteract
the "automatic" nature of the hardware; this is beyond the scope of the
handler.  However, P?S/8 has an optional feature: the console overlay. 
When the console overlay is enabled, most of an additional memory field
is reserved for it.  Thus, most P?S/8 systems then require 8K, and a few
12K because of this, etc.  As part of the console overlay, two pages are
reserved for a "handler enhancement" that allows user interaction with
device errors reminiscent of the PDP-9/15 IOPS system, or even the MS-DOS
"critical" error handler, etc.  As part of the PDP-12 LINCtape version of
this code, the handler can actually force the tape hardware to search
forwards if appropriate!  It is possible to write a two-page OS/8
non-system handler or perhaps a two-page 12K system handler that would
also accomplish this, but the philosophy of OS/8 (and P?S/8!) is to always
attempt to write a one-page system handler to allow a minimum system (8K
for OS/8, 4K for P?S/8) so this was never done, etc.  The existing
handlers for 8K OS/8 on PDP-12 LINCtape are otherwise fine.)

Thus, the use of bit[11] is at most innocuous to the transfer, and more
importantly is not the best use of resources, since better handlers can be
written to serve the intended, but crudely implemented, feature of tape
search optimization.

Moreover, I want to incorporate the use of bit[11] as part of the "^C
abort" feature of OS/8 Version 5 to forever eliminate hardware dependancy
of the DECmates, etc.  The system call in 07600 would allow the low-order
bit(s) of 07601 to be set when a program aborts.  Thus, even if the
console hardware is incompatible, a program can still indicate it was
aborting due to ^C being hit.  (Note: on DECmates, KSF doesn't skip more
than once!  This is the key reason why traditional OS/8 console handling
can't work on a DECmate.  A program detecting the user's ^C keystroke
cannot convey that information to the keyboard monitor because KRS cannot
be used to pre-read the character without disturbing the flag, and KSF
clears the flag, thus it's no longer set!  By the time the keyboard
monitor could notice KSF skipping again, it's for an additional typed
character, not the ^C that caused the abort, etc.  By allocating bit[11]
to this purpose, an aborting program can signal the abort to the keyboard
monitor by executing ISZ I (7601).  By allocation of bits[9-11], there is
an additional safeguard against accidental multiple executions, since the
code could only be destroyed if executed more than seven times.)

cjl

---

From: [email-masked] (Johnny Billquist)
Date: 6 Jan 1994 14:26:15 GMT

>(potentially) relocatable binary for its "family"'s files.

Associated linker is not the same as a linker.
Even though only one program generate code for each linker,
the linkers are general programs, which very well could be
fed with output from other programs, just that none have been
written.

>the FORT family?  What is the equivalent for the MACREL family?)

You are right on all accounts.
There is no library maintainer for the "MACREL family".
You create libraries just by using PIP.
The format of the object file is such that you can have them
concatenated.

>and does nothing that a linker ever does.

That's why I put it inside parenthesis. It does a very meager subset
of what linkers do.
I know you dislike macro assemblers. :-)

>available to these CUSP's, and that *nothing* else would change.

TANSTAAFL is always true.
Another golden rule is, if it ain't broke, don't fix it.
Seems to me that DEC broke that rule...

>actually markedly different, something had to break!

Well, it seems to me that OS/78 definitely are different from OS/8.
Your accounting just give me more reason to believe so.
Why you started by saying it wasn't so I don't understand.

>available, thus wasting all of the user's typing.)

Hmmm, interesting. The only thing I've ever seen with ";" on OS/8 was
the original version of CCL that I was using, which had the ";" to
separate commands, like in UNIX. The was removed in CCLX, which I now
use.
To actually separate the commands, CCL created a file with the commands,
and called BATCH to execute them one after another.

>had a large price tag, and was unpopular.

Well, by this time then, you cannot claim that OS/8 and OS/78 are the same.
OS/8 stayed by V3D (or 3Q internally, which actually is what my OS/8
says it is...)

>"latitude" may be necessary to correct this, etc.

Well, when V5 comes out, I'd be interested in looking at it,
and maybe use it, unless something gets broken. ;-)

>alien to a disk handler, etc.)

Ummm, Charles. I think most people know this already.
The reason I mentioned TM8E and TA8E is because I was quoting the manual,
and it said so. If I had skipped that, the quote would have been
incomplete.
So I don't think there was any cause for a discussion about this.
(I just think you are stating the obvious, and are overdoing it.
 And also have a tendency to spin off into sidetracks on subjects
 that really isn't part of what's being discussed.
 But I'll admit you know more of the stuff than anyone else
 I've ever heard of.)

>forwards, and only the overhead of search timing can be affected in any

Okay, in that case I agree that the bit could just as well be removed.
Coding this into a device driver hardly takes more than about
5 words.

>code could only be destroyed if executed more than seven times.)

Sounds like a sensible idea.

---

From: [email-masked] (Charles Lasner)
Date: 7 Jan 1994 05:52:12 GMT

In article <[email-masked]>,
>fed with output from other programs, just that none have been

Nor are likely to ever get written!  The linking loader (aka linker aka
linkage editor depending on your background) has to be rewritten for each
family of utilities because each had different requirements at the time. 
In any case, I am not trying to be as pedantic on this point as you are! :-)

>The format of the object file is such that you can have them

That makes sense to me.  I always wondered why a specific utility would be
needed, since the binaries are created individually, etc.  Other than
concatenating them together, what's ever required of a library?

>That's why I put it inside parenthesis. It does a very meager subset

Yes, namely program loading.  But historically, loaders predate linkage
editor-type loaders, so ABSLDR is only a loader not deserving to even be
grouped with linkers!

>I know you dislike macro assemblers. :-)

Yes, because I don't see enough "reward" to overcome the overhead they add
in terms of time-to-compile, etc.  Even global symbol handling can be done
in PAL8 using a TECO macro such as the one I use for Kermit-12
maintenance, etc.

>Seems to me that DEC broke that rule...

Absolutely.  Also note here that I am *defending* MACREL in this case; it
was a management blunder for misusing it!  However, it is true that there
is no general method for OS/8 program swapping on a non-SYS: device.  But
had they instead used the method of CHAIN, then it would gracefully
complain instead of potentially crashing quite badly (as did occur!).

In this way, P?S/8 is somewhat superior to OS/8: any system program can be
on any logical unit that the system handler can address (generally 0-7)
with no restrictions regarding residence on the booted-to unit (which in
turn need not be 0).  Overlays are allowed since the system program can
determine its own loading block and logical unit and just has to calculate
offsets to create absolute block arguments, etc.

Incidentally, years before there ever was a MACREL, there was a version of
a BASIC for OS/8 that worked ala the P?S/8 method.  It depended on the
specified order of saving images of pieces of the program.  Then you
deleted all of the directory entries for the (secondary) pieces.  Instead
of the overhead of a CHAIN, it just calculated block offsets, etc. 
(Unfortunately, all of this is also restricted to SYS:!)

>Why you started by saying it wasn't so I don't understand.

Because OS/78 V1 *is* OS/8 V3D!  And the later versions are merely a
demented manager's preference for a system rename.

>and called BATCH to execute them one after another.

Exactly.  This was dropped in later versions.
>OS/8 stayed by V3D (or 3Q internally, which actually is what my OS/8

The name distinction is superfluous.  And up to OS/78 V4, you could still
make it call itself OS/8 with SET SYS OS/8.  BTW, other than the
development of BASIC into CBASIC (later renamed BASIC), a few handlers,
there really isn't much to OS/78 V3 other than dropping support for all of
the older stuff and not guaranteeing that the code won't contain
8/e-specific instructions (well, at least that some non-LINC-8, -8
instructions could "contaminate" the code).

BTW, OS/278 V2 does bring OS/8 users a benefit: the PAL8 Version B0 and
companion CREF Version B0 are superior to all prior versions.  A lot of
bugs were fixed, and there is only one minor "behavioral" anomaly
associated with interaction with the TTY: handler regarding type-ahead of
^Z.  I have checked the code and find no occurences of instructions that
would prevent operation on any model; this is why I distribute an ENCODEd
copy of them with the Kermit-12 package.
>and maybe use it, unless something gets broken. ;-)

I hope so!  We need user feedback in case anything gets broken, so we can
fix it!  The primary aim is to make one system work everywhere.  The code
of V3D is the closest to that goal; only the changes absolutely necessary
will be made; any DECmate-specific stuff will be added in ways that don't
"hurt" the -8 versions, other than the console-mandated changes, etc.

>and it said so. If I had skipped that, the quote would have been

I imagine some people aren't aware of the TM8E/TA8E-specific extensions. 
In any case, it's harmless to mention them :-).  Over the years, some
people who *should* have known this stuff none-the-less wrote defective
code!  (Such as disk device handlers that returned soft error returns, etc.)
>Coding this into a device driver hardly takes more than about

Coding the bit-related code takes about 5 words, but doing the
dead-reckoning from within the handler takes more!  Especially on the
TD8E.  Some of the hardware changes we made on the LINC-8 were designed to
allow the self-reckoning; the OS/8 bit was always ignored!

>Sounds like a sensible idea.

Actually, it could be ISZ'ed up to 63 times, but after 7 times it makes
the wrong field get saved!  After that, the page count is increased which
will partially corrupt the system!  Of course the reloaded keyboard
monitor will clear the bits out each time, etc.!

So far, no other word in field 0 has been shown to have any equivalent
potential for ^C abort marking.  I am also seeking other bits to enhance
the system date word!

cjl

---

From: [email-masked] (Johnny Billquist)
Date: 9 Jan 1994 03:22:59 GMT

>family of utilities because each had different requirements at the time. 

Well, I have, from time to time, considered writing a compiler which
would produce .RB-files...
Why waste a good linker? :-)

>In any case, I am not trying to be as pedantic on this point as you are! :-)

Nope. Sorry if I'm getting on your nerves... ;-)

>concatenating them together, what's ever required of a library?

Well, I like to be able to replace modules in the library, be able
to check which modules that are in the library, and what versions
they are. Also, specific dates when different modules were added
to the library can be handy.
All but the dates can be solved within the format today. Maybe
I'll write a program for this. when I have time (which probably
isn't any time soon... :-( )
I can see some uses of a library program, but I can live without
it as it stands today.

>in PAL8 using a TECO macro such as the one I use for Kermit-12

Guess I'm lazy, and spoilt by MACRO-11... :-)

>demented manager's preference for a system rename.

Well, OS/78 V1 isn't the definition of OS/78 as a whole, is it?

>Exactly.  This was dropped in later versions.

A little sad, I agree, but I can live without that one.

>"hurt" the -8 versions, other than the console-mandated changes, etc.

Sounds like the correct approach. Next question is; can it be done?

>potential for ^C abort marking.  I am also seeking other bits to enhance

Hmmm, aren't there any free bits left in 07777?
Also, what is address 17777 used for? (I can't remember it being used
for anything, and the OS/8 Software Support Manual claims it
is reserved for future use...)

	Johnny

---

From: [email-masked] (Charles Lasner)
Date: 9 Jan 1994 12:52:44 GMT

In article <[email-masked]>,
>Why waste a good linker? :-)

The original intent was to write a high-performance FORTRAN that replaced
FORT/SABR.  The compiler was canned, but Stan had written enough of MACREL
that they let him finish the initial offering and even get a manual
written for it.  I have his followup work on a next-generation MACREL
which was never completed (but might fix some limitations/bugs of the
released MACREL) he did as a hobby for awhile, etc.  The compiler was
never started, other than some circumspect overall specifications, etc. to
convince the suits that the product was even needed!

>I can see some uses of a library program, but I can live without

As I understand it, some of this is also lacking in the F4 family.  Some
of the utilities to implement some of what you seek were user-written
though.  (And in a most unlikely language - PASCAL!)  Perhaps you could
more readily modify the PASCAL programs to accomplish the requirement!

>Guess I'm lazy, and spoilt by MACRO-11... :-)

Just put it this way:

You have written -8 code the way -11 code is often written.  Sometimes
expediency is a goal in and of itself.  (And also a lot of other
trade-offs you could add, etc.)

But the simple fact is that P?S/8 and OS/8 "proper" couldn't be developed
in MACREL assuming it pre-existed compatibly on another "convenient"
machine.  That kind of environment doesn't lend itself to the tricks that
make the existent code possible.  Much of the code is difficult to
"maintain" (by the conventional definition of maintainence - meaning that
a mediocre individual can quickly step into the shoes of the original
author and fully understand the nature of what can/cannot be done to the
code as it stands; for proof of this, just look at all of the introduced
bugs in OS/278 that have no particular hardware dependency as the "excuse"
for them, etc.!) and MACREL would only make such a task more difficult, etc.

>Well, OS/78 V1 isn't the definition of OS/78 as a whole, is it?

It appears that strictly speaking, "OS/78" means *only* all of the following:

1)	You can execute the command SET SYS OS/78 to enable it.

2)	You can execute the command SET SYS OS/8 to cancel it.

3)	During it, the VERSION command indicates it's present.

4)	During it, all programs with bit[5] of the JSW set are subject to
the restriction that the R, RUN, and GET commands will not function.

5)	In memory, the only indication of the various modes is whether the
HLT at 07604 is a HLT, CLA HLT, OSR HLT, or LAS HLT.  OS/8 is HLT, and
OS/78 is CLA HLT.  The other two cases are attempts at being known as
VT278 and OS/278 mode respectively.  It's not clear (nor consistently
implemented!) just what these actually are, but my best guess is that they
mean that the terminal can be expected to be a VT-52 or a VT-100.  I would
recommend that they be re-implemented as the object of SET TERMINAL
commands that actually do that!  Clearly, some OS/278 programs are
attempting to check these bits to gain "permission" to be outputting VT-52
and VT-100 escape sequences, but in inconsistent ways, etc.

However, there is no clear way to implement properly what's implied
anyway!  There is no purpose served in tieing together the notion of the
command restriction and also the terminal type.  This leads to the
limitation that OS/8 can never have a designated terminal type, or
alternatively that OS/78 restriction is a subset of designating that you
have a VT-52 or VT-100 present.  (Perhaps someone else can suggest what
they were attempting to designate here!  I would suggest an alternative:
the other bit means that there is a VT-52 or a VT-100 present.  All of the
programs are attempting to do tricks such as clear-screen.  You can write
code that will work on all VT-52 and VT-100 to do that without caring
about the difference; merely add code to enter VT-52 mode first; it's
ignored on an actual VT-52 mode terminal or emulator.  Then the bit
controls whether you can presume the VT-52 screen enhancements at all, etc.)

>A little sad, I agree, but I can live without that one.

It complicated the keyboard monitor, and was flakily implemented.  And it
still depended on the ability to chain to BATCH after the fact, which on
8K systems isn't allowed!  Moreover, there are *fatal* commands to BATCH
such as SQU SYS: /O.  It's better to restrict the usage of "safe" commands
to formal BATCH input (*.BI files) than to also allow impromptu files
created by (perhaps accidently!) typing a ";". 

>Sounds like the correct approach. Next question is; can it be done?

To implement what I want to do, all that needs to be done is the following:

1)	Plan for all DECtape/LINCtape handlers to be upgraded to obsolete
the use of bit[11] of the function word.  However, the worst case
consequence is that ^C abort causes the core-save function call to search
initially in the wrong direction and then turns around and proceeds as
before, etc.

2)	Rewrite all portions of OS/8 and its handlers that are generic to
DECmates.  Things like RK8E handlers need not be changed.  Only the
console-related code needs to be changed.  However, some of the programs
have already been otherwise modified as versions migrated to be able to be
run on DECmates such as the F4 run-time system, etc.  Some of the changes
introduced in the newer versions need to be retrofitted back into the
older code or vice-versa.  Note that the rewrite also includes
user-written programs and handlers.  Also, some things such as
user-written RX handlers may not be able to be run from the DECmate II or
DECmate I or VT-78 due to space or speed limitations.

3)	Some of the DECmate-specific changes depend on work in progress
that stems from disassembly of code with no source available.  Much of the
work is already done however.  There will come a point where the OS/8 V5
code will be stable per se, but still won't completely function correctly
until "slushware" changes are made as well, etc.

Due to the large amount of work that needs to be done, it's likely that
this will happen gradually.  Along the way, various "experimental"
releases will tend to happen where it's known what can't possibly work
yet, etc.

Note: I have already completed the P?S/8 equivalent of this about 95%. 
Some of the remaining few percent isn't done because the DECmate
environment has suggested alternative ways to implement certain things
already implemented in a way that is either inefficient or slightly
incompatible on a DECmate, but works fine on the -8's.  Other than
handlers, this only involves the extended software interrupt environment
of the P?S/8 console overlay, especially as it relates to providing
services to programs such as FOCAL.)

(Note:  P?S/8 supports a concept totally lacking in OS/8 - an alternate
console "overlay".  There is an orderly mechanism in P?S/8 that allows any
and all cogniscent programs to stop using "raw" device 03/04 code for the
console (and raw device 66 code for the LPT the way some OS/8 code also
does!) and instead call defined software routines in the overlay to
accomplish the equivalent to a configurable console device.

Existent console devices already implemented include using a VT8E and also
alternate KL-type interfaces to other external terminals and printers
w/keyboards, etc.  All of the P?S/8 system programs have already been
upgraded to support ^S/^Q whether on the device 03/04 interface of either
an -8 or a DECmate or to the logical console device.  However, all of
these programs (except P?S/8 FOCAL) are non-interrupt-driven.  The logical
LPT support even includes some print buffering that noticeably speeds up
printing on parallel printers, etc.  However, for maximum efficiency in an
interrupt-driven environment, the mechanism for interrupt handling has to
be redefined.

The basic problem is that a typical program already knows what devices it
handles interrupts for, and just has an interrupt routine for it, etc. 
But when the console and LPT routines are generic, they have to be hooked
into the interrupt handler at the correct point so that the former
hardware-oriented interrupt handlers can be replaced by software calls to
the generic routines.  Not all of the details are worked out
satisfactorily, but a rudimentary version already exists.  Currently, you
are obliged to inspect a table of overlay-supported devices, and delete
any devices you may be redundantly be handling, such as device 03/04. 
Various event flags are set after you call the overlay's interrupt scan
routines that you can inspect, and then make calls to deal with the
associated data, etc.  But at present, there can be some confusion about
exactly which device is which in the most general implementation of the
routines. 

Consider the following example:  The console could be defined as a
replacement for 03/04 and actually goes to 03/04 or alternatively to
another KL-type device such as 40/41.  (Which doesn't matter to the
example.) Alternatively, the console may be defined as the VT8E which
generates keyboard input and keyboard input interrupts, but outputs
without an interrupt structure.  (You merely output by poking at memory,
possibly reformatting memory, but the call to the console routines
finishes the job without subsequent interrupt, etc.)

Beyond this, FOCAL may itself be running with a patch file that creates
FOCAL-12-like features where display graphics functions may be active,
and, *if* the console device is the VT8E, it wants to additionally
"time-share" the hardware between text mode and graphics mode switching
context at the video clock rate, and additionally enable various commands
that determine which of either of these modes (or both!) are being
enabled.  Additionally, if FOCAL determines that the console isn't the
VT8E, it wants to output to the VT8E itself using its own built-in
routines as part of the VT8E patch package, etc.  Thus, there needs to be
a more orderly (and less confusing!) mechanism that determines whether
FOCAL, as an application program has total, partial, or no control as to
whether to context switch the VT8E hardware as determined by whether the
console device coming in is either none, partial, or completely using the
VT8E hardware.  This is also complicated by the fact that the VT8E also
could be the parallel LPT interface, with a slight incompatibility: the
interrupt enable for the LPT isn't in device 66, but rather is shared
KL-style with the keyboard of the VT8E.  (DEC envisioned the VT8E as a
hardcopy terminal with a DMA screen, keyboard and printer.  The standard
VT8E is delivered complete with a diagnostic report that it passed the
DECwriter I (parallel) tests!)

(Since experiencing the needs of making the DECmate work in this kind of
interrupt environmment handled by generic software at times, I have begun
to rethink some of the intended mechanisms of the console overlay to best
serve all requirement in a "cleaner" way.  All of the non-interrupt
implementations are actually fairly elegant however, etc.  And were there
not the complications of the console overlay, all of the console-relevant
DECmate hardware differences are currently solved; the current version of
P?S/8 FOCAL *does* totally run on the DECmates.  When the code is
redesigned, it will additionally run under all of the VT8E variants
possible on an -8/e as well; currently it does run under most of the
"useful" configurations (but not all of the possible cases!).)

In any case, the non-interrupt aspects of upgrading P?S/8 wasn't that much
work; I think it gives a yardstick for doing the equivalent in OS/8, etc.

>is reserved for future use...)

I believe all of 07777 is used up currently;  I would be open to a
redesign of BATCH to possibly free up some of it, etc.  Note that there
was a user-written batch processor that can run in 8K!  By better
integrating it into the OS/8 environment, perhaps some of the overhead of
BATCH could be eliminated.  (Certainly the 12K requirement!  Note that
P?S/8 runs in 4K, BATCH or no BATCH!)

I think 17777 is basically reserved for BATCH, along with a few words in
27777 and nearby.  It would be nice to free it up as the date extension word.

Note that even when the date extension gets defined (and only a few bits
are needed!  I could even live with using 07601 bits[9-10] for the date
extension and [11] for the ^C abort with no margin for the error of
multiple ISZ I (7601) mistakes.  This would make the date last four times
as long as the 32 years of 1970-2001!), you still need to have two extra
information words in the directory to implement it better than the current
imprecise to 8 years kludge.  But many people complain that even one extra
word is too many, and have a whole bunch of little files with no dates and
still have wasted disk space on the end of the device!

Of course if you have only a few files, as most of us do, the disk runs
out before the directory space.  And further, there are user-written
"partition" utilities to encapsulate files within their own directory
space, and only take up one OS/8 directory entry.  If they are upgraded,
this allows a means for everyone to at least have some viable way of
maintaining file dates at some level, etc.  Note that Kermit-12's ENCODE
utility warns the user that the date in the file is imprecise, and asks
the user to set the proper 8-year group at the other end of the decoding,
etc.  If we had this upgraded mechanism, ENCODE could be upgraded to
provide precise information if available, etc.  In any case, complete date
information I would want bundled into any scheme to extend the viability
of the date mechanism itself! 

cjl