test-drb

test-drb@ccmp.vtda.org

101090 discussions

by bqt＠softjar.se

"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote: > >Johnny Billquist wrote: > >>> > >"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote: >> > >>> >> I would not assume anything until I actually had tested the presence >>> >> or absence of a >>> >> specific "feature". >> > >> > What have any features have to do with this? >> > I'm telling you that RTEM-11 will not, and never have been capable of >> > running on a VAX. >> > If there was a RTEM product for the VAX, it would have to be a >> > separate product, with a separate code base from RTEM-11, since you >> > cannot write a RT-11 emulator of any kind in PDP-11 mode on a VAX. It >> > will have to be VAX code. And thus, it can not be the same product as >> > a RT-11 emulator program written to run under RSX. > > 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. 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. > 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. >>>>>>> >>>> >> I don''t know if Megan Gentry is still around or perhaps Allison >>>>> >>>> or >> one of the >>>>>>> >>>> >> other DEC fellows. Perhaps they might at least know something >>>>> >>>> about >> which >>>>>>> >>>> >> hardware and operating system(s) supported RTEM? >>>> >>> >>>>> >>> > I definitely remember (and probably still have some mail >>>> >>> somewhere) > from Megan mentioning that she used RTEM-11 for RT-11 >>>> >>> work, running on > RSX machines. Possibly even an 11/74. >>> >> >>> >> I don't have enough information about RSX to know if RTEM-11 was >>> >> supported. >>> >> However, ... >> > >> > I'm telling you that it is. Just google for it, and you will find the >> > documentation from DEC that is still on the net about this product. >> > It's actually really simple. Go to "www.google.com". Type in "rtem-11 >> > rsx" in the search field, and hit enter. >> > The first hit will be >> > http://www.google.se/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&url=http%3A%2F%…, >> > which is "RSX-11M Optional Software Cross Reference Table", which >> > lists what version of various software is compatible with RSX-11M V4.0 >> > and V4.1. Among these, you'll find RTEM-11 V1.0 and V1.1. More >> > "supported" than that is hard to get. > > Thank you for the reference. Although this does make my goal of having > the code > support running the program under the RTEM-11 RTS even more difficult. 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. > 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 noone will test you code under RTEM-11. >>>>>>> >>>> >> In addition, RSTS/E also supported RT-11 programs via the >>>>> >>>> SWITCH RT11 >>>>>>> >>>> >> capability. However, only the RT-11 EMTs which are used by a SJ >>>>> >>>> are >> supported >>>>>>> >>>> >> by RSTS/E. At least there is quite reasonable documentation as >>>>> >>>> well >> as the ability >>>>>>> >>>> >> to test and actually run RT-11 programs under RSTS/E up to the >>>>> >>>> latest >> versions >>>>>>> >>>> >> of RSTS/E. RT-11 EMTs for mapped RT-11 monitors (RT11XM) are >>>>> >>>> not >> supported >>>>>>> >>>> >> not are multi-terminal EMTs. Also, probably the latest RT-11 >>>>> >>>> EMTs >> for file status >>>>>>> >>>> >> information are also not supported under RSTS/E. >>>> >>> >>>>> >>> > The correct technical term is that RSTS/E have a RT-11 *run time > >>>> >>> system*. An RTS in RSTS/E provides an environment under which you >>>> >>> can > get a specific behaviour. So you had RTSes for RT-11, RSX, >>>> >>> BASIC+, > TECO, DCL and some other stuff. Some RTSes were also KBMs >>>> >>> (keyboard > monitors), meaning you could "switch" to them, and get >>>> >>> an interactive > command line interpreter with that. But the RTS >>>> >>> mostly implemented > system calls. However, there were RTSes which >>>> >>> didn't implement any > system calls, and only gave you the basic >>>> >>> calls RSTS/E itself > provided, and mostly focused on being a KBM, >>>> >>> such as DCL. >>> >> >>> >> I apologize for my lack of familiarity with the terminology. Your >>> >> description >>> >> is what I was attempting to say. >> > >> > :-) >> > >>> >> Actually, my testing seems to show that RSTS/E supports being able to >>> >> run RT-11 programs even if the RT-11 RTS is not activated. For example: >>> >> RUN MACRO >>> >> is possible if the RTS is normal RSTS/E or RT-11. This might be >>> >> based on the >>> >> file type. RSTS/E may determine that MACRO.SAV is an RT-11 program and >>> >> support the RT-11 EMT requests. Or RSTS/E may support naked RT-11 EMT >>> >> requests from any program. That is something I should test. >> > >> > No, you are confusing things, and making wild guesses. >> > What do you mean by "activated"? There is no activation. If an RTS is >> > installed, it will always be used for programs that are marked as >> > requiring that RTS. This is an "attribute" of a file. Whenever that >> > file is run, it is run under the indicated RTS. If you try to run a >> > program that requires an RTS that don't exist I would suspect that >> > you'll get an error. > > 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. 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. >> > Also, if you type "RUN MACRO", how do you know that you are even >> > running the RT-11 version? RSTS/E normally also have an RSX RTS >> > available, and an MACRO.TSK, which is MACRO-11 running under the RSX RTS. > > When MACRO.SAV is run (under the RSTS/E RTS or any other RTS or under > any other operating system including RT-11 and TSX-Plus, it is simple to > just > type <RETURN> at the "*" prompt to obtain the version number and so identify > which program is being run. 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. >>>>> >>> > All exeutable files have an RTS associated with it, and when the > >>>> >>> program is run, it is run under that RTS, which then handles all >>>> >>> EMTs > and so on when the program executes them. >>> >> >>> >> Does the file type trigger the use of that RTS? >> > >> > Unless my memory have totally rotted away, the answer is no. The RTS >> > associated with a file is an attribute of the file, just like file >> > protection. There is a switch to PIP that you can use to check, and >> > set, the RTS. >> > That said, all RTS have a default file extension as well, and I think >> > that is used to search for runnable files if you just type "RUN MACRO" >> > for example. > > That answer helps quite a bit. Thank you! 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. >>> >> I do have a question. With V7 of RSTS/E, the FIT program is able to >>> >> copy files from a drive with an RT-11 file structure (such as an RX02) >>> >> to the RSTS/E file structure. My initial testing with V10.1 of RSTS/E >>> >> shows that (at the very least the distribution which I am using) does >>> >> not >>> >> have a FIT program. Is there some other method of making a copy of >>> >> a file on an RX02 with an RT-11 file structure to a device with a RSTS/E >>> >> file structure? >> > >> > Either FIT, or some "new" program that does the same thing, I'd guess. >> > I'm no expert on RSTS/E, and my experience is old. I mostly ran RSTS/E >> > between V7.1 and V9.0, with the majority of my time in the V7-V8 >> > timeframe. > > 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. >>> >> Also, is it possible to run an RT-11 program under a DEBUG mode? It >>> >> would be much easier to check out the code if that is possible. At the >>> >> moment, I can check most of the code under RT-11. However, the >>> >> portion which runs in a different manner under RSTS/E as opposed to >>> >> RT-11 since RSTS/E does not support all RT-11 EMT requests in the >>> >> same manner as RT-11. >> > >> > What do you mean by "debug" mode??? > > I am not sure if RSX-11 has an SD(X).SYS device driver like RT-11 which > handles the BPT instructions placed in a program running under RT-11 when > the user wants to stop a program in the middle of running and check out the > code. The SD(X).SYS device driver under RT-11 supports the features that > the ODT subroutine handles without the requirement for that subroutine to be > part of the program which is being tested. Under TSX-Plus, there is a > so-called > debug option which invokes the same sort of support. Since the SD(X).SYS > is written as a device driver in RT-11 (starting with around V5.4 of > RT-11 if 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. > I remember correctly), debugging a program under RT-11 became much easier > since ODT was no longer inserted into the program being tested. > > I was hoping that RSTS/E has the same sort of feature available, but > that does > not seem to be the case. But then how did users debug their programs under > 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'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

15 years, 8 months

need Lisa parts

by chrism3667＠yahoo.com

in particular a nice crt-chassis, etc. I was perusing the vintage computer marketplace a few weeks back, and someone had some of that very stuff. I think it may even have been Erik. In any event I don't know how to contact anyone on that site anymore, because someone gummed up the works LOL. please let me know. Much obliged.

15 years, 8 months

Thinning The Herd

by fsmith＠ladylinux.com

Hi Guys, I am mostly a Lurker here and very much enjoy and will continue to enjoy reading the posts here. However I am feeling a need to thin down my collection some that I have been accumulating over the last 10 years. I am looking for people to show up here with some cash and a truck and to haul away some of my prized possession's. I don't have any blinking light DEC machines anymore or anything ultra rare like a Lisa but I do have a large assortment of PDP 11/23 and other QBus equipment. As well as a decent sized collection of regular PDP 11 Unibus and mass buss boards. I also have many different types of workstations such as Dec Professionals , Rainbows and 3100 and 4000 series gear. Also a virtual pile of peripherals. Also some smaller stuff like KayPro , Osborne etc. Also much software as well and a couple nice televideo terminals. Now I did pay good cash money for all of this and its all been stored in a climate controlled clean area. So anyone who wants a instant collection or just wants to come by and kick the tires and do some dealing please e-mail me at fsmith at ladylinux dot com. Please try and keep communications off list as this is not really applicable I feel. Thanks!! Fran (Mid Alantic USA)

15 years, 8 months

Valves/Tubes was: ez80

by tshoppa＠wmata.com

Will writes: > The US truly is (was?) the land of standardized parts. And the even better part, is there are so many standards to choose from!!! Occasionally I get to even use Whitworth threads here at work :) Tim.

15 years, 8 months

Any former Psion 5 owners out there?

by lproven＠gmail.com

This is not strictly on-topic, but I thought it might be of interest. I for one, and a lot of former Psion-owning acquaintances, have long bemoaned that there is no modern equivalent of the classic keyboard-driven PDA available today. Which is why I was rather interested by this device: http://digitalchunk.com/kddi-sharp-android-iso1-smartbook.htm -- Liam Proven ? Profile: http://www.linkedin.com/in/liamproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AOL/AIM/iChat/Yahoo/Skype: liamproven ? LiveJournal/Twitter: lproven MSN: lproven at hotmail.com ? ICQ: 73187508

15 years, 8 months

68K ISA project

by ken＠seefried.com

On 7/11/2010 1:00 PM, "Andrew Lynch"<lynchaj at yahoo.com> > > Hi! Just out of curiosity does anyone know of any home brew ISA bus 68K > boards? > Didn't Circuit Cellar do something like this in a series of articles? KJ

15 years, 8 months

Formatting media issues (was Re: Amlyn Minipac diskette changer)

by ethan.dicks＠gmail.com

On 7/19/10, Chuck Guzis <cclist at sydex.com> wrote: > On 19 Jul 2010 at 8:00, Steven Hirsch wrote: >> Reminds me of >> the DEC Rainbow (wasn't that system deliberately crippled to prevent >> it from being able to format blank media?). > > If the Amlyn disks use an embedded servo, formatting one is a > mechanical issue--you need to periodically offset from the central > track axis a bit one way or the other to write a servo burst. Not > easy to do wth a conventional read/write drive. That's one issue I recall with the transition from RK05 to RL01 as "inexpensive" cartridge media in the DEC world. The RK05 has a manually-aligned external positioner, and the RL01 (and RL02) uses embedded servo data. One advantage to the RK05 technique is that you can format packs that have been bulk-erased (since the platters only contain data, not positioning info) One advantage to the RL01 is that you don't have to be quite as precise with head alignment (you have to be close enough for the embedded servo data to be legible, then, IIRC, the positioner circuit can lock on the rest of the way). There was another method that was acceptable for multi-surface packs - a servo surface. It's not worth dedicating an entire surface to positioner data if you only have two surfaces - you get a poor space-to-cost ratio. If you have 4-8 surfaces, it's more practical to give up a surface (vs a loss of some space for embedded servo info). An advantage of a servo-surface pack is that you can easily format the data surfaces as long as you leave the servo surface untouched. I've heard of a field service device for writing servo data on a wiped RL pack, but I've never seen one in person. -ethan

15 years, 8 months

Amlyn Minipac diskette changer

by snhirsch＠gmail.com

Has anyone else on the list seen one of these? I picked up a Vista V1200 disk system for Apple 2 that uses this type of drive. The mechanism takes a plastic cartridge with five 5.25" floppy disks. The diskettes appear to be conventional SS format with a couple of extra punchouts to mate with the loader mechanism. Electrical interface is compatible with 8" floppy drives (interface card was also sold for that purpose). I'm not able to turn up any information about the drive and am wondering how the diskette select/load scheme is intended to work. There are at least a couple of possibilities: - Treat the physical diskettes as portions of a single logical floppy and select diskette by track range (first diskette 0-39, second 40-79, etc.) - Treat each physical diskette as a logical drive and use binary select lines on interface to choose. Anyone have documentation on the drive mechanism or the Vista product? Steve --

15 years, 8 months

Northgate OmniKey Ultra

by LWhetton＠usbr.gov

Is the keyboard still available for purchase? Please advise. Thank you. Linda Whetton Environmental Resources Division 125 S. State Street, Room 6107 Salt Lake City UT 84138-1147 Tel: 801-524-3880 Fax: 801-524-3858 EM: lwhetton at usbr.gov

15 years, 8 months

RTEM-11

by bqt＠softjar.se

"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote: > >Johnny Billquist wrote: > >>> >> I suspect that the most likely possibility is that RTEM and RTEM-11 >>> >> are used. >> > >> > Huh? If you are suggesting that they would be the same, I can assure >> > you they could not. > > I would not assume anything until I actually had tested the presence or > absence of a > specific "feature". What have any features have to do with this? I'm telling you that RTEM-11 will not, and never have been capable of running on a VAX. If there was a RTEM product for the VAX, it would have to be a separate product, with a separate code base from RTEM-11, since you cannot write a RT-11 emulator of any kind in PDP-11 mode on a VAX. It will have to be VAX code. And thus, it can not be the same product as a RT-11 emulator program written to run under RSX. >> > A very common misconception these days seems to be that VAXen with >> > PDP-1 compatibility could run PDP-11 programs. That is only true in a >> > very limited sense. Only the basic PDP-11 instruction set is supported >> > by the VAX, and only the user mode stuff. EMTs, as well as any other >> > kind of traps, interrupts, and so on, was *not* supported. >> > When you execute an EMT in PDP-11 mode on a VAX, it will trap back to >> > VAX mode. No possibility to have a PDP-11 trap handler. > > The absence of a PDP-11 trap handler under VMS compatibility mode on a VAX > is definitely one possible situation. However, I suggest that it may > also be possible > for RTEM under VMS on a VAX to handle some of the SJ RT-11 EMT requests. Definitely. But the code that catches the trap, and does something will have to be VAX code, and not PDP-11 code. You cannot write a trap handler in PDP-11 code on a VAX, no matter how much of the PDP-11 compatibility that exist in the VAX hardware. The PDP-11 compatibility mode simple does not extend to that stuff. Period. >>> >> In addition, I also suspect that both Johnny and Ethan are correct in >>> >> that RTEM >>> >> was supported under both RSX and VMS on an older VAX which allowed >>> >> compatibility mode. >> > >> > It would have to be totally separate products in that case. > > AGREED!! Thank you. Now we can proceed. >>> >> I don''t know if Megan Gentry is still around or perhaps Allison or >>> >> one of the >>> >> other DEC fellows. Perhaps they might at least know something about >>> >> which >>> >> hardware and operating system(s) supported RTEM? >> > >> > I definitely remember (and probably still have some mail somewhere) >> > from Megan mentioning that she used RTEM-11 for RT-11 work, running on >> > RSX machines. Possibly even an 11/74. > > I don't have enough information about RSX to know if RTEM-11 was supported. > However, ... I'm telling you that it is. Just google for it, and you will find the documentation from DEC that is still on the net about this product. It's actually really simple. Go to "www.google.com". Type in "rtem-11 rsx" in the search field, and hit enter. The first hit will be http://www.google.se/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&url=http%3A%2F%…, which is "RSX-11M Optional Software Cross Reference Table", which lists what version of various software is compatible with RSX-11M V4.0 and V4.1. Among these, you'll find RTEM-11 V1.0 and V1.1. More "supported" than that is hard to get. >>> >> In addition, RSTS/E also supported RT-11 programs via the SWITCH RT11 >>> >> capability. However, only the RT-11 EMTs which are used by a SJ are >>> >> supported >>> >> by RSTS/E. At least there is quite reasonable documentation as well >>> >> as the ability >>> >> to test and actually run RT-11 programs under RSTS/E up to the latest >>> >> versions >>> >> of RSTS/E. RT-11 EMTs for mapped RT-11 monitors (RT11XM) are not >>> >> supported >>> >> not are multi-terminal EMTs. Also, probably the latest RT-11 EMTs >>> >> for file status >>> >> information are also not supported under RSTS/E. >> > >> > The correct technical term is that RSTS/E have a RT-11 *run time >> > system*. An RTS in RSTS/E provides an environment under which you can >> > get a specific behaviour. So you had RTSes for RT-11, RSX, BASIC+, >> > TECO, DCL and some other stuff. Some RTSes were also KBMs (keyboard >> > monitors), meaning you could "switch" to them, and get an interactive >> > command line interpreter with that. But the RTS mostly implemented >> > system calls. However, there were RTSes which didn't implement any >> > system calls, and only gave you the basic calls RSTS/E itself >> > provided, and mostly focused on being a KBM, such as DCL. > > I apologize for my lack of familiarity with the terminology. Your > description > is what I was attempting to say. :-) > Actually, my testing seems to show that RSTS/E supports being able to > run RT-11 programs even if the RT-11 RTS is not activated. For example: > RUN MACRO > is possible if the RTS is normal RSTS/E or RT-11. This might be based > on the > file type. RSTS/E may determine that MACRO.SAV is an RT-11 program and > support the RT-11 EMT requests. Or RSTS/E may support naked RT-11 EMT > requests from any program. That is something I should test. No, you are confusing things, and making wild guesses. What do you mean by "activated"? There is no activation. If an RTS is installed, it will always be used for programs that are marked as requiring that RTS. This is an "attribute" of a file. Whenever that file is run, it is run under the indicated RTS. If you try to run a program that requires an RTS that don't exist I would suspect that you'll get an error. Also, if you type "RUN MACRO", how do you know that you are even running the RT-11 version? RSTS/E normally also have an RSX RTS available, and an MACRO.TSK, which is MACRO-11 running under the RSX RTS. There is no RSTS/E RTS, by the way. >> > All exeutable files have an RTS associated with it, and when the >> > program is run, it is run under that RTS, which then handles all EMTs >> > and so on when the program executes them. > > Does the file type trigger the use of that RTS? Unless my memory have totally rotted away, the answer is no. The RTS associated with a file is an attribute of the file, just like file protection. There is a switch to PIP that you can use to check, and set, the RTS. That said, all RTS have a default file extension as well, and I think that is used to search for runnable files if you just type "RUN MACRO" for example. > I do have a question. With V7 of RSTS/E, the FIT program is able to > copy files from a drive with an RT-11 file structure (such as an RX02) > to the RSTS/E file structure. My initial testing with V10.1 of RSTS/E > shows that (at the very least the distribution which I am using) does not > have a FIT program. Is there some other method of making a copy of > a file on an RX02 with an RT-11 file structure to a device with a RSTS/E > file structure? Either FIT, or some "new" program that does the same thing, I'd guess. I'm no expert on RSTS/E, and my experience is old. I mostly ran RSTS/E between V7.1 and V9.0, with the majority of my time in the V7-V8 timeframe. > Also, is it possible to run an RT-11 program under a DEBUG mode? It > would be much easier to check out the code if that is possible. At the > moment, I can check most of the code under RT-11. However, the > portion which runs in a different manner under RSTS/E as opposed to > RT-11 since RSTS/E does not support all RT-11 EMT requests in the > same manner as RT-11. What do you mean by "debug" mode??? 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

15 years, 8 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb