21 Jul
2010
21 Jul
'10
12:47 a.m.
Johnny Billquist wrote:
I agree that
it is obvious that the RTS code will be written in the
native
instruction set of the system under which the RTS is running. That
means
that the RTS system under RSTS/E executes PDP-11 instructions and
uses RSTS/E EMT requests. As you state, under VMS and a VAX,
VAX instructions are used. And if I may push the envelope a bit, under
SIMH, x86 instructions are used if we agree to call SIMH or E11 a RTS
of a different kind, although the more descriptive name is emulator.
No. Now you are mixing and confusing things again.
First of all, let's make clear that RTS is a RSTS/E specific concept.
Don't use it outside discussions of RSTS/E. My reference
to a specific "feature" is with respect to the actual
details of
the RTS in question. For RSTS/E, the RTS to handle RT-11 EMT requests
does not support even all of the RT-11 EMT requests which the RT11SJ
monitor in RT-11 supports. For example, the .CStatus request is ignored
and the .SaveStatus request return the "dev:filnam.typ" and [PPN] for
the
file in question rather than the five Channel Status words used in an
RT-11
environment. So there are significant differences between the RT-11 RTS
under RSTS/E and an actual RT11SJ monitor running under a PDP-11
instruction set (specified so as to include both a DEC CPU and an
emulator
such as SIMH).
Yes. And RTEM-11 will also behave slightly differently that vanilla
RT-11 for some of those calls. And assuming there is a product called
RTEM, which runs under VMS, it too will behave differently than RT-11.
However, RTEM-11 and this RTEM will not necessarily behave the same
way, since RTEM-11 and RTEM are different products, and different
implementations, written by different people (assumingly) at different
times. RTEM-11 is not an RTS. RTEM-11 is a product that ran
(runs) under RSX.
If I were to make a qualified guess, I'd suspect that RTEM-11 is a
program that you start just like any other program under RSX. That
program then looks like an RT-11 environment, so you can run RT-11
programs inside that.
RTEM-11 will catch EMTs and other traps, and do something appropriate
to those traps. It's not difficult to catch traps in an RSX program.
Exactly what it does, and how, is another issue. And that is something
you are asking about, and which I cannot answer, and it seems noone
else can either, since noone around here have RTEM-11, or have used
it. As I said, I think Megan mentioned that she had used it, but she's
the only one I know of who have admitted to any knowledge about this
product.
I suspect that Megan is no longer available for help.
On the
other hand, I doubt that anyone will be likely to even test the
RTEM-11 handling
portion of the code, so I am probably going to just assume that what
works for the
RT-11 RTS system under RSTS/E will also suffice for the RTEM-11 RTS
under
RSX-11.
Not an RTS, but anyway, you are most probably very correct in the
assumption that no one will test you code under RTEM-11. That is what I
had assumed, however, I am curious how RSTS/E decides
which RTS to use - or none at all as the case might be.
Are you not reading what I am writing?
This is an attribute of the file. You *tell* which RTS a program
should run under. Normally you do not need to do this explicitly,
since every file always have an RTS associated with it, and it's
normally already correct, so no need to change it. Well, I am
having difficulty finding the "new" program under V10.1 of
RSTS/E.
I finally managed to figure out how to MOUNT the RL02 drives I am
"using"
(don't forget that all the code is being run under SIMH or E11) under
V7 of
RSTS/E when I am running V10.1 of RSTS/E. Since FIT had already copied
to file to the RL02 drives, I could then used PIP to copy the program
in I am
testing to the correct [PPN] on the DU0: drive which is being "used"
to run
V10.1 of RSTS/E. A bit inconvenient, but fortunately faster than on
a DEC
system.
That sentence makes no sense. Either you are running RSTS/E V7, or
RSTS/E V10, you cannot run RSTS/E V10 when you are running RSTS/E V7,
or vice versa. You'll have to reboot the machine in order to run
another version of RSTS/E. With ODT linked in to the program, just as you
mentioned that people
normally did with RT11 in the past as well.
The same type of development cycle is still what people use to this
day. You build a special debug version, which you run through the
debugger, and when you are happy, you build a new, leaner version,
without debug support.
I agree that this was also done in the past with RT-11.
I'm not sure how you use that device driver under
RT11, nor how useful
it actually is...
However, by V05.04 of RT-11, DEC developed the SD(X).SYS device
driver which allowed a program to have a BPT instruction without the
requirement to include ODT as part of the code. If the user LOADed
SDX.SYS prior to executing the program with the BPT, but without
ODT included, the code in SDX.SYS initialized the required VECTOR
to trap the BPT instruction when SDX.SYS was LOADed. The code
in SDX.SYS then performed all of the functions that ODT supported
(and a few others as well) without adding any extra code to the program
being tested. It is even possible to place a BPT in the monitor code
and test those instructions as well.
Based on some of the comments in the SDX.SYS source file, it looks
like it is also available under both RSTS/E and RSX-11. However,
since I have almost no knowledge of RSTS/E and even less of RSX-11,
I can't even begin to speculate why those comments are in the source
file.
Jerome Fine