edstrom@elmer.hsc.ucalgary.ca (John Edstrom) (01/25/91)
Is there anyway to link a module to an absolute address? The reason I ask is that the device I am writing a driver for (Data Translation's 1492 AD/DA & etc board) has 1/2 Meg of dual ported memory on board. Idealy the user program would be able to read/write from the DT1492 memory while the device is acquiring data. My problem is accessing the memory from a program without going to system mode. I tried using colored memory but the os dumps about 12 bytes of important stuff at the bottom of the memory section when I request it from the system. Since there lots of bytes around the loss of data space doesn't bother me much. However, the ADC will writes data over these magic numbers and all attempts to access that segment of memory fail with a buss error. The easiest way I can think of is to create a non-relocatable data psect and then link my program to it. But I can't see how that is possible. An alternative would be to jump into system mode, copying the data I wanted into a user-space buffer, returning to user mode and continuing with the data manipulations. Although my real-time application will probably not suffer from this it seems like a barbaric thing to do. Is there any way around this impasse? John Edstrom | edstrom@elmer.hsc.ucalgary.ca -- RM 2104, HSc Building, Div. Neuroscience U. Calgary School of Medicine, 3330 Hospital Drive NW Calgary, Alberta T2N 3Y4 (403) 220 4493 (wk)
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/28/91)
edstrom@elmer.hsc.ucalgary.ca (John Edstrom) writes: > Is there anyway to link a module to an absolute address? > The reason I ask is that the device I am writing a driver for > (Data Translation's 1492 AD/DA & etc board) has 1/2 Meg of dual > ported memory on board. Idealy the user program would be able > to read/write from the DT1492 memory while the device is acquiring > data. My problem is accessing the memory from a program without > going to system mode. Well, you could hardcode the memory address in your program <yuk>. Or you could add a getstat call to your driver, which simply returns the base address of the memory... this at least would remove address-dependence in your applications. (or ahhh... is the ram protected by the machine, and only directly accessible in system state?) > An alternative would be to jump into system mode, copying the data I > wanted into a user-space buffer, returning to user mode and continuing > with the data manipulations. Although my real-time application will > probably not suffer from this it seems like a barbaric thing to do. Slower, but not barbaric at all. A getstat that copied the data to the requesting user would also let the driver handle incrementing its own pointer through the data. Customize to your needs: perhaps one getstt to return all data, another to return current info right THEN, another to return next in queue with a timestamp, and so on. That gives you device independence also. kevin <kdarling@catt.ncsu.edu> PS: did you ever find your bus error?
rlb@skyler.mavd.honeywell.com (Randal L. Barnes) (01/28/91)
edstrom@elmer.hsc.ucalgary.ca (John Edstrom) writes: > Is there anyway to link a module to an absolute address? kdarling@hobbes.ncsu.edu (Kevin Darling) writes: > Well, you could hardcode the memory address in your program <yuk>. We had a similar problem with our Heurikon 68030 boxes. We used the OS/9 f$permit call to give the application access to the area of memory in question (this got rid of the 102 error). It is not a pretty solution, but it does help get the work done by Friday ;-) -- Randal L. Barnes rlb@skyler.mavd.honeywell.com Tea, Earl Grey, HOT! Honeywell Military Avionics Division 612/542-5021
kdarling@hobbes.ncsu.edu (Kevin Darling) (01/29/91)
rlb@skyler.mavd.honeywell.com (Randal L. Barnes) writes: >>> Is there anyway to link a module to an absolute address? >> Well, you could hardcode the memory address in your program <yuk>. > >We had a similar problem with our Heurikon 68030 boxes. We used the OS/9 >f$permit call to give the application access to the area of memory in question Interesting! I can see the F$Permit call in the funcs.a defs, but not in my manual. Could you post the parameters needed, in case others are in the same boat and wish to see if it works for them? thanks! - kevin <kdarling@catt.ncsu.edu>
rlb@skyler.mavd.honeywell.com (Randal L. Barnes) (01/29/91)
> > Interesting! I can see the F$Permit call in the funcs.a defs, but > not in my manual. Could you post the parameters needed, in case > others are in the same boat and wish to see if it works for them? > thanks! - kevin <kdarling@catt.ncsu.edu> Here is what we use for f$permit and f$protect in "C": #asm * permit(addr, len, perm) /* grant access*/ * void *addr; * int len; * int perm; permit: link a5,#0 movem.l d1-d2/a0,-(sp) movem.l a2,-(sp) movea.l d0,a2 start address to allow move.l d1,d0 length to allow move.l 24(sp),d1 permission required (read/write/exec) os9 F$Permit movem.l (sp)+,a2 bra.l _sysret * * protect(addr, len) /* deny access */ * void *addr; * int len; protect: link a5,#0 movem.l d1-d2/a0,-(sp) movem.l a2,-(sp) movea.l d0,a2 start address to deny move.l d1,d0 length to deny os9 F$Protect movem.l (sp)+,a2 bra.l _sysret #endasm -- Randal L. Barnes rlb@skyler.mavd.honeywell.com Tea, Earl Grey, HOT! Honeywell Military Avionics Division 612/542-5021