26 Aug
2012
26 Aug
'12
9:52 p.m.
On 08/26/2012 12:45 PM, Rick Murphy wrote:
;) Still fun to play with.
The console IO for PDP-8 is far more trivial and only a few words. CP/M
added command line editing.
Relative to OS/8 CP/M is small, If the bios is of the MDS800 sized it
all fits in less than 7K. Thats
the BIOS(typically under 1.5K in simple systems, can be overlaid),
BDOS(3.5K and overlayable)
and CCP (2k and overlayable), If you treat the bios as the resident
portion 2K for 8080/z80
is not much.
Allison
At 05:12 PM 8/25/2012, allison wrote:
The hack wasn't fitting OS/8 into 4k it was making TSS-8 give up 8K.
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.
P?S/8 could do more.
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.
Old millrat here too.
I'm sure that you're confusing TSS-8 with ETOS
or MULTOS/8, probably
the latter.
Never used ETOS or MULTOS/8
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