Subject: Format of .SV files?

From: [email-masked] (Megan)
Date: Fri, 31 Dec 1993 00:18:03 GMT

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

					Megan Gentry

---

From: [email-masked] (Charles Lasner)
Date: 31 Dec 1993 07:28:14 GMT

>file.  Can someone possibly post it?

There have been several extensions written to the .SV file from various
releases of the OS/8 family.  I doubt if OS/278 supports some of the
extensions which are associated with the KT8A.  In any case, I can lookup
the exact details if need be.  From memory though:

It contains a count of up to something like 9 entries that are arguments
to be passed to a handler consisting of the page count and field in the
proper bits in one word with bit[0] and [9-11] clear (page count in [1-5]
with 00000=40 octal, field in [6-8]) and the transfer address in the other
word.  I think the next word after the count is the overall Job Status
Word for the image which gives info such as whether 00000-01777
should/should not be saved before loading, likewise 10000-11777 when this
program swaps with the USR or command decoder, etc.  The remaining words
are the pairs of the entries themselves followed by junk.  After this
header block comes the image data itself.  The minimum size would be a
record where the first half is loaded and the other half of the record is
junk.  The entry for that data would indicate a one page transfer, etc. 
The maximum size for that part of the image would be 32 pages or 16
records.  Even counts always load whole records while odd sizes indicate
that the last record in the data segment is to be only first-half loaded,
etc.  Further, the order of the image is supposed to be highest loading
field first so that the problem of how to load field 0 is done only after
all other loading is complete.  This allows the data to be transferred to
scratch blocks on the system device so that a final call to the handler
can bring in the remaining data.  Note that this means that you cannot
tell where the file actually is, since the program is started from that
last call (whoops!  I forgot a header word which is the starting
address!).  Note: at that criticl point, that call to the system device
just halts on an error return!  (No part of OS/8 is left in memory to
handle errors!)

One problem of version creep in OS/8 is that the JSW bits aren't
consistently handled!  As of OS/8 V3D, a bit (I believe [5]) was added for
the dubious purpose of execution restriction to implement what was
originally known as "OS/78" mode.  The idea (invented by a long departed
manager) was to implement a "less is more" campaign where OS/78 mode
inhibits the "R" "RUN" and "GET" commands, but only if this bit is set. 
This requires that CCL be present to avoid the inability to access the
program.  (Note, in an infamous event at a DECUS Symposium, this manager
was publicly embarassed when an astute user walked over to his demo
machine and typed "CCL <return>" and made his system self-destruct!  The
command "CCL" is the CCL command to disable CCL entirely.  The only way to
reenable it is to type "R CCL".  However, the image of CCL.SV has the
infamous bit set, thus this wasn't allowed!  Thus, the system was
permanently and hopelessly corrupted until the image of CCL.SV could be
modified from another system/program that wasn't influenced by OS/78 mode,
etc.)

Somehow, as of OS/278, there is a problem with OS/78 mode's
implementation.  Whatever OS/278 mode is, it's clearly a superset of OS/78
mode.  However, the images within OS/278 don't have the bit set, nor are
they particularly sensitive to it.  Instead, if an image has a perverse
combination of bits set, an unwanted byproduct is that you cannot use the
three commands (R, RUN, GET).  For example, ABSLDR.SV has most of the
optimization bits set.  This eliminates some of the overhead regarding
memory swapping of the first quarters of fields 0,1 regarding command
decoder and usr.  By clearing the optimization bits somewhat, it's then
possible to use R ABSLDR in OS/278, yet the stock version cannot.  Also,
it's clear that the bit does the intended function also (it takes
noticeably longer on an RX50, etc.).

Clearly all of this is repairable, but the sources of OS/278 have to be
finely searched for newly introduced bugs.  Note that this has nothing to
do with the DECmate hardware, and was likely introduced in either OS/278
V1 which was never publicly released (but shows up on utility disks) or in
OS/78 V4 (which was riddled with bugs and was intended for use on 8/e, 8/a
and DECmate I).  Additionally, there are bugs that interact with the SAVE
command in OS/278, which can be demonstrated to fail in ways former
systems do not, and this includes mis-settings within the JSW as an
additional problematic consequence.  (I have documented some of this in
the Kermit-12 .BWR file k12mit.bwr.)

In any case, the lowest level of data in a .SV file is the 12-bit word. 
Thus, any cross-system representation of a .SV cannot be based on any
8-bit byte scheme as can a .BN or any text format (such as .PA).  It is
hoped that someone can formulate an appropriate 12-bit format for
8-bit-byte-oriented machines so that a version of PDP-8 ENCODE can be
written for these machines.

If the ENBOO utility is used and MSBPCT is used on the 8-bit end, the
results of what is a .SV file on the 12-bit end has to be reconstructed on
the 8-bit end using the standard "3 for 2" pack/unpack method of
constructing 2 12-bit words from 3 adjacent 8-bit bytes in the stream of
data.  To accurately render the original .SV file, a utility must also be
prepared to confirm that the file is an exact multiple of 256 12-bit words
in length.

This principle is used in the DECODE utility automatically.  At the EOF,
the DECODE utility demands that there be little or new "overhead" bytes
left, and also that they would decode to a single (partial) grouping of
encoded data, all members of which are 0000.  (Or alternatively, since
compression is supported, that the file ends on a block of compressed
data.)  Any other form of ending is a sure sign of file corruption, etc.

As an aside, there used to be a utility called EPIC.SV that was used to
create files that were formerly .SV files, but instead could be
represented in the form of 8-bit bytes at some level.  Presumably it was
reversible in function.  In essence, this sounds like what .BOO encoding
accomplishes except that there isn't any printable encoding, thus the epic
file could potentially be smaller.  (Note: ENCODE and .BOO support
elementary repeat compression; epic clearly didn't, so certain images
could compress to a smaller size with .BOO or ENCODE, etc.)

cjl