Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!alberta!atrc!mofh!ersys!aunro!atha!aupair.cs.athabascau.ca!cpsc.ucalgary.ca!yogi.fhhosp.ab.ca!yogi.fhhosp.ab.ca!news From: edstrom@elmer.hsc.ucalgary.ca (John Edstrom) Newsgroups: comp.os.os9 Subject: Message-ID: <1991Jan28.094415.1747@yogi.fhhosp.ab.ca> Date: 28 Jan 91 15:44:14 GMT References: <1991Jan24.162635.1742@yogi.fhhosp.ab.ca> <1991Jan28.022859.24393@ncsuvx.ncsu.edu> Organization: Dept. Clinical Neurosciences, Univ. of Calgary, Calgary, Alberta, Canada Lines: 63 Nntp-Posting-Host: elmer.hsc.ucalgary.ca In article <1991Jan28.022859.24393@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes: >edstrom@elmer.hsc.ucalgary.ca (John Edstrom) writes: > >> Is there anyway to link a module to an absolute address? >> ... blah blah blah >> going to system mode. > >Well, you could hardcode the memory address in your program . >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?) > Knowing the address is not the problem. The program loads into some portion of the available user memory and either the data buffers are outside of my program/data space and are flagged as bus errors (illegal memory reference) or else my program loads into the data buffers in which case my program and/or data will be overwritten by AD conversions. What I really want to do is to get the linker/loader recognise the data buffers as part of the user program's data space. > >> An alternative would be to jump into system mode, copying the data I >> ... blah blah blah >> 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 I don't see offhand how that can be done. The driver and program would still need to have access to a commonly accessible section of memory. I don't see how getstat can return more than one word at a time to the user program. Repeated getstats to recover 256 kB would be too tedious. My current strategy is to use a trap executing in System State to copy the data to/from the data buffers, sort of a mmccpy. Given the speed of the processor this is not crippling but it is irksome in that the system state restricts use of some traps and other features it just makes it that much more trouble to use. It seems to work OK but it requires that the program know more about the device than I'd like. > >PS: did you ever find your bus error? Nope. Not all of them anyway. I found one error. There are two or three outstanding. One is in the boot rom. Another results from having garbage written into the static data section during the initialization process. 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)