pecampbe@mtus5.cts.mtu.edu (Paul Campbell) (11/05/90)
The OS-9 TeX package is available from the Bitnet COCO list in the
OS-9 file listings. To subscribe, send mail to listserv@Pucc.Princeton.edu
or listserv@Pucc.BITNET with the following line in your body:
sub coco Your Full Name
You might also want to include the line
index os9
get coco memo coco
The first sends you an index of all the files available under the OS-9
directory and the other one sends you the standard user blurb (now very
much out of date, I should rewrite it) about the list.
Paul Campbell
COCO List Manageredstrom@elmer.hsc.ucalgary.ca (John Edstrom) (01/28/91)
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 <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?) > 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 <kdarling@catt.ncsu.edu> 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)
kdarling@hobbes.ncsu.edu (Kevin Darling) (02/05/91)
edstrom@elmer.hsc.ucalgary.ca (John Edstrom) writes: |>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> | |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. The program could pass the address of some of its own memory, and the driver could then copy the data to/from it and the A/D Ram, since the driver is in system state and should have global access: ***************************************************** * GetStt calls * a1 = path desc * a2 = device memory * a4 = proc desc * a5 = user reg stack * a6 = sys globals ... cmpi.w #SS_AData,d0 statcall to return A/D ram data beq AData ... ***************************************************** * SS_AData getstt call: return A/D data * Call copies (d3) amount starting at (d2) offset * in the A/D Ram back to user's buffer at (a0). * User passes: * a0 = buffer address in user space * d0.w = path * d1.w = SS_AData code * d2.l = beginning offset (often just 00) * d3.l = copy count in bytes AData move.l V_PORT(a2),a3 a3 = a/d RAM address adda.l R$d2(a5),a3 + begin offset move.l R$a0(a5),a0 a0 = user's buffer move.l R$d3(a5),d1 d1 = amount to copy ADLoop move.b (a3)+,(a0)+ copy the data subq.l #1,d1 bne.s ADLoop rts return with Carry clear, d1=0 Optimize or customize to own taste, including error checking on sizes, and much faster copies. To use, your program might: move.w adpath(a6),d0 path number move.w #SS_AData,d1 statcall lea buffer(a6),a0 program-allocated data area moveq #0,d2 beginning at offset 0, move.l #4000,d3 copy 4000 bytes of A/D data os9 I$GetStt to our buffer ... You could also use the same code # as a SetStat, if there's a need for copying info the other direction. This is probably similar to what you're doing now, but with a statcall it becomes "legal" and fairly independent of the hardware. best - kev <kdarling@catt.ncsu.edu> PS: can you describe how your apps usually use the data? In large lumps? Does the A/D converter continously store new info, or does it need a trigger? Etc. The design of a statcall might depend on these. PPS: it took a week for your message to arrive here. Apologies if you've already figured something out. - kev