reid@sask.UUCP (05/15/87)
Unfortunately, the serial line driver in Venix 1.0 has a bug in it which
makes the Pro crash stone cold dead when I try to receive at > 300 baud. I
haven't had any luck in getting a fix from either VenturCom or the Canadian
dealer (Software Kinetics in Ontario).
If anyone knows of a fix (short of buying Venix 2.0), I'd sure love to hear
from you. For that matter, if you know of a net address for Software
Kinetics (I already have one for VenturCom) even that would be much
appreciated.
300 baud is just plain painful... and to think I wrote my first programs on
punched paper tape at 110. Of course, the TTY (a real one) made so much
noise that it _seemed_ fast...
--
- !Baboo - (reid@sask.uucp or {alberta, ihnp4, utcsri}!sask!reid)
When I was a child I was an imaginary playmate.reid@sask.UUCP (I am NOT your Sweet Baboo) (05/22/87)
In article <725@sask.UUCP> reid@sask.UUCP (that's me) writes: > >Unfortunately, the serial line driver in Venix 1.0 has a bug in it which >makes the Pro crash stone cold dead when I try to receive at > 300 baud... Well, I've checked around a little more, and now I'm trying to get some of this egg off my face. The Pro only crashes at >300 Baud when I'm running Kermit (even just as a terminal emulator). Cu, which I'm using now, runs just fine at 1200 baud. As far as I can guess, it must be some interaction between Venix's code-mapping (a tricky sort of pseudo-overlay system) and interrupts, causing the CPU to become lost somewhere on the outskirts of /dev/null. -- - !Baboo - (reid@sask.uucp or {alberta, ihnp4, utcsri}!sask!reid) When I was a child I was an imaginary playmate.
smith@uoregon.UUCP (Dale Smith) (05/29/87)
I am submitting this for a friend of mine who doesn't have news access. Please reply directly to him ( ..tektronix!uoregon!oregon2!uoneuro!brumbley or ...hp-pcd!uoregon!oregon2!uoneuro!brumbley). From: <BRUMBLEY@uoneuro> Subject: message for UNIX UUCP NEWS facility I have a memory management problem using Fortran 77 under RSX-11M on an LSI-11/73. I am using a memory-resident RMS library (taking up two APR's). Two of my overlays also use a virtual array (declared in the root segment and taking up another APR) and one of those overlays also uses a device common for data acquisition (using up another APR; 4KW of address space to access a dozen device registers!). That leaves four APR's (16KW) for the main task window. The Fortran support routines take about 10KW, leaving me 6KW for my code in a 256KW machine! I have squeezed the data acquisition routines into this space, but other overlays need more code space and don't need the device common; most don't need the virtual array either. The data acquisition overlay doesn't need the RMS routines. Can I use memory management executive calls to dynamically change the task window size and reassign APR's? How do I tell the Task Builder to use the same virtual address range (same APR) for the high 4KW of the task window and for the device common? Likewise, I want to use one APR for the second-highest 4KW of the task window and for the mapped array area (virtual array). I want the task to start up with the full task region size allocated, but mapped with the smaller task window, and the "shared" APR's set to the device common and mapped array area, respectively. Then I can save that mapping context and re-assign those APR's to extend the task window and back again as needed. Is there a way to do this? Or a way to swap between the RMS library region and the device common "region"? Any suggestions for other solutions would be greatly appreciated, as well.