At 05:12 PM 8/25/2012, allison wrote:
Yes, I know, I even have a PDP-8 with 24KW of core.
However TSS-8 and
OS/8 had many hacks
that allowed things that were, uhm, unsupported. ;]
I'm not so sure about that. Let's look at the OS/8 requirement of 8K
and see what we could 'hack' to make it fit in 4K.
That's not possible because the User Service Routine (USR) entry point
is at field 1, location 7700. You can't just move that, as every
program using OS/8 would have to be rewritten to know where it's
located. (Not to mention relocating the Command Decoder tables, date
word, etc.)
So you can't run OS/8 in less than 8KW. (P?S/8 perhaps could.). How
about hacking TSS-8 so that it handles 8KW programs so OS/8 can run? I
suppose it's possible, but it would require a massive restructuring of
the TSS-8 RMON to permit linking two memory fields together so they're
swapped in as a unit, plus adding code to support an OS/8 filesystem.
There's just no room in TSS-8 to permit that much code.
This isn't just speculation - my first job at DEC was in the group that
supported TSS/8. I've seen the effort necessary to do much simpler
things given the memory available - for example, replacing the RF08
code with code to support an RK8E/RK05 as the system disk took major
bit bumming to fit. Similarly the code to support the KL8-A four-line
serial multiplexer that I wrote was hard to jam in. There's just no
room. Adding the equivalent of the OS/8 USR (which handles the file
systems and takes up memory from 10000 through 11777 in OS/8) would be
quite an accomplishment.
I'm sure that you're confusing TSS-8 with ETOS or MULTOS/8, probably
the latter.
I keep a few DM-IIIs handy to run the bastard stepchild
OS/278 as well.
Yeah, and that "bastard stepchild" problem is part of why CP/M has a
slight edge over OS/8:
The only advances that CP/M brought was the concept of
OS independent
BIOS for hardware
abstraction,
If OS/8 had use something like the BIOS for console interaction,
something like OS/278 with everything patched to support the DM-III's
broken console device wouldn't have been necessary. Fix it in the
"BIOS", not in every user utility program.
a scatter/gather file system that didn't need to be
compacted to allow
for files
larger than the largest contiguous unoccupied block and a set of APIs
while not large were
adequate. Oh, and it was cheap and cheap enough that if your media
was supported or
allowed for SSSD 8" then the OS was port-able, and applications could
be portable.
I'm not arguing that CP/M was a major leap from what OS/8 gave you.
What OS/8 does with a really tiny memory footprint (just two pages of
permanently resident memory used) was damn impressive.
-Rick