larry@focsys.UUCP (Larry Williamson) (06/10/88)
How does one obtain access to physical memory in System V/AT?
I have a video processor board that I need to access. This board
is accessed through a 1Meg buffer mapped on any 1Meg boundry in
the 286's address range.
I would ideally like to be able to do whatever shmcreate does and
create a shared memory segment that I would then use to access the
memory on this board. But I would like to be able to create a
segment that is the full 1 Meg memory size, or at least be able
to create 4 256K segments.
I would like to do something like:
shmcreate 0x800000 800000 1048560
to create a 1Meg shared memory segment at the 8meg address location.
Shmcreate restricts segment sizes to 64K. So I must use something
else, but what?
If my only option is to use shmcreate and I have to restrict my
segment size to 64K, then I will. But even this may not work as
there may be a limit to the number of 64K segments that can be
created. I would need at least 16 of them.
Thanks, larry
--
Larry Williamson Focus Automation Systems
UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4
+1 519 746 4918mp1@sdcc12.ucsd.EDU (Leroy Dorman) (06/13/88)
In article <185@focsys.UUCP>, larry@focsys.UUCP (Larry Williamson) writes: > I would like to do something like: > shmcreate 0x800000 800000 1048560 > to create a 1Meg shared memory segment at the 8meg address location. Unless Microport put in a peek/poke-style function in to V/AT, (the Rel 1.0 from At&t didn't have one) there's no way to access physical memory from u-space. A device driver could get to where you want to go by twiddling a selector to get the right addresses but talking to the driver through ioctls or writes probably would be too slow You're right, it sure would be nice to assign a physical memory location to a segment selector so you can get at it in large-model user space programs. Poke, poke, uPort . . :-) ------------------------------------------------------------------- Eric Dorman Chekov-"The whole Gamma 7A University of California, San Diego System is, dead, sir. Scripps Institution of Oceanography Just, dead." siolmd!eric@sdsioa.ucsd.edu From- "The Immunity mp1@sdcc12.ucsd.edu Attn: eric Syndrome" dorman@mplvax.nosc.mil Attn: eric
bowles@lll-crg.llnl.gov (Jeff Bowles) (06/13/88)
In article <1019@sdcc12.ucsd.EDU> mp1@sdcc12.ucsd.EDU (Leroy Dorman) writes: >In article <185@focsys.UUCP>, larry@focsys.UUCP (Larry Williamson) writes: >> I would like to do something like: >> shmcreate 0x800000 800000 1048560 >> to create a 1Meg shared memory segment at the 8meg address location. > >Unless Microport put in a peek/poke-style function in to V/AT, >(the Rel 1.0 from At&t didn't have one) >there's no way to access physical memory from u-space... If you mean dereference a pointer and you're changing a character on the video screen, no, there's no portable way to do it. I am running Bell Tech SVR3, and the only choice *I* have is to open "/dev/mem" and lseek(2) to the location of the video buffer and write(2) out the places I want to change. But it DOES work, folks, albeit slowly (1-2 milliseconds to update the screen via one write(2) system call). More info, send me mail. It's not that hard, but certainly clumsy. Jeff Bowles
wtr@moss.ATT.COM (06/14/88)
In article <1019@sdcc12.ucsd.EDU> mp1@sdcc12.ucsd.EDU (Leroy Dorman) writes: >In article <185@focsys.UUCP>, larry@focsys.UUCP (Larry Williamson) writes: >> I would like to do something like: >> shmcreate 0x800000 800000 1048560 >> to create a 1Meg shared memory segment at the 8meg address location. >Unless Microport put in a peek/poke-style function in to V/AT, >(the Rel 1.0 from At&t didn't have one) >there's no way to access physical memory from u-space. >You're right, it sure would be nice to assign a physical memory >location to a segment selector so you can get at it in >large-model user space programs. >Eric Dorman eric - "what we have here is a failure to communicate" :-) microport V/AT allows root (via a shell script executed at bootup) to reserve specific memory locations as a shared memory resource. this allows you (the user) to access such wonderous areas as the display memory DIRECTLY! i currently am working with a set of graphics primatives that write directly to the screen, and you dont have to be root to do it, nor are there any nasty drivers to play with. larry- the only thing that i can suggest, since the [not really] large model supports only 64k arrays is to make 16 reserved sections of 64k memory to use for your 1 megabyte display buffer. probably use an array of 16 pointers to move this monster around. i don't have the manual here right now, so this is a standard disclaimer to quench any "you don't know what the &^*% you're..." postings which may follow. i believe that the above suggestion will work, and i can think of any better method. good luck! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
hedrick@aramis.rutgers.edu (Charles Hedrick) (06/14/88)
I don't understand the two messages saying they wished there were a way to access screen memory directly. There is, and the original question gave it. I even use it in my version of microemacs (the diffs for which were posted to this group some time ago). It uses the shmcreate program, which can be used to create a System V shared memory segment for a region of physical memory. The original question was simply whether there was a way to do this for a large segment (other than the obvious way of using several contiguous small ones). There is some maximum segment size documented (which I don't recall, since my documentation is elsewhere). It's that limitation on segment size, not the existence of the facility, which was the subject of the question.
larry@focsys.UUCP (Larry Williamson) (06/17/88)
In article <28070@clyde.ATT.COM> wtr@moss.UUCP (Bill Rankin) writes: >>In article <185@focsys.UUCP>, larry@focsys.UUCP (That's me!) writes: >>> I would like to do something like: >>> shmcreate 0x800000 800000 1048560 >>> to create a 1Meg shared memory segment at the 8meg address location. > >microport V/AT allows root (via a shell script executed at bootup) >to reserve specific memory locations as a shared memory resource. >this allows you (the user) to access such wonderous areas as the >display memory DIRECTLY! i currently am working with a set of >graphics primatives that write directly to the screen, and you dont >have to be root to do it, nor are there any nasty drivers to play >with. > > >the only thing that i can suggest, since the [not really] large >model supports only 64k arrays is to make 16 reserved sections >of 64k memory to use for your 1 megabyte display buffer. >probably use an array of 16 pointers to move this monster >around. >Bill Rankin You are absolutely right. This is the method that I was afraid I was going to have to use. It is ugly, but because of the basic limitations of the 286, it is all we can ask for. Upon closer inspection of my requirements, this is not as much a problem as I had first thought. The device that is being accessed is a colour frame grabber. There are 4 planes, one for each colour and one more for a text overlay. Each plane is 512 lines by 512 8 bit pixels. But at 60Hz, only the first 480 lines are available. If I break each plane into 4 sections, I have 4 segments of 120 lines which works out to 4 segments each of 61440 bytes. I will need 4 of these segments for each plane. A total of 16 segments, each a little smaller than 64K. If I code this carefully, then once all the segments are attached, the application will not even be aware that there are segment boundries being crossed. I'm not sure this is possible, but the way the man page on shmat() reads, it seems like I can. I would like to thank all who contributed to this discussion. Your input has been most helpful. If there are any further ideas that people have, please do speak up. Thanks, larry -- Larry Williamson Focus Automation Systems UUCP: watmath!focsys!larry 608 Weber St. N, Waterloo, Ontario N2V 1K4 +1 519 746 4918