OS/2 vs DOS vs Windows for memory access

OS/2 vs DOS vs Windows for memory access

Post by Kevin Mey » Wed, 24 May 1995 04:00:00



"For it is said, go not to the Usenet for advice; for it will say both yes
and no, and quite a few things you can't relate to the actual question" -
Martin Walker

Ok knowing the above, I'm here anyway, and this time money will be spent on
the results. Please people, I need information, not third-hand opinions.

We are about to embark on several large projects which require real-time
image processing. We don't have an extremely large budget so Sun systems are
out, but PCs are in, as long as the image grabber isn't too expensive [like
US$3000] and the primary developing platform will be C.

PROBLEM:
I need to be able to directly manipulate memory at a specific high memory
location, for example at 11 meg. This memory is the card memory of a image
grabber. Presently, to the best of my knowledge, this is physically
impossible under DOS.

The images will all be about 256k to 380k in size, and need to be globally
addressable all the time: IE I need to be able to access pixel at (0,0) and
at (767,255)  and a few other random ones without having to swap memory about.

My options are:
DOS: Use DPMI or some such extended memory manager to bring the memory to
conventional space, manipulate it, and use same manager to put the memory
back.. Are there any 32 bit protected mode DOS compilers?
CONS: Slow. Very slow.

Windows: I have no idea. Was told to use Selectors, but could never get them
to correctly access the memory in question.
CONS: Slow. 16 bit. [Yeah, yeah, scream all you like about win32s.. How do I
access high memory directly [if I know the linear address] in win32s?

OS/2: Again, I have no idea. How do I go about accessing a known linear
address in OS/2?

I'm in favour of using OS/2 because I believe if it can allow me to access this
physical memory directly, ie by making a char pointer point to it, then I'll
be able to take advantage of an up and running 32 bit OS to access the whole
image and several buffers. But I have no solid info on how to go about doing
this in OS/2.

I'll be writing my own drivers, if need be, though cards under consideration
are the Creative Labs SE200 [SE100?] video blaster, and similar. The DT 3851
card, while nice, VERY NICE, is also very pricey.

So if you all out there could show me how I'd go about accessing 400k images
on the card's own memory in C under your favourite platform [DOS protected
mode, Windows, Win32s, OS/2 PM, OS/2 native], I'll then look at the platform
and method and make a decision [taking into account whatever other information
you give..]

Other hardware platforms are also acceptable options, but we'll be writing
our own applications.

Simple, isn't it?

--

This is not mine, I had nothing to do with it.| #include <std_disclaimer.h>
Kevin Meyer, Plasma Physics Research Institute|Everyone knows the war is over
University of Natal, Durban, South Africa     | and the good guys lost - LC.
         http://flyer.ph.und.ac.za/users/kev/welcome.html

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by sim.. » Wed, 24 May 1995 04:00:00



Quote:>PROBLEM:
>I need to be able to directly manipulate memory at a specific high memory
>location, for example at 11 meg. This memory is the card memory of a image
>grabber. Presently, to the best of my knowledge, this is physically
>impossible under DOS.
>OS/2: Again, I have no idea. How do I go about accessing a known linear
>address in OS/2?

>I'm in favour of using OS/2 because I believe if it can allow me to access this
>physical memory directly, ie by making a char pointer point to it, then I'll
>be able to take advantage of an up and running 32 bit OS to access the whole
>image and several buffers. But I have no solid info on how to go about doing
>this in OS/2.

Ok. This is what I *KNOW*

Under any intel based OS, protected  mode will required to address memory at
these high addresses. I have know idea how it is done using DPMI or
Windows.

Under OS/2 things are not quite as you expect!

You will need a device driver.  Only device drivers are allowed
to access physical memory directly.

To write a driver for OS/2 you really need the OS/2 Device Driver
Developer's Connection CD-ROM from IBM.  It is not expensive and it
*WILL* cost you more to try to write one without it.

The driver can have access to the entire adapter address space, but
cannot give an application such access (at least I am 95% sure and
I've been writing OS/2 drivers on and off for over 5 years). The
application would have to call into the driver (via the kernel) to
use this technique.

A driver can give a calling application direct memory access to (up to) 64kB
chunks of RAM, but this would involve the memory mapping you want to
avoid.

I have written a video capture driver for a fast JPEG capture card,
and used the 2nd technique.  An alternative is move more
functionality into the driver, but this is harder to write and debug
(drivers use a 16:16 or mixed segmentation model, and have to know
about different sorts of address).

Mail me with any queries.

Regards

Simon Bowring

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Phil ~Phlash~ Ashb » Thu, 25 May 1995 04:00:00



> PROBLEM:
> I need to be able to directly manipulate memory at a specific high memory
> location, for example at 11 meg. This memory is the card memory of a image
> grabber. Presently, to the best of my knowledge, this is physically
> impossible under DOS.

> The images will all be about 256k to 380k in size, and need to be globally
> addressable all the time: IE I need to be able to access pixel at (0,0) and
> at (767,255)  and a few other random ones without having to swap memory about.

Since you need fast, simple programming, then a 32-bit compiler under
DOS will probably provide the best option. You have a choice (of course)
of Watcom/DOS4GW or DJGPP/GO32.

I know very little about Watcom, but doubtless others will help here.

I do know that DJGPP/GO32 (which is free BTW!), allows you to malloc()
large buffers (eg: 1MByte is no problem), and index them normally. It
also provides a ready-made selector to access linear addresses using a
suitable 'far' pointer eg:

byte far *videoBuf = MK_FP(go32LinearSelector(), cardAddress);

where MK_FP() macro puts a far pointer together for you, and cardAddress
holds the linear address of the card (11 MBytes say).

Quote:> Simple, isn't it?

Hopefully yes <g>.

Phil ~Phlash~ Ashby.

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Saulni » Thu, 25 May 1995 04:00:00


: "For it is said, go not to the Usenet for advice; for it will say both yes
: and no, and quite a few things you can't relate to the actual question" -
: Martin Walker

: Ok knowing the above, I'm here anyway, and this time money will be spent on
: the results. Please people, I need information, not third-hand opinions.

: We are about to embark on several large projects which require real-time
: image processing. We don't have an extremely large budget so Sun systems are
: out, but PCs are in, as long as the image grabber isn't too expensive [like
: US$3000] and the primary developing platform will be C.

: PROBLEM:
: I need to be able to directly manipulate memory at a specific high memory
: location, for example at 11 meg. This memory is the card memory of a image
: grabber. Presently, to the best of my knowledge, this is physically
: impossible under DOS.

: The images will all be about 256k to 380k in size, and need to be globally
: addressable all the time: IE I need to be able to access pixel at (0,0) and
: at (767,255)  and a few other random ones without having to swap memory about.

: My options are:
: DOS: Use DPMI or some such extended memory manager to bring the memory to
: conventional space, manipulate it, and use same manager to put the memory
: back.. Are there any 32 bit protected mode DOS compilers?
: CONS: Slow. Very slow.

: Windows: I have no idea. Was told to use Selectors, but could never get them
: to correctly access the memory in question.
: CONS: Slow. 16 bit. [Yeah, yeah, scream all you like about win32s.. How do I
: access high memory directly [if I know the linear address] in win32s?

: OS/2: Again, I have no idea. How do I go about accessing a known linear
: address in OS/2?

: I'm in favour of using OS/2 because I believe if it can allow me to access this
: physical memory directly, ie by making a char pointer point to it, then I'll
: be able to take advantage of an up and running 32 bit OS to access the whole
: image and several buffers. But I have no solid info on how to go about doing
: this in OS/2.

: I'll be writing my own drivers, if need be, though cards under consideration
: are the Creative Labs SE200 [SE100?] video blaster, and similar. The DT 3851
: card, while nice, VERY NICE, is also very pricey.

: So if you all out there could show me how I'd go about accessing 400k images
: on the card's own memory in C under your favourite platform [DOS protected
: mode, Windows, Win32s, OS/2 PM, OS/2 native], I'll then look at the platform
: and method and make a decision [taking into account whatever other information
: you give..]

: Other hardware platforms are also acceptable options, but we'll be writing
: our own applications.

: Simple, isn't it?

: --

: This is not mine, I had nothing to do with it.| #include <std_disclaimer.h>
: Kevin Meyer, Plasma Physics Research Institute|Everyone knows the war is over
: University of Natal, Durban, South Africa     | and the good guys lost - LC.
:          http://flyer.ph.und.ac.za/users/kev/welcome.html

        Under DOS, use Watcom.  But you'll need some assembler.  I can help
you there.  All you need to do is allocate a selector, set the base, limit and
some access rights.  And you're off.  You need some assembler to access this
memory though.  DS is used for all variables, but you will need to use, say
ES, FS or GS for the new selector you are using.  Then just use segment
overides to access your memory.  If you decide to use Watcom, ust e-mail me,
I'll be glad to help you with anything, even some assembler routines to set
the thing up, read the memory and write to it if that's possible.
These selector routines are DPMI function in case you want to know.  I'll look
and see if I can't modify the page table somehow.  Since DOS4GW programs run
at protection level 0, it should have access to everything.  If I succeed in
modifying the table, this will let you use C only!

        Cleo Saulnier

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Steven Georg Goodrid » Thu, 25 May 1995 04:00:00



> We are about to embark on several large projects which require real-time
> image processing. We don't have an extremely large budget so Sun systems are
> out, but PCs are in, as long as the image grabber isn't too expensive [like
> US$3000] and the primary developing platform will be C.

> PROBLEM:
> I need to be able to directly manipulate memory at a specific high memory
> location, for example at 11 meg. This memory is the card memory of a image
> grabber. Presently, to the best of my knowledge, this is physically
> impossible under DOS.

No one seems to realize it, but OS/2 Warp comes with video capture support,
making it a great platform for image processing, since it supports more
video capture amd multimedia hardware than any other 32-bit platform. I only
wish IBM would market it this way and save a lot of engineers a lot of
grief trying to do such under DOS and Windoze.

If you want to address the pixels repeatedly, as required for many
image processing and computer vision applications, it is best to get a copy
of the image into main memory RAM. The MMPM/2 api will do this for you.
For fastest image aqcuisition, one may need to use the streaming API,
but the MCI_GETIMAGEBUFFER command is good for 5-10 frames/second. I
hope IBM does a better job documenting these functions and improving them.

The trick is to shop in the multimedia market as opposed to the
industrial vision market, if you want to do video capture under OS/2
at a reasonable price. I paid $200 for my Jovian Logic QuickVia.
It's color and accepts SVIDEO as well as NTSC.

Also, you can use OS/2's multimedia support for video capture cards
in order to capture images into our program. The Video In application
that comes with the Bonus Pack adds video capture support to MMPM/2
(Multimedia Presentation Manager for OS/2.) Video In comes with drivers
for several brands/models of capture cards. Once you install the
hardware, followed by Video In, you can write programs to copy
the image data into your program RAM.

The api you'll use to capture video is part of the MMPM/2 programmer's
toolkit. You'll open the DIGITALVIDEO02 device (capture card) using the
mciSendCommand or mciSendString function, then use mciSendCommand to
perform the MCI_GETIMAGEBUFFER command. This returns an RGB OS/2
bitmap into the RAM you allocate for it. I recommend you get the
OS/2 Warp Multimedia Programming Guide and the Warp Programming
Reference; they have some examples of how to use MCI_GETIMAGEBUFFER
and how to open the device, etc.  The MMPM/2 toolkit is on DEVCON
and available with CSet. Once you get to the programming part, feel
free to send me mail for more help. It took me a while to figure it out.
One thing I didn't realize at first is that you have to set the
rectangle parameters of the MCI_GETIMAGEBUFFER command to get the
maximum image size. I'm telling you this now so you know; it wasn't
documented!

The capture cards supported under OS/2 MMPM/2 are listed under the
Video In installation screen (you can quit installation after viewing
these) or are described int the last two _OS/2_xxxx_Unleashed_ books
under the section on Video In. They include Jovian Logic, Video Blaster,
etc. (although the latest Video Blaster, the RT300, is not supported.)
Note that you may have to tell your bios to exclude the memory used
by these cards under some systems. Also, the Video Blaster cards limit
your PC to 16Meg of RAM.

I have found the Jovian Logic card to perform very well, despite its low
price. It uses software to put the image in the window, as opposed to
the Video Blaster, which uses an overlay cable. Also, the Jovian card
captures directly to RGB, which is good for my work; the Video Blaster
captures to YUV, which would require more time to convert to RGB.

I use color, and many vision applications do not, so I'll address this
now. SVIDEO provides very good color information - much better than
NTSC, but not as good as RGB. For my application, SVIDEO is good
enough, and I hate to pay the premium price for RGB (which has no OS/2
support.) Also, a color multimedia video capture card is often less
expensive than many B&W capture cards, because it is sold on the mass
market.

You can use a color capture card with a B&W camera, but
you should use a card with higher color depth. My QuickVia is
16 bits per pixel: 5 red, 6 green, 5 blue. This is good enough
for my color needs, but a B&W camera would provide the same voltage
on all three channels, meaning a max of 6 bits (green) of gray scale
values are available. The api converts the image to a 24-bit/pixel
image, but you're stuck with only 2^6 visible levels from B&W video. A
card that captures 24-bit color, like the QuickVia Pro-24, will provide
8-bit color depth.

Many of these capture cards are available through mail from Indelible
Blue. There are multiple resolutions, speeds, color depths, and bus
types available. Support for PCI cards should be coming very soon.

Steve Goodridge
NCSU

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Martin Tom Brow » Fri, 26 May 1995 04:00:00




Quote:> We are about to embark on several large projects which require real-time
> image processing. We don't have an extremely large budget so Sun systems are
> out, but PCs are in, as long as the image grabber isn't too expensive [like
> US$3000] and the primary developing platform will be C.

> PROBLEM:
> I need to be able to directly manipulate memory at a specific high memory
> location, for example at 11 meg. This memory is the card memory of a image
> grabber. Presently, to the best of my knowledge, this is physically
> impossible under DOS.

[snip]

Quote:> OS/2: Again, I have no idea. How do I go about accessing a known linear
> address in OS/2?

You need to make a device driver to give you a suitable r/w selector
for the physical region of memory you want to access.

You probably ought to have the DDK, but as an indicator of where to
start you could try looking at how RamScope and Physmem.sys work.
The latter is a device driver which allows you to do * things
with physical memory it might be a useful starting point for you.

Try on any Hobbes mirror - ramscope.zip  &  physmem.zip

They are quite old. Using physmem.sys makes the OS vulnerable.

HTH
--

Scientific Software Consultancy             /^,,)__/

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Tim Smi » Fri, 26 May 1995 04:00:00



>PROBLEM:
>I need to be able to directly manipulate memory at a specific high memory
>location, for example at 11 meg. This memory is the card memory of a image
...
>My options are:
>DOS: Use DPMI or some such extended memory manager to bring the memory to
>conventional space, manipulate it, and use same manager to put the memory
>back.. Are there any 32 bit protected mode DOS compilers?
>CONS: Slow. Very slow.

That's wrong.  What you'd do is tell DPMI to allocate an LDT selector,
and then tell DPMI to set that selector to refer to the desired physical
memory.  You don't have to "put the memory back" after you manipulate it.
It would stay mapped for the duration of your program.  I think you are
thinking of something like EMS, which maps 16k chunks of memory into the
lower megabyte for V86 (or real mode) programs to access.

Basically, as long as you don't need multitasking and don't need
protection at the file system level, DOS with a 32-bit DOS extender
is as reasonable a platform for running a 32-bit program as a Unix
system or OS/2 or NT is.  (Assuming you also don't mind 8.3 filenames,
and stuff like that).

You can also do this from Windows, but a 32-bit program with a DOS
extender should be faster than a 16-bit program under Windows.  FYI,
here's how you would access memory from Windows:

        struct SREGS    s;
        unsigned short sel;
        char            * mp;

        segread( &s );      /* gets current values of segment registers */
        sel = AllocSelector( s.ds );    /* clone selector */
        SetSelectorBase( sel, your_linear_address_goes_here );
        SetSelectorLimit( sel, size_of_your_memory_area+1 );
        mp = MK_FP(sel,0);      /* mp now points to your memory */

When you are going to exit, do this:

        FreeSelector( sel );

If you could not get this to work, you probably did this:

        sel = AllocSelector( 0 );

which, according to the manual, allocates a new uninitialized selector.
At first, that seems to be exactly what you want.  However, the access
rights for that selector are set to "no access" and you die when you
try to use it!  That's why my example clones DS.  That gives a selector
with the access rights set to "R/W Data", which is what you want.

At least one Windows compiler (Watcom) includes a Windows Extender.  The
concept is similar to that of a DOS extender, except it is for Windows, so
you can write full 32-bit code (not win32s) under plain Windows.

For DOS, I think all the major compilers either include or have available
as extra cost options 32-bit DOS extenders.  I know Watcom does.  There's
also a GCC port to DOS that includes a free DOS extender.

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Tim Smi » Fri, 26 May 1995 04:00:00



>Ok. This is what I *KNOW*

>Under any intel based OS, protected  mode will required to address memory at
>these high addresses. I have know idea how it is done using DPMI or
>Windows.

Evidently, what you *KNOW* doesn't include the LOADALL instruction! :-)
(One would have to be rather insane to actually consider using it, but
a determined person could in fact access high memory addresses without
leaving real mode on most 386's and many 486's).

--Tim Smith

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Tim Smi » Fri, 26 May 1995 04:00:00


If you developed your application on Linux, you could simply open
the file "/dev/mem", and then use the mmap() system call to map the
file into your address space.

--Tim Smith

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Jerome Chapdelai » Mon, 29 May 1995 04:00:00


Is everybody here forgetting that the base address of a selector does not
correspond to a PHYSICAL address?  You can never assume this because almost
all protected mode system use the paging capabilities of the processor to
remap memory (that includes most dos extenders, windows, os/2).  Under DPMI
(DOS extenders and Windows 3.x), there are functions to get access to
physical memory (to allow DMA transfers).  Under os/2, I'm not sure but I
think you would have to write a driver.

        Jerome C.

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by Adrianus den To » Tue, 30 May 1995 04:00:00



Conc: Re: OS/2 vs DOS vs Windows for memory access

Hi chapde00,
Du meintest am 28.05.95 um 03:12 im Brett /COMP/OS/OS2/PROGRAMMER/MISC:
c>
c> Under DPMI
c> (DOS extenders and Windows 3.x), there are functions to get access to
c> physical memory (to allow DMA transfers).  Under os/2, I'm not sure but I
c> think you would have to write a driver.

hmm, here it's getting very interesting (for me...).
I found out that when the VDM's DPMI Settings are sized such, that
the base Address of an Video Accelerator Cards Aperture Memory will
be reached,- then you will find that DPMI fails in that specific VDM
telling it is not able to install!
(example: Accelerator Aperture at 64MByte Base,
          DPMI MEMORY LIMIT > 64MByte ; oops - doesn't work!)

Does this really mean that physical mapping via DPMI is not supported in
VDM's?

This would be _really_ sad as it would prevent me from writing a
Graphics Driver for the ATI MACH 64 Accelerator. This accelerator
features only aperture-memory mapped I/O in the PCI Version...

Tried this issue on CIS, but there was no response that gave a definit
answer to this question...

Anyone that knows?

cu/2
  -> echo me,  Arie <--       If Windows 9? is the answer,-
                              who ever did ask this stupid question?
## CrossPoint v3.0 R ##

 
 
 

1. MCP vs W4 vs DOS - refresh my memory, please

As I understand it, Boot Manager and fdisk are sort of pre-operating system
utilities, and MCP messes with that.  So, if I install MCP, it is a more
serious commitment than installing a regular fixpak.

And I may never use fdisk again.

So, does MCP play nicely with Warp 4 and DOS?  e.g. a machine with a C:
partition using Dos 5.n & Win3.1 [just accept the fact!], a maintenance
partition with Warp 4 and a working partition with Warp 4.  If I now install
MCP over the working partition [apparently acceptable procedure], then

is the maintenance partition any use any more?  or do I have to move it to
MCP also?

what happens with the DOS partition?  oh, I promise not to use the DOS fdisk!

Peter

*/------------------------------------------------------

   Wadsack Management; Madison WI USA
------------------------------------------------------*/

2. connecting batteries q.

3. OS/2 vs Dos vs Windows on the book shelf

4. How to force delivery of a sendmail queue entry?

5. Missing the Point (OS/2 vs MS vs OS/2 vs MS etc...)

6. Bubble & Squeak

7. OS-9 vs. OS/A65 vs. UNIFlex vs. LUnix/LNG

8. Any Suggestion in rack modems ?

9. OS/2 vs. DOS vs. NT

10. JPEG: OS/2 vs. DOS vs. DOS386

11. Win95 vs. NT vs. OS/2 for DOS development

12. OS/2 vs Windows <----> C64 vs ZX Spectrum - echoes of the past....