On Jan 1, 2014, at 12:16 PM, John Wilson <wilson at dbit.com> wrote:
From: "Jerome H. Fine" <jhfinedp3k at compsys.to>
In respect of RSTS/E, is this possible as well or does RSTS/E
have the same requirement as TSX-Plus?
RSTS doesn't have loadable drivers, so it all has to be genned into the
system (and user-written drivers aren't officially supported). On the plus
side, RSTS autosizes the system on every boot (including floating CSRs, and
all vectors except card readers are autodetected so they don't need to follow
the rules at all -- user-written drivers would have to be hooked up to this
too), and passes CSR/vector/model information to the drivers that it enables.
So while RSTS requires the drivers to be linked to the system, it's not a
totally rigid mass that works only on the exact config it was built for.
You can run a monitor on totally different hardware and as long as it has
drivers for enough of the existing peripherals to work, you're all set.
Also, you can have multiple monitors (built different ways) on the same
pack and tell the pre-boot thingy (INIT.SYS) which one to boot.
A good example is the monitor called sysgen which is the one on the system
installation tape. It s a bit like the Unix Generic kernel. It s built to
support one or two units of every supported mass storage and distribution device, plus a
terminal line or two. That way, a single kernel works for every system on which a
customer might want to install. You then run that monitor to build your own, which would
normally have a more selective set of mass storage devices, the non-disk/tape I/O devices
on your system, and support for more jobs. But in all cases, you can build a monitor for
more hardware than you have, and whatever is missing is simply disabled at startup.
As for loadable drivers, true until late in the RSTS evolution. Somewhere in the V9 era,
I believe, the terminal driver system was redone so it has port drivers for each
terminal interface type, which are loaded at startup as appropriate for the hardware you
have. That s not a general mechanism, though.
In fact, RSTS has 3 or 4 quite distinct driver types: disk drivers, terminal drivers,
network device drivers, and other device drivers. Network and other are somewhat
similar, but terminal port drivers and disk drivers have no relationship at all to
regular device drivers.
User written drivers no such thing. In theory you might be able to, but only with a
source kit which few people did. And there was no documentation for this. It may be
that one or two people wrote an other driver; I can t imagine user written disk
drivers.
paul