Physical memory access with SystemV/AT

[Larry Williamson]

In article <28070 at clyde.ATT.COM> wtr at moss.UUCP (Bill Rankin) writes:

>>In article <185 at focsys.UUCP>, larry at 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