RTEM-11

"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote: 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. As RTS is a RSTS/E specific thing, any code written to implement an RTS is *always* written in PDP-11 machine code. You could possibly write it in some supported high level language under RSTS/E, but I don't think any actually is supported for doing this. The one possibility I can think of would be PDP-11 C for RSTS/E, which might allow you to do something like this. Otherwise, an RTS must be written in MACRO-11. The RTS does not do anything until a trap happens. Be that from an EMT, an illegal memory reference, or whatever. At that point, the RTS is called at a specific address, and the RTS can then do whatever it feels like, and either abort the running program, or else let it continue. The PDP-11 compatibility mode on some VAXen allows the PDP-11 instructions to be executed without any other layer involved. They are executed by the microcode of the CPU. But not all instructions are implemented. If an unimplemented instruction is executed, the CPU traps back to VAX mode, and to a trap handler. Something like simh is like the microcode of the CPU. However, the microcode in this case looks just like x86 assembler. This is nothing at all like what an RTS under RSTS/E is doing. The microcode executes all instructions that have been implemented, and if an unimplemented instruction occurs, some kind of trap happens. On a VAX, this will be a trap back to VAX mode, and a trap handler. Under simh, it will be handled just like on any other PDP-11. Ie. you'll get a trap in PDP-11 mode, to the trap address for illegal instructions. (Check out the processor handbook for a PDP-11 if you want more details on this.) Now, it should be pretty obvious that this is not the same thing as what un RTS do. An RTS depends on the PDP-11 specific behaviour when a trap occurs. A VAX does not follow that behaviour. A PDP-11 emulator like simh do. So, you can run RSTS/E on simh, but you cannot run RSTS/E on a VAX. Furthermore, you can have an RTS under RSTS/E which emulates the RT-11 system calls. You cannot even run that RTS on VMS. 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. Not an RTS, but anyway, you are most probably very correct in the assumption that noone will test you code under RTEM-11. 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. When a file is created, it is created by a program. That program is running under an RTS. And so, the new file will by default also be associated with that RTS. So when you run LINK.SAV to create a new runnable file, LINK.SAV will create your file, and since LINK.SAV runs under the RT11 RTS, your new program created by LINK.SAV will also be marked as associated with the RT11 RTS. Now, this is obviously correct, so you do not need to think about it. If you instead run TKB.TSK, that program runs under the RSX RTS. And TKB.TSK will create a new runnable task for you. A pretty good and obvious guess is that that program is a RSX task, and as such, you want it to run under the RSX RTS. And since TKB is an RSX task, it runs under the RSX RTS, and files created by TKB will thus also be associated with the RSX RTS. Once again, right without you having to think about it. Would you ever want to force a program to run under another RTS (probably a bad idea, but anyway...) you can change this with the PIP program. Now, I hope I've made it clear enough this time. RSTS/E is *not* an RTS. RSTS/E is the operating system. RT-11 the operating system is never an RTS. There is an RT11 RTS under RSTS/E, but that is only relevant when you are running RSTS/E as the operating system. If you type just "RUN MACRO", how do you even know it's invoking MACRO.SAV? There is also a MACRO.TSK normally under RSTS/E, since you might also want to compile things in RSX flavour. Both are MACRO-11, based on the same code base, and actually even generating the same object files. However, the system calls they make are specific to the OS they are built for, so they are not the same binaries. MACRO.SAV *always* runs under the RT11 RTS. If you were to try and run MACRO.SAV under any other RTS, you would crash and burn hard and fast. Note that what KBM you have switched to have nothing to do with this. You can switch to basic, DCL, or RSX for all that you want. If you then run MACRO.SAV, it will still run under the RT11 RTS. It *must*, or it won't work. So, if you have access to a RSTS/E system, now type "HELP PIP", and find out how you see and set the RTS for a program. 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. That is called a debugger, and yes, there are several debuggers for both RSTS/E and RSX. Normally you have to link them into the runnable image in order to be able to access things in the running program though. If the debugger is not linked in to the program, the program will normally abort if it executes a BPT instruction. Since you do mention this concept in your text, you should be familiar with it. ODT is one of the debuggers availabe, and I believe it's the only one shipped with RSTS/E by default. 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'm not sure how you use that device driver under RT11, nor how useful it actually is... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol