Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!mcnc!ncsuvx!news From: kdarling@hobbes.ncsu.edu (Kevin Darling) Newsgroups: comp.os.os9 Subject: Re: Message-ID: <1991Feb5.043247.17057@ncsuvx.ncsu.edu> Date: 5 Feb 91 04:32:47 GMT References: <1991Jan24.162635.1742@yogi.fhhosp.ab.ca> <1991Jan28.022859.24393@ncsuvx.ncsu.edu> <1991Jan28.094415.1747@yogi.fhhosp.ab.ca> Sender: news@ncsuvx.ncsu.edu (USENET News System) Organization: NCSU Computing Center Lines: 73 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 | |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 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