TSS/8
Tim Radde
what is available for TSS/8
and to try to create an RK05 disk instead of the RF08 disk. If I can
do that I'll then try to
modify the resident monitor code to read/write RK05 tracks. I Know
the RK05 can't read/write single words like an RF08 could. But I
think there are ways around this. I hope to get something that will
run on my 8e, since my 8i doesn't have enough memory. I learned
computers on an 8i running TSS/8 so this is my main reason to try
this. Vince is also
helping as he is interested in seeing this run too. Any suggestions
or ideas feel free to
pass on. I know someone modified TSS/8 like this years ago and they
said it worked.
So it can be done, it's just not easy as there isn't alot available
for source.
cjl
I don't have specific experience with TSS8, but I do have a lot of
time spent with RK8E [and RKS8E] not to mention the RK8F [which is the
kludged-up version for the DW-8/e, but programs identical to the RK8E;
the RKS8E is a superset that might have marginal use in certain
applications, etc.
I don't know specifics about TSS8 structure, but what I do know is the
organization of DMS, especially on DECtape. This system depends on an
essentially non-translatable feature and was thus essentially a dead-
end. All other software in the LINC/PDP-8/LINC-8/PDP-12 universe is
based on multiples of 128 words [or 256 words] and not 129 words. A
word-oriented disk allows you to write your own ticket, but you still
have to do a lot of mapping fighting the "unnatural" arrangement since
the actual tracks are organized in a more "friendly" 2 to the
<whatever> manner just about every device is.
Thus, if you want to maintain a logical call of essentially 128 word
records, with an associated "link" word that tells you [in the 12-bit
sense, not any larger] where the "next" block is, you can do that, but
it cost you in all sorts of ways when you cannot map the device the
way you can on a DF32/RF08 [again, it is still requiring mapping and
it's messy, but it can be done because you can specify a single-word
transfer starting just about anywhere.
One approach is to emulate the DECtape's link word approach, namely
that the link word is the physical 129th word, a natural for DECtape,
nothing inherently obvious for DF/RF but clearly you can just lay the
words out in order there.
On the RK08 [NOT the RK8E!] you can create a transfer for any number
of words you want, with the following proviso:
Any whole multiple of 256 words is always read/written as you
specified. Should there be any additional transfers, this just
extends the operation, up to a total of as much as 4096 words.
However, what if the transfer is say, for a smaller amount [as the
last, or perhaps only portion of the current transfer]?
In that case, if it is a read, the number of words requested is
tranferred, and the rest are not. If you designate them as waste
space, that works fine. Writing works similarly, except that be
forewarned, the rest of the 256 word record is also written out,
presumably with all 0000, but certainly with junk, not data. [Of
course you could set the word count for writing to anything you want,
as long as the rest are designated junk, whatever the junk is, who
cares.
Thus, on the RK08 [which is half the size of the RK05], this would be
fairly straight-forward, other than the fact that, neglecting the link
word [which is essentially the cause of the problem] you are wasting
exactly half of the disk space. [Of course an RK08 cartridge is
bigger than an RF08, but this difference starts to hurt when you
compare it to a 4 or special-order 8 platter version of an RF08.]
The RK8E/RK05 represents a further challenge: There is no way to read/
write an arbitrary word count. All you get is either 256 words read
or write, or you get the first 128 words read, ignore the rest, and
you can write 128 words, but the rest of them are all 0000. Thus,
there is no direct way to read back 129 words, unless you can tolerate
all 256.
I had a vaguely similar problem in P?S/8.
P?S/8 is similar to OS/8, except that the media is addressed to the
nearest 128 word block, not the 256 word logical block better
described as record. [In some OS/8 documentation, they confusingly
inter-change the two.]
For example, on a DECtape, P?S/8 addresses the blocks as the "natural"
progression of the tape physical blocks. For any block, the 129th
word is ignored. On writes, what actually happens is that the 129th
word is junj, and is hardware dependent as to what exactly gets there
[such as 0000 or perhaps a clone of the 128th word; not really
important other than perhaps to diagnostic programs] This is trivial
to program for a TC01/08 thus, the entire handler for this fits into
07600-07777. This is also true for the DMS and also OS/8, which is
why OS/8 doesn't require 12K for a system devicce based on TC01/08,
and thus DMS and P?S/8 can run in 4K on the same hardware.
For OS/8, the same situation applies, except that in OS/8, the
physical block you transfer is the logical record multiplied by two.
In both systems, transfers are whole pages, one through 32 depending
on the call. The reason this works is because in OS/8, any call for
an "odd" number of pages must start on an "even" boundary, a
consideration that is moot in P?S/8 on DECtape. In both systems, the
latest block is read or written by always setting the word count to
128 and letting the 129th word never read back, and not care what the
129th becomes.
And in the DMS, the 129th word matters, because it becomes the link
word, which must be appended onto the end of the user-calling buffer,
so that all 129 words are written out. When reading, the 129th
becomes typically the link word for a potential future transfer, etc.
Both the DMS and P?S/8 care about each tape block, while OS/8 only
cares about the "even" ones should a transfer ever be initiated with
an "odd" count. The theory is that the "odd" half of the double-block
record now has junk, merely being required to be transferred, but no
particular contents are required, etc.
Transferring these notions to the RK8E, OS/8 wins, and partially this
is because, in a rare spirit of cooperation between DEC hardware and
software people, the hardware was modified to enable OS/8 to work;
without the hardware mod/kludge, OS/8's support of the RK8E would
likely be abysmal or perhaps even impossible.
For OS/8, the reads are a piece of cake. If this is an "even"-only
transfer, just set the "do one half of the record" bit. When reading,
the contents of memory adjacent to the caller's read buffer is not
corrupted by the read operation. When writing, only the first 128
words are written, as OS/8 requires. The second 128 words are all
0000. Since OS/8 basically doesn't care, this is acceptable. Again,
all OS/8 cares is that subsequent reads for double-page purposes
complete without error. Those who write odd page counts expect all
subsequent usages to not care about the contents of the "second-half"
of the record other than basic CRC integrity. And of course, for all
two-page reads or writes, the hardware works perfectly fine.
However, this scheme is an anathema to both P?S/8 and the DMS. P?S/8
demands that it be possible to write a "second-half" of a physical
record, because in P?S/8, blocks are addressed to the nearest 128-word
section; that it might actually be a half of a physical record is
irrelevant;that's the handler's problem!
In OS/8, a problem such as this [were it to exist] would not be
possible to fix [which is why they asked for the hardware to do what
it does!]. However, due to inherently far superior design [with all
modestly; it's just flat-out obvious], P?S/8 totally solves the
problem:
The handler in P?S/8 consists of either one of two cases [OS/8 has two
cases as well, but they are merely a 1 page handler and a two page
handler; this is just not even close for solving a problem such as
this]. The P?S/8 cases are: 1) The handler fits in 07600-07777, just
like when OS/8 or DMS have no particular problem, making P?S/8 able to
run in 4K, DMS able to run in 4K, and OS/8 in 8K, not 12K. 2) This
case parts company with all of these other systems. The handler gains
an additional 1024 words located in x6000-x7777 where x is the highest
field of memory implemented, at the minimum 16000-17777 on an 8K
machine through 76000-7777 on a 32K machine. Initialization blocks
are reserved for the code that figures out where stuff goes, and moves
the code accordingly, thus all of that extra 1K is live space for
handler code.
To solve the problem handily, the code, which is actually only about
two pages long, includes an additional 256 word buffer within the
handler space [thus the RK8E handler only needs about 512 of the 1024
words available! Thus, the handler can include exemplary track seek
algorithms and detailed error handling. OS/8 uses marginal track seek
and horrible error handling. Literally, any error must be handled as
a worst-case error, and this can lead to pathological cases on
marginal media in fact; P?S/8 has rescued data on flakey-condition
RK05 disks where OS/8 literally gave up! When you initiate a
recalibrate sequence for merely a read-data CRC problem, you are more
likely to never get past the problem, etc. Again, OS/8 has no extra
space for other than poor handling of the disk particulars; on a scale
of 0 through 1, it works. P?S/8 has the ability to give it all to
whatever is required. Data errors are retried, and only cylinder seek
errors ever initiate a recalibrate, etc. And there is still tons of
space left for the handler to be made even larger.]
Now that a buffer is available, all of the two-page transfers portion
of a caller are handled as OS/8 would in terms of addressing, except
that the physical record is actually halved first. This leads to the
problems of what to do with the problematic single page transfers.
If the requested logical block happens to be the first half of a
physical record, just set the "1/2 transfer" bit and all is done if
this is a read.
If the requested logical block to be read is a second-half of a
record, you have to read in the entire record into the internal 256
word buffer. Then move the second half of the buffer to the user's
buffer space.
If the requested operation is a one-page write, you have to first read
into the internal buffer the entire record, then move the user's data
over the interal buffer; which half depends on whether the original
call was for a first-half, or a second-half. In any case, when done,
write out both halves of the interal buffer.
By handling all of the well-"aligned" transfers two pages at a time,
maximum transfer time is achieved, same as with the one non-
problematic one-page read; the other three cases involve transfers
through memory as well as DMA, and in the case of writing, both read
before and write afterwards.
[Note: P?S/8 non-system handlers work the same way, except that the 4-
page non-system handler has its own internal buffer. Unlike OS/8, P?S/
8 non-system handlers are not limited to a page or at most two, but to
a maximum of an entire field, measured in pages needed. As an
implementation restriction, you cannot load a handler into page 0,
just as in OS/8's case, except in the singular exception where the
handler is exactly an entire field. In this case, the code is already
loaded exactly where it must be, complete with the use of its own auto-
index registers. In OS/8, handlers are page-relocatable, but always
run in field 0. In P?S/8, non-system handlers must be both page and
field relocatable.]
Thus, this suggests a method for use with the DMS or similar code that
is too-heavily invested in either 129-word-oriented devices or one-at-
a-time-addressing oriented devices, at least for the RK8E. First, as
in the RK08 case, you have to give up on attempting to save the space
wasted in the rest of the second-half of every physical record. At
least in the RK05 case, the disk is twice as large [and so is the
wasted space!]. You can always write out a buffer consisting of the
128 data words with the 129th word pasted into the next word. If
necessary, you can save the former contents, and restore it after the
transfer, but only if you can guarantee that destruction of that word
is a safe thing to do. I don't know the innards of TSS8, but this
probably means you have to define a bigger handler space, and
similarly to P?S/8, the handler has to "own" a private two-page buffer
to handle all of the problematic cases. This will run a lot slower
than an RF08, not only because of the seeking, but because the data
has to first DMA, then move in memory, and perhaps DMA after the fact
depending [last case not likely if you handle it correctly]. [One of
the three operations shoudln't apply for all cases of practical reads
and writes required to be supported.]
Without any more specific info about TSS8, this is as far as I can
take it. But this is why only a few devices can support these
systems. the only other device DMS can run on is a 129 word/block
LINCtape for use on the PDP-12.
cjl
John Everett
wrote:
>I don't know specifics about TSS8 structure, but what I do know is the
>organization of DMS, especially on DECtape. This system depends on an
>essentially non-translatable feature and was thus essentially a dead-
>end. All other software in the LINC/PDP-8/LINC-8/PDP-12 universe is
>based on multiples of 128 words [or 256 words] and not 129 words. A
>word-oriented disk allows you to write your own ticket, but you still
>have to do a lot of mapping fighting the "unnatural" arrangement since
>the actual tracks are organized in a more "friendly" 2 to the
><whatever> manner just about every device is.
As the designer and coder of the TSS-8 file system all I can say is,
"What was I thinking???"
--
jeverett3<AT>sbcglobal<DOT>net (John V. Everett)
John Everett
wrote:
>On Jun 14, 8:09锟絧m, Tim Radde <tra...@excite.com> wrote:
>> Well, I have gotten the urge again to try to figure out how to build
>> what is available for TSS/8
>> and to try to create an RK05 disk instead of the RF08 disk. 锟絀f I can
>> do that I'll then try to
>> modify the resident monitor code to read/write RK05 tracks. 锟絀 Know
>> the RK05 can't read/write single words like an RF08 could. 锟紹ut I
>> think there are ways around this. 锟絀 hope to get something that will
>> run on my 8e, since my 8i doesn't have enough memory. 锟絀 learned
>> computers on an 8i running TSS/8 so this is my main reason to try
>> this. 锟絍ince is also
>> helping as he is interested in seeing this run too. 锟紸ny suggestions
>> or ideas feel free to
>> pass on. 锟絀 know someone modified TSS/8 like this years ago and they
After my first tongue-in-cheek response to cjl's posting I actually
read the rest of it. I also wrote DMS (Disk Monitor System) so it
might appear that I was in love with 129 word logical blocks.
Turns out when DEC was developing the RF-08 and DF-32 (I think those
were the model numbers) I was assigned to write the software. At the
time I didn't have a working disk available, so I wrote a small
DECtape driver and debugged DMS on DECtape. The word addressability of
the DF-32 made it easy to just carry the 128 plus link word design
over to the disk.
For the life of me I don't know why I carried that concept over to
TSS-8. About all I can think now was that in my youthful naivete I
thought all disks were word addressable. :-|
cjl
<jevere...@sbcglobal.DEFEAT.UCE.BOTS.net> wrote:
> On Sun, 14 Jun 2009 22:57:55 -0700 (PDT), cjl <clasyst...@gmail.com>
> wrote:
>
> >On Jun 14, 8:09 pm, Tim Radde <tra...@excite.com> wrote:
> >> Well, I have gotten the urge again to try to figure out how to build
> >> what is available for TSS/8
> >> do that I'll then try to
> >> the RK05 can't read/write single words like an RF08 could. But I
> >> think there are ways around this. I hope to get something that will
> >> run on my 8e, since my 8i doesn't have enough memory. I learned
> >> computers on an 8i running TSS/8 so this is my main reason to try
> >> helping as he is interested in seeing this run too. Any suggestions
> >> or ideas feel free to
We can forgive your "youthful" foolishness :-) . But perhaps only
barely.
Just to make your "legacy" be fully understood:
On the PDP-12, while the original standard LINCtape format is 256
words/block to conform to original LINC [and faked often, but not
always!] LINC-8 standards, OS/8 and P?S/8 are implemented on the
PDP-12 using 128 word/block LINCtapes.
That should be the end of the story, however: Various to use your
words "naive" utilities were written within DEC to allow for tapes to
be formatted with 129 words/block "just in case".
To make matters worse, Mark Hyde, of Syracuse University implemented a
LINCtape handler for the DMS, so there is somewhere a working copy of
DMS on the PDP-12 Linctape. It doesn't end there.
Due to various tape hardware particulars, LINCtape capacity has to be
larger than DECtape for the same physical tapes. However, since the
extraneous extra word is expected to be there, standard directory
lengths within OS/8 assume the LINCtapes logical length is more in
line with standard DECtapes, despite the clear expectation that
LINCtapes should have more blocks. [Note: LINCtapes have simpler tape
structure, so you can get more blocks in the same tape space. You
lose such internals as a pre-final word detection thus no double-
buffering in the hardware, just a single final word, no ability to
transfer data while moving backwards, just search, so whatever was
doubled up on both ends of the block, doesn't happen on LINCtapes, and
the lengths are multiples of 12-bits, not multiples of 18 bits. Thus,
inherently you get more blocks on the tape. Additionally, there could
be a slight redefinition of the nominal tape density all other things
being equal, at least when you format the tape on the LINC-8, which
could make an additional small contribution.] If 128 words/block were
the norm, it would have to follow you could get more on a LINCtape
there. [Note: I am talking about default values. We often patch OS/
8 PIP to get whatever you need. In point of fact, LINCtapes are often
even still longer, and of course especially if you don't have any
129th words to waste space. Even DECtapes are often even longer than
nominal, so a semi-standard of 3300 blocks exists for most DECtapes
instead of the default 2702 blocks. LINCtapes could actually achieve
4000 octal blocks! In P?S/8, there are equivalent techniques so
directory extents match the hardware instead of a default value, etc.]
And yet, it doesn't end there either!
Due to the known proliferation of these 129 word/block LINCtapes, the
system handlers of both OS/8 [OS/12] and P?S/8 have to support as
standard features the presence of the extra word annoyance. [Note:
All system handlers and many non-system handlers are already
compromised as it is; needless annoyance support is not welcome, but
we were forced to deal with this instead of improving overall
performance and error handling, etc.]
On the PDP-12, the tape transfers are DMA totally automatic once
initiated. There is no way to shorten the length of the transfer such
as on the TC01/08 because there isn't any sort of word-count
register. Thus, if the tape is 129 words/block, all of them will
transfer.
Thus, the algorithm used in both P?S/8 and OS/8 has been severely
compromised: If the transfer could have depended on the 129th word
NEVER be present, you could just tell the hardware to do all of the
blocks as a group. Instead, it does one block at a time, fixing up
for each one, and iterate as many times as required. Techniques
fortunately are implemented so that the tape motion is not
compromised; it's more overhead, but it did fit into the handler [thus
compromising error handling in a short amount of code space.]
Each block is handled thus: Assume the DMA read will destroy the 129
word, meaning the word defined BEYOND the designated DMA buffer the
user-call defines. For example, if you want to transfer 1 block into
07400-07577 [a totally reasonable example], the handler first saves
internally the correct contents of 07600 [a word you wouldn't want
compromised. Notice this could be the source of a corrupted program
exit if the handler breaks down at the wrong moment in time!] After
the DMA finishs and there are no errors, the contents of the
endangered word is restored from the internal save word within the
handler [hopefully!]. Then control is returned to the loop iterating
each of these onesy transfers.
[Note: The theoretical consequences of this specific failure, and it
can happen essentially equally in P?S/8 or OS/8, are really bad.
Whatever was the 129th word on the tape block is now what is in
07600. Execution occurs, if the system restart location is reached,
of a a random value. And what is likely to be there? Literally what
is there is the random contents of the first word in memory past the
designated write buffer when the block was last written on perhaps
years ago on a different computer. Good luck knowing what that would
be! And assuming it was 0000, that is the instruction AND 0000
effective a NO-OP. But what is in 07600 in both O/Ses is a call to
the system handler; I think in OS/8 JMS 7607 or 4207 and JMS 7640 or
4240 in P?S/8. These are calls to subroutines that have in-line
arguments, that when returned is to intended to be topast the in-line
arguments. Thus, the net effect is that the ARGUMENTS ARE LIKELY
EXECUTED NOT AS DATA BUT AS INSTRUCTIONS! Again, that assumes that
what becomes the contents of 07600 is effectively a NOP. Should it
have skipped the next, it would execute a different in-line argument
as the first unintended instruction! [Note: P?S/8 and OS/8 have
slightly different arguments, so the consequences could slightly
vary!]
Personally, I never let any 129 word/block tapes get on any -12 system
I would ever play with to avoid this. And of course, get longer-still
tapes as a result, and take advantage of that with non-standard larger
capacity directories, etc.
So much for unintended consequences :-).
Going back to my original [longer] post:
I described how to handle the RK disk problem of having P?S/8 do
logical support for a subset of a physical block using a buffer as
necessary. Please note that this predates by years how CP/M-80
actually implements such as 128 byte logical blocks on such as
diskettes with 1Kbyte physical sectors to raise overall storage
capacity. Another example of imitation is the sincerest form of
flattery.
On the DECmate, OS/278 handling of the diskettes is to only use 3/4 of
each byte because there are myriad problems to support the full "8-bit
mode" of the media by using "12-bit mode". Thus, OS/278 "wastes"
about 1/4 of the already meager capacity of the RX50 diskettes.
Additionally, this means that you cannot use an OS/278 handler to copy
diskettes. [Any utilities that seem to work, do so with internal
subroutines, not handler calls.] Thus, this locks out a whole host of
utilities, such as my ENCODE/DECODE utilities as part of the KERMIT-12
package for Decmate formats other than those that conform to the OS/
278 limitation. [Note: Many other DECmate systems cannot work with
this, including WPS-8.] All that is needed is a handler that could
handle the entire diskette format, but you cannot get that to fit in
an OS/8 family system.
In P?S/8, since the system handler can be literally 1024 more words
than what fits in 07600-07777, or in rough page counts, you get 9
pages instead of one or perhaps two at most in OS/8 to do whatever it
takes, this means it should be possible to create a P?S/8 bootable
RX50 system based on 8-bit transfers capable of defining a full and
complete RX50 read/write capability.
P?S/8 non-system handlers are even more generous; since they can be
loaded into any field as well as any page, one can be defined to be
more than enough space to accomplish this as a non-system handler.
Once loaded, the handler would be loaded into field 7 on all normal
32K Decmates.
Mark Hyde [described above with regard to the DMS on PDP-12 129 word
LINCtape] is also responsible for another concept: An OS/8 handler
that is itself a one-page handler that doesn't actually do anything
itself. Instead it calls an external routine loaded into the highest
actual field. The OS/8 CORE command innards is automatically set to
one field smaller than would otherwise be available, to protect the
handler, etc.
While this would not apply to a system handler [since there would be
no way to ensure it was already present, and OS/8 has no such bootup-
time facility to load such a thing], it was successfully applied to a
non-system handler. The handler performs a checksum across the
"helper" code to ensure that it is loaded, else return an error. When
the system is up, you have to run a program to load memory properly,
so that the handler then functions without preliminary error. All
internal sanity checks will allow the helper code to be referenced,
etc.
Thus, combining all of the above ideas [note: This code is not
currently written, but it is not a pie-in-the-sky issue; just needs a
reasonable amount of time I presently don't have. Mark's code, to the
extent required, is a relatively straight-forward "stub" that can be
recreated if needed], you can implement an OS/278 handler to call the
P?S/8 code loaded into field 7 while OS/278 is set to effectively
"CORE 6" instead of "CORE 7". If the code can handle 8-bit mode RX50
as a logical device, then OS/278 can now support 8-bit diskettes. And
the ENCODE/DECODE utilities could define OS/278 .EN files to transfer
images of *any* RX50 diskette.
cjl
John Everett
wrote:
>
>We can forgive your "youthful" foolishness :-) . But perhaps only
>barely.
>
>Just to make your "legacy" be fully understood:
>
Just to clarify, the format of PDP-8 DECtape was already well
established before I chose to debug DMS using DECtape as a stand-in
for the DF-32. I had nothing to do with the choice of 128 words of
data plus a link word. I'm guessing it goes back to the PDP-5, and
predates my joining DEC in 1966.
cjl
<jevere...@sbcglobal.DEFEAT.UCE.BOTS.net> wrote:
> On Fri, 19 Jun 2009 00:53:46 -0700 (PDT), cjl <clasyst...@gmail.com>
> wrote:
>
>
>
> >We can forgive your "youthful" foolishness :-) . But perhaps only
> >barely.
>
> >Just to make your "legacy" be fully understood:
>
> Just to clarify, the format of PDP-8 DECtape was already well
> established before I chose to debug DMS using DECtape as a stand-in
> for the DF-32. I had nothing to do with the choice of 128 words of
> data plus a link word. I'm guessing it goes back to the PDP-5, and
> predates my joining DEC in 1966.
Of course the format of the tape is quite well established. But
that's the hardware:
LINCtape came first and is any multiple of 12-bit words you want
because the LINC is a 12-bit machine. Transfers are forward only,
searchs either way, and only a single final data word indicator and
inter-block-zone detection. Mark window of 4 bits gets you this by
clever selection of the bitstream of mark bits corresponding to the
various data states below. For example, when the state is "BLOCK"
then the 12-bit data latest assembled is the 12-bit block number.
Searching in reverse gets you there as well, etc.
DECtape is an outgrowth of that, and is 18-bit oriented because that
was the standard at the time. Final word gave way to pre-final word
and final word to facilitate double-buffering, and directional
transfers were allowed thus everything was doubled up on both ends of
the block. The data of a BLOCK mark as a practical matter is twelve
bits because you can never have even as many as 11 of the bits
significant. [Especially on 18-bit machines.] The mark window is 6
bits corresponding to 18 bits of data so you can get all of these
extra states with a more elaborate cousin of the original.
On the 12-bit machines, thus, you are constrained to use tape data
sizes that are a multiple of both 12 bits and 18 bits. Since the
PDP-8 uses 128 12-bit word pages, the nearest up value that provides
this is 129 12-bit words.
Due to the additional count of blocks, the inter-block "overhead" adds
up, thus you get less total data per tape in exchange for more handy
smallest data size. Thus, the standard became two magic sizes, one
for all of the 18-bit multiple machines and one expressly for the
PDP-5 and later -8.
The two sizes are extremely conservative, even for the nominal tape
lengths actually delivered by 3M. Many users soon realized that they
could patch the formatter program and get even more data, thus the
PDP-8 standard 2702 block size gave way often to the larger 3300 block
size often achievable [until nearer to the end of tape production, 3M
got "stingy" and made the tapes shorter, still barely achieving the
nominal length, but not the usual "extra" amount]. There were even a
few grumbles about the occasional tape that was actually cut too short
to even become the standard. These tapes were banished to become
"long" versions of the shorter 150 feet original LINCtapes that aren't
even trying to come close, etc. [These tapes are supposed to be 260
feet! Often they were something more like 285 feet, but at the end,
you might not even get 260 feet, etc.]
The standard formatter values [using octal notation] is
18-bit-oriented: 1000 blocks, 600 words/block
12-bit oriented: 2702 blocks, 201 words/block
Notice you get inherently more data in the first standard format.
However, most of the standard usage in the various 18/36/16 worlds are
not extendable, in part because they tend to make multiple passes on
the tape to take advantage of always rolling a lot, to minimize the
need to do a turn-around when starting another transfer. This is
mostly not an important factor on typical PDP-8 software [but actually
used on some that took multiple passes on the tape; this was
occasionally done, a topic for another post].
However, since most PDP-8 software has the directory at the beginning,
it is usually a simple matter to make the tape logically longer to
take advantage of the data. It's certainly true in OS/8 and P?S/8's
file structures[es]. [That's not a typo; P?S/8 has several
simultaneous file structures. Each has to declare starting and ending
extents either explicitly or implicitly. OS/8 has one general
directory, optimized for nothing in particular, but quite easy to
patch to take advantage of available space. A length table is kept
within a repository contained within the executable program PIP, which
you can patch transiently or permanently, your choice. You can always
fake a physically impossible length; it doesn't care, etc.]
Thus, clearly there are no "rules" cast in stone for what software
"must" do. On the PDP-5, there were fewer choices still. To my
knowledge, the only thing that survived was a version of the DECtape
Library System, which was more of a program saver/loader to save paper-
tape images than an O/S. Images were saved in an order, and deleting
an "inner" entry meant that the empty space had to be "squished" out
of existence because the structure only supported contiguous images,
with the ability to specify what subset of 0000-7577 was actually in
any one of them. The only commands were oriented to deleting, saving,
execution merely by naming the one you wanted, or listing all that are
present.
An adaptation of this early stuff was found also on the LINC-8. I
have never seen what I am about to describe, just the playback of
someone who worked for DEC who was really impressed by it [for I have
not the foggiest reason, considering just how primitive this is
compared to the original version of the R-L monitor system, the
"grandfather" of P?S/8:
Apparently, this is referred to as something like the "Josephson"
modifications. Apparently the notion is that you could save your
"files" but all they were are the paper-tape editor with your typings
in the internal buffer. Thus, you called up an instance of the editor
to edit your file within that particular copy of the editor, and then
saved the core image after an edit, etc. An assembler, perhaps PAL
III? was modified to accept input from a designated "file" and created
binary paper-tape output frames converted into some form of 12-bit
data that got written out into some "sacred" name binary file place
holder. Specifying the place holder was the way you got your binary
program into memory. Restarting the system allowed you to save your
program's image, just like the unmodified original.
While I admit this is a small step up from the original image-loader/
saver system, this is still far less than anything else, R-L and
forward, including DMS.
But in any case, none of these systems demand any specific designated
structure regarding each 129 word block, just that the blocks
themselves at the "raw" level merely ARE 129 words.
Thus, *someone* decided to use the notion of a 128 data plus a link
word to another file block in a linked list. There is nothing
inherent in the hardware, or any other software outside of the TSS8
and DMS family, etc. In fact, none of this stuff even wants to find
use for the 129th word; it is merely an annoyance to be dealt with in
the handler, constantly setting word counts to -128 words each and
every time.
Thus, no, there is no basis for anything in the software demanding or
even suggesting the specific usage of the 129th word as a link-list
element. All of the software before or after is based on the notion
of implicit relatively short contiguous areas; OS/8 gets the dubious
"honor" of having to deal with the notion of variable-length "gaps" in
the structure that tend to develop over time, necessitating what
people today tend to call "defragging" but we know it as "squishing"
out the empties so that they instead became one big empty at the end.
If you didn't have a big enough contiguous area, you are SOL in term
of writing out the file, etc. [Note: RT-11 works the same way.]
So, I suggest you have to look closer to the TSS8/DMS world to find
out where this suggestion came from, because it isn't in any other
prevailing software any one I ever heard of ever heard of. That the
hardware constrains block size itself is of course not in dispute, nor
is the wisdom of not getting trapped into using this dependency that
dead-ended itself in terms of newer devices.
BTW, what Richard Lary invented [and still used in the most
"primitive" of the P?S?8 file structures is the notion of direct-
access editing of a partitioned text file.
In essence, your source file is partitioned into sections each with a
name of your own choosing. Perhaps you want a program named SPCWR
[space war truncated down] so you make a series of files named SPCWR1,
SPCWR2, SPCWR3, SPCWR4, etc.
Each file has a fixed maximum capacity for its section, in this case
2K words. [The R-L and later P?S/8 integrated keyboard monitor and
editor is 2K long including the system handler; the rest of a 4K
machine is the edit buffer; the 2K includes a cached complete copy of
the directory.]
When you start typing, and you are inexperienced, you will likely run
out of room as you type the latest line into somewhere within the
latest 2K file you are editing. Not to worry, you just save it
somewhere, kill something like half of the text lines, and save it
back. Get the original back again, kill the other half, and then save
it as the second file. Thus, if you somehow thought that SPCWR was
going to be a source file of only 2K, you might have called the file
SPCWR. But that gave way to SPCWR1 and SPCWR2 as soon as you realized
this was a whole lot longer program than first envisioned. [Maybe you
actually typed some comments in!]. In any case, between iterations of
this process, perhaps augmented by pre-planning for the scope of the
project, eventually the source file is now embodied inh SPCWR1,
SPCWR2, SPCWR3, SPCWR4, and SPCWR5.
To make any edit, you have to get the hang of where it is, to the
nearest file at least. You can load in any one of them by name, and
list out some portion of the file to get close. If you are wrong,
adjust accordingly one or more filenames forward or backard, etc.
Eventually, you get to the place where the edit needs to take place.
Make the change, and save the file back onto the precise same place on
the tape. In that typical instance, NO DIRECTORY UPDATE occurs
because none is needed! [Butter-fingers people could make backups to
well-placed save reserve files as well; if they are pre-placed, again,
no tape motion to update the directory, just short relative motion to
move the tape to the designated spot, presumably nearby, and certainly
by clever placement, this would be so.]
Thus, only when a new file is created, is the directory updated, and
then of course the new state is now cached thus avoiding further
updates.
Notice that the unaffected parts of the partitioned file are never
updated at all! The worst [not typical!] thing that could happen is
that you have to split unexpectedly one of the files into a pair of
half-empties. Experienced users pre-half-emptied the files as they
created them, thus further making this a rare occurence. [When a file
got half full, save it one last time, empty it and then start another
file, save that when half-empty, etc. All of the names could be pre-
enterred to reserve the space even before you needed them. By
invoking the system batch facility, you could pass to the assembler
all of the files, even ones that are currently empty, since they would
be quickly passed over containing literally nothing. This even less
often had to be updated, but only if you underestimated the number of
pre-prepared file names you needed, etc.]
In the hands of a savvy user, this technique is startlingly fast to
edit even fairly long projects. In P?S/8, the practical limit on
files is 17, somewhat longer than the R-L original. Binary can be
directed to a designated one or two scratch files, whose names make
them "special" files not allowed within the defined directory space,
and are actually positional and near the beginning of the tape. Of
course you can also designate binary output files directly by name if
desired. P?S/8 extends this further in that the system handler
supports up to units 0-7, so you can designate output files on another
tape from where the source files are, or any other clever
arrangement. Since the system hander, always resident except when
loading your binary output [and maybe not even then, a user-controlled
option], there is also no overhead loading in non-system handlers just
to access all of the other tapes, etc. [Note: P?S/8 had the notion
of the CP/M-MS-DOS prompt first. The only difference is that in those
systems, devices are letters; in P?S/8 they are the digits 0-7. In
any case, one of the standard prompts could look like 0> or 1> up to
7>. Others prefered the R-L original prompt of <CR>/<LF> or a lot of
people preferred the TOPS-10 . [which carried over into OS/8.] P?S/8
commands exist to change the prompt to a variety of choices.
Thus, it became quite common to see strings such as:
PAL BSPCWR<SPCWR1, SPCWR2, SPCWR3, SPCWR4, SPCWR5, SPCWR6 /J /Q
[whatever switches were needed]. Alternatively, the equivalent could
be something like:
PAL SPCWR1 SPCWR2 SPCWR3 SPCWR4 SPCWR5 SPCWR6 (JQ) > BSPCWR
In P?S/8, spaces are ignored, the comma is optional and otherwise
ignored, command-line switches can be /1 /2 /Q whatever or bunched
together inside of a leading parenthesis and an optional closing
parenthesis and either or both can be used anywhere in the line past
the system program name [in this case PAL]. The "flow" of the command
can be output from input or input into output, just by using the "<"
or ">" of your choosing. [Makes it easy when switching from other DEC
systems which arbitrarily did it one of the two ways, in opposition to
each other, etc. P?S/8 embraces both methods.]
For those that want to say this is too long to type in, well you could
put it into a batch file, and save that file at the special file near
the beginning of the physical tape, and thus just type
BATCH $
and let it do it for you. Infrequently you could call up $ and edit
it should more files appear in the command string, etc.
Admittedly, this is not for everyone. But do as much any other way
when all you have is one DECtape, and a 4K PDP-8 and a teletype. And
this doesn't cover the topics of the "slurp" loader and other time-
saving shortcuts. [Well, here's one: If you type control-R while
typing in your command line, not yet up to the commit point of <CR>,
the tape automatically rewinds to the front. If you did it just
right, as you finished the command, the assembler, [presumably what
you were invoking] would start up and the tape was already generally
in the right place. Here's another one: Due to superior tape
handling, all circumstances where the next transfer is further down
the tape, the handler starts searching forwards, not backwards. Thus,
the assembler loaded in, the tape keeps rolling down to where your
source files are, all in one seemless movement. The feature is
dynamic, so it always takes advantage if possible. Note that in OS/8,
there are about three static places where the handler is "helped" in
this regards, but all other opportunity is actually lost.]
It is a historic fact that the Poly Spacewar program was in fact
developed on a single DECtape on this machine; the only other relevant
hardware available was a home-made "music register" for sound-effects,
and there was available an AA01A to drive an oscilloscope, and also
EAE, in this case the PDP-8 subset [slightly less than the -8/i kind
and far less than the -8/e kind]. Poly Basic was written on and for
the same hardware less the game-oriented gimmicks.
I am unaware of a PDP-8-type block-oriented storage device that P?S/8
couldn't support [although it might need 8K], and certainly I never
encountered any. By not being painted into a corner regarding "odd"
device size requirements, something could always be accommodated as
new devices appeared.
cjl
Rich Alderson
> On the 12-bit machines, thus, you are constrained to use tape data
> sizes that are a multiple of both 12 bits and 18 bits. Since the
> PDP-8 uses 128 12-bit word pages, the nearest up value that provides
> this is 129 12-bit words.
It may help to remember that each line on the tape is 3 data bits, so we're
looking at a 6/4 = 3/2 ratio. 129 12-bit words = 516 lines = 86 18-bit words.
> The standard formatter values [using octal notation] is
> 18-bit-oriented: 1000 blocks, 600 words/block
18-bit-oriented: 1100 blocks, 400 words/block (200 on 36-bit boxen)
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
cjl
wrote:
The PDP-8 formatting program shows octal 12-bit word counts, thus 600
octal 12-bit words per block. That would be 400 octal 18-bit words,
or 200 octal 36-bit words. However, the block count was a typo.
In fact, this 1100x3timesasbig is the source of the 3300 octal block
goal for "long" DECtapes by patching the formatter. Without the
longer physical tape, it could not be achieved due to inter-block-zone
et al. overhead, i.e., you get more data in less larger blocks than in
more smaller blocks. But with the extra tape, you can get there
anyway [but not on all tapes!]. [There are few and far between tapes
that could go even longer; they got reserved for making 4000 octal
block LINCtapes.]
I even added some patches to the DEC code to obey the P?S/8 passed
switch options. Giving /s [standard] makes a 2702 octal block tape
with 129 12-bit words/block, /3 gets you the 18/36/16-bit world
format, and /X gets you the length specified by the = paramater, with
the default equivalent to =3300 if left out. The code is then started
past the usual starting point where it asks for manual input. If no
options are given, it starts normally and asks you for your choices,
which are to essentially pick one of the standard two, etc.
cjl
Tim Radde
Back to the original topic. Vince and I have made quite a bit of
progress. By examining the TSS/8 image I was able to figure out the
missing
pieces in FIP and TS8, along with some stuff that was in the wrong
place. Now all the pieces compile, as they did not at first. After
doing some
compares of the new binaries to the image we'd like to get the
corrected source back up on the net for others. Vince was able to
extract all
of the system library SAV programs which will be useful later during
an actual build. For not I can run Build and load the first four
binaries with
Simh with no problem. PUTR is no cooperating and I don't think we
have the correct binary for it. We are trying to figure that out.
Once that is
done we should be able to build a new TSS/8 image and see if it runs.
Then the fun begins of trying to convert the disk read/write IOTs from
the RF08 IOTs to RK8e IOTs. I know it's been done before so it can be
done again. Basically everything must go thru a buffer since the
RK8e
can't read/write single words. Not a huge deal, and if it slows down
a bit who cares. If TSS/8 ends up running on an 8e I will be very
happy.
Tim Radde