In a past life ;-) I used and worked with RSTS/E running on an 11/70 -
including creating a lot of software, adding libraries, etc. - while running
the Quant. Analysis Group at Fidelity.
I now have RSTS/E running on my 11/83 - including the same account (and my
personal software) that I worked with over twenty five years ago.
To port RSTS/E to Intel would be a major chore. RSTS/E supports the RT, RSX
BASIC-PLUS, BASIC-PLUS2, TECO, etc. run-time systems. It "automagically" can
run programs from any of those "OS"es!
So porting RSTS/E would mean porting all of those runtimes and their
associated libraries (RT, RSX, etc.) as well. Whew!!!
I thinks its a LOT easier (and more fun) to simply run it on real DEC hardware
- or if you can't create that environment - run it on Intel via the SIMH or
ERSATZ emulators.
Cheers,
Lyle
On Tuesday 14 September 2004 07:17, Paul Koning wrote:
>>>> "Ron" == Ron Hudson <ron.hudson(a)sbcglobal.net> writes:
Ron> Would there be any interest in re-writing somthing like RSTS/E,
Ron> ITS, TWENEX or one of the other legacy OS to work on x86
Ron> machines? The idea would be to do something like Linux has done
Ron> for unix but for one of the other OSs, I think all the ones I
Ron> mentioned ran on pdp machines, whatever we choose to write could
Ron> have once run on anything.
What would it mean to "run" such an OS on an x86? Consider RSTS,
which is the only one of those three I know well. The OS itself is
100% assembly language. The system services are defined in terms of
request blocks in low user memory along with system call instructions
(EMT opcode of the PDP-11). Applications were generally written in
Basic-Plus (or -2), or in PDP11 assembler; rarely in some other
language such as TECO, or FORTH, or others.
I could imagine creating a Basic-Plus environment that emulates that
aspect of RSTS. I could also imagine a BP2 compiler that generates
X86 code. The surrounding machinery -- "run time systems", the system
service semantics, etc. -- that would be tricky. Assuming you get
that far, you have a user mode analog of the original, so old
applications (if written in Basic-Plus or BP2) would run. The same
would go for TECO. Assembly language applications have no chance
short of running an emulator at least for user mode. The same goes
for FORTH, since it tends to hook right into the assembly style system
service API, though obviously you could replace just that small part
and keep the rest.
paul
--
Lyle Bickley
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"