MIT provides MULTICS source and documentation (DPS-8 simulation)
jwstephens at msm.umr.edu
Tue Nov 13 00:58:42 CST 2007
Roy J. Tellason wrote:
> On Monday 12 November 2007 17:24, Al Kossow wrote:
>> > The I/O on a full blown system is where a modern system might have
>> > emulation problems
>> This is exactly where simulation has been hung up for years. The mass
>> storage and terminal system is complex, with microcoded controllers for
>> tape and disk and dedicated front end processors for terminal/network I/O.
> This sort of thing is exactly the area where I'm fuzziest when it comes to any
> sort of a real understanding of big iron. Aside from seeing references to
> such stuff from time to time, I really don't have a clue as to why you'd
> _want_ something like a separate dedicated processor to handle I/O, for one
The Multics system was designed to be scaled to very large numbers of
processors and thousands of users.
It was recognized that all of the tasks to handle the disk i/o which was
very important to performance
need not all go thru the processors in all cases.
Multics was a virtual memory system. The nature of this sort of system
was researched by students
at MIT and ideas to enhance performance showed that a lot of the
activities could be carried out by
subsystems which were dedicated to just the specific task of moving data
to and from the memory.
Early systems also had three level storage systems which incorporated a
swapping drum to allow
the same performance of a large amount of core memory w/o having the
actual core available by
swapping user spaces to the drum. Disk was sufficiently fast to allow
the virtual memory approach
to start to be used in a timesharing system, but not fast enough to
match the drum storage performance.
When the system I worked on was configured the threshold was crossed and
the USL Multics
system was configured with no drum and a large (1 or 2mb I think) or
memory rather than a drum.
> Or mass storage. Or whatever.
The communications front end handled a lot of the mundane tasks of
interfacing with terminals
and transmitted in streams of character data to and from the terminal
rather than dealing with
> And I really don't have that much
> of a handle on how the architecture of those sorts of machines differs from
> the micros I'm familiar with. Even that bit of time I got to spend with the
> Heath H11 was very alien to the rest of what I'm familiar with.
> I realize that I'll never get as familiar with some of this stuff as some of
> you guys that have actually worked with it, but can any of you point me
> toward some resources that might let me understand some of it better than I
> do now?
C. Gordon Bell's books are a good place to start. One oriented towards
DEC systems is at
This book which is online covers all computers for the time it was
published and is very useful
Also on that site is a listing of computer companies he compiled which
is very useful if you can't
quite think of the name of the computer company you have a part for.
(off the subject but useful)
I find his web site is useful in general to pour over for reading. The
links above are from books he has had put online
since going to work for Microsoft.
More information about the cctech