gossa@chefs.dec.com (Andrew Goss) (02/02/90)
Hi I need some help with installing MICRO RTX. (I can't evaluate it's usefulness to me if I can't even get it to work !!) . I managed to assemble a .BIN library from the RTXBIND.S source by slightly altering it to fit my C compilers needs. ( Assembled using HISOFT's DEVPAC 2 for LATTICE C v3.04). The .PRG is in the AUTO folder on an otherwise blank floppy, (I Don't have a HARD DISK so there no problems there). On booting from the floppy the Copyright Notice is displayed and the system exits to DESKTOP, so it looks like the system has installed. If I compile a simple program i.e. turning the code fragment for RTX_INSTALL into a program which prints out "Installed" or "Not Installed" then it compiles, links (with the MICRO RTX library) and executes without crashing but does not print out either of the above messages. On Investigation using MON ST I discovered that the program was falling over at the TRAP #5 in RTX_INSTAll with an 'Illegal Trap' message. (Is this due to MON ST stealing/reseting the TRAP #5 vector ??). TRAP #5-#15 all point to the same address is this correct ??? Is there something going on in the STARTUP of Lattice C which causes problems with MICRO RTX ?? I'd love to find out as the system looks like the answer to my dreams. - Andrew (Goss) - P.S My system is a 520STFM with 1/2meg intenal,1meg external drives and TOS v1.3 in ROM and is as bought.
hoenig@genesis.informatik.uni-kl.de (Helmut Hoenig) (02/02/90)
gossa@chefs.dec.com (Andrew Goss) writes: > Hi I need some help with installing MICRO RTX. (I can't evaluate it's >usefulness to me if I can't even get it to work !!) . > On Investigation using MON ST I discovered that the program was falling >over at the TRAP #5 in RTX_INSTAll with an 'Illegal Trap' message. (Is this due >to MON ST stealing/reseting the TRAP #5 vector ??). TRAP #5-#15 all point to >the same address is this correct ??? I have the same problems in my Turbo C-Environment. At least I can test the programs after leaving the environment, as Turbo C restores the vectors. I temporary solved the problem by writing a tiny program which copies the trap-vectors to the area of user-vectors, befor starting the C-environment. I changed the RTX_INSTALL-function to set the trap-vectors back to these vectors befor executing the trap. But I still hope for a better solution. Good luck. Helmut Hoenig
rxg3321@ultb.isc.rit.edu (R.X. Getter) (02/03/90)
I'm using the Sozobon C compiler, which is supposed to be Alcyon compatible, and it compiles RTXBIND.S to RTXBIND.O fine, and then I put it in my libraries directory and #include <RTXBIND.H>, but I can't get my programs to link with it. Can anyone tell me how to fix this problem? I also have gcc, but I don't know enough assembly to convert the file to one gas will accept. I'll be happy if I can get it to work with either compiler. Also, people have been talking about bugs in Fforce, Is there another way to use the pipes supplied in micrortx? or a patch for Fforce? or does micrortx patch Fforce? micrortx seems like a fantastic package, and I will register for it if I can use it effectively. thanks in advance. Robert Getter ps. this is my first post, so no signature this time, maybe next time.
david@bdt.UUCP (David Beckemeyer) (02/07/90)
In article <8016@shlump.nac.dec.com> gossa@chefs.dec.com (Andrew Goss) writes: > Is there something going on in the STARTUP of Lattice C which causes >problems with MICRO RTX ?? I'd love to find out as the system looks like the >answer to my dreams. The only thing I can think of about Lattice is that I think it uses 32 bit ints and the RTX stack frames are expecting 16-bit ints and 32-bit longs. You will have to hack the RTXBIND.S glue routines to set up the RTX stacks with the correct 16/32 bit values in the right places before you make the trap #5 call. I also remember that the Lattice startup does do some strange things and Lattice is NOT a supported language for commercial RTX use (that means even if you pay, we won't help you if you're using Lattice C -- you're on your own). > - Andrew (Goss) - > -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." P.O. Box 21575, Oakland, CA 94620 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david |
michaelv@watzman.as.sub.org (Michael Vishchers) (02/08/90)
In article <2083@ultb.isc.rit.edu> rxg3321@ultb.isc.rit.edu (R.X. Getter ) writes: >I'm using the Sozobon C compiler, which is supposed to be Alcyon >compatible, and it compiles RTXBIND.S to RTXBIND.O fine, and then >I put it in my libraries directory and #include <RTXBIND.H>, but >I can't get my programs to link with it. Can anyone tell me how >to fix this problem? Are you passing the rtxbind.o to the linker explicitly, or have you put it in your dlibs.a ? just putting it in the lib directory won't work. >for Fforce? or does micrortx patch Fforce? micrortx seems like a >fantastic package, and I will register for it if I can use it >effectively. I really think it's worth the price. If you are using dlibs, you will have to change initargs.c in the last part, where it tries to get the program name from the parent memory (I guess). the line containing something like p= *(p + 0x36) (I think) must be checked if p != NULL, and argv[0] set to something reasonable, else the program will crash. That means you have to recompile all programs that were compiled with dLibs (of course, even the compiler, linker etc.) if you want to use them under RTX. I've build a small root program, a "backgrounder" (i.e., a program that can be accessed from other programs and starts background jobs), and a cron utility last weekend. I am starting gulam as the main shell from the root program and am very happy with RTX doing all the background work (hopefully also running uucp etc.) If there is enough interest, I might post the sources after some cosmetic cleanups, so others may avoid doing the same mistakes that I made 8-) . Michael -- _____________________________________________________________________________ Michael Vishchers (michaelv@watzman.UUCP) "Wer fuer alles offen ist, kann nicht ganz dicht sein." (unbekannt) _____________________________________________________________________________