Port I/O

Port I/O

[Robert P. Kuzmicki]

How do you do simple port I/O with ObjectAda 7.0? I must have been programming
in 'C' too long. 

Re: Port I/O

[Ed Falis]

Robert P. Kuzmicki wrote:
> 
> How do you do simple port I/O with ObjectAda 7.0? I must have been programming
> in 'C' too long.

A more interesting way to put this question is "how do I do simple
port i/o under Windows 95 or Windows NT?"

Which is what makes it not so simple.

There are three options I know of to address the mechanics of the
question:

1.  Write a device driver using the MS Device Driver Kit (DDK)
2.  Get a copy of BlueWater Systems WinRT, that provides this
    capability alog with direct real memory reads/writes and interrupt
    handling (206) 771-3610.  This package is basically designed to
    allow 'C' code to do realtime and hardware types of things udner
    NT and Win 95, but it's not too difficult to interface to.
3.  You can try to use the IN and OUT instructions provided in package
    Machine_Operations_386 with Objectada, but I suspect they won't
    work properly under at least NT.

To address the problem from a different angle, you might ask yourself
why you're trying to do what you're doing (presumably direct hardware
manipulation) from user code under NT or W95 rather than going through
a device driver.

Feel free to follow up via email.

- Ed
-- 
Ed Falis
Thomson Software Products
(617) 221-7341

Re: Port I/O

[Michael F Brenner]

Ed Falis of Thomson Software Products 617 221-7341 said:
 > you might ask yourself
 > why you're trying to do what you're doing (presumably direct hardware
 > manipulation) from user code under NT or W95 rather than going through
 > a device driver.

The obvious answer is that NT does not provide device drivers, or 
fast enough device drivers to do the kind of animation, serial control,
parallel control, disk access, and sound that the games, simulatons, and
robots we are building require. Extremely high level operating systems
have advantages for some types of software (like databases where speed
is not important). However, when controlling industrial or game processes,
you need much faster access to the bits of information (like pixels,
voxels, serial bits, and control bytes) than is possible with a four-level
security layer on top of an operating system kernel. The game developer
need to be able to by-pass the operating system whenever anything
interesting in the game needs to be programmed. As an example, in 
writing software that displays a map, even a background map, you need
direct hardware access to the memory mapped pixel in order to display it
fast enough that the user does not have to wait for it, and even then, 
you have to carefully control the order of the bits and bytes you display,
in order to gradually res and de-res the map up, to make up for the
extremely low bandwidth of current CRT-type displays. Until operating
systems realize this (as Windows NT 4 is beginning to, by granting
programmers a little bit of access to the pixels and some ports if they
buy an expensive game developers kit), programmers must resort to 
some not very nice practices in order to meet the performance requirements
of the software.
  

Re: Port I/O

[Robert S. White]

In article <55nf0f$7fq@top.mitre.org>, mfb@mbunix.mitre.org says...

...snip...

>The obvious answer is that NT does not provide device drivers, or 
>fast enough device drivers to do the kind of animation, serial control,
>parallel control, disk access, and sound that the games, simulatons, and
>robots we are building require. 

...snip...

  Sorry, A lot of us in this newsgroup are going to think that you will 
be better off in the long term in writing to some sort of API.  Currently
DirectDraw from MS fits your requirements the best.  I know that I would 
perfer that you write your current games to this spec.  This would make 
it easier for me to preempt my 15 year old son to get time on this 
computer for GNAT work or browsing comp.lang.ada

  If you are looking for a good Ada 83 compiler to write to simple x86
resource limited systems, try DDC Ada from Denmark (DDC-I in US).  Compile 
on Unix or VMS and target to the x86 system.  I know it works well.  
Engineers around here have been using it for avionics and other things 
for years.

_______________________________________________________________________
Robert S. White                    -- an embedded sys software engineer
WhiteR@CRPL.Cedar-Rapids.lib.IA.US --long/cheap alternate I-net address

Re: Port I/O

[tmoran]

> > manipulation) from user code under NT or W95 rather than going through
>The obvious answer is that NT does not provide device drivers, or
>fast enough device drivers to do the kind of animation, serial control,
  Does NT *allow* user code fast (or any) access to the IO ports?

Re: Port I/O

[Michael F Brenner]

>>The obvious answer is that NT does not provide device drivers, or
>>fast enough device drivers to do the kind of animation, serial control,
>  Does NT *allow* user code fast (or any) access to the IO ports?
It does, if you purchase the separately priced game developers kit. Without
the game developers kit you must override the security kernel to get
access to the pixels, ports, memory locations, and certain interrupts.

Re: Port I/O

[Simon Johnston]

I think the comments on NT are a little unfair, we are using it in a =
high-speed near real-time mission critical environment (150+ lane =
hypermarkets) where throughput is very much dependant on O/S =
performance. In this environment we have had to develop our own NT =
drivers for some hardware and make use of a number of other facilities, =
we also have a good relationship with the NT guys in Redmond.
As far as the game SDK is concerned I again question the comment on =
price, I got two copies free with our MSDN subscription (if your =
developing MS based software without MSDN you deserve everything you =
don't get!) and I'm sure if you talk nicely to MS they can get you a =
copy. With the game SDK Windows 95 and Windows NT have full DirectX, =
DirectSound, DirectDraw, DirectPlay etc. which do provide port level =
access to the hardware, fast enough for game programming.=20
As far as industrial control is concerned then I think you should be =
talking directly with Redmond as there is quite a push to get NT into =
this area.

Michael F Brenner wrote:
> Ed Falis of Thomson Software Products 617 221-7341 said:
>  > you might ask yourself
>  > why you're trying to do what you're doing (presumably direct =
hardware
>  > manipulation) from user code under NT or W95 rather than going =
through
>  > a device driver.
>=20
> The obvious answer is that NT does not provide device drivers, or
> fast enough device drivers to do the kind of animation, serial =
control,
> parallel control, disk access, and sound that the games, simulatons, =
and
> robots we are building require. Extremely high level operating systems
> have advantages for some types of software (like databases where speed
> is not important). However, when controlling industrial or game =
processes,
> you need much faster access to the bits of information (like pixels,
> voxels, serial bits, and control bytes) than is possible with a =
four-level
> security layer on top of an operating system kernel. The game =
developer
> need to be able to by-pass the operating system whenever anything
> interesting in the game needs to be programmed. As an example, in
> writing software that displays a map, even a background map, you need
> direct hardware access to the memory mapped pixel in order to display =
it
> fast enough that the user does not have to wait for it, and even then,
> you have to carefully control the order of the bits and bytes you =
display,
> in order to gradually res and de-res the map up, to make up for the
> extremely low bandwidth of current CRT-type displays. Until operating
> systems realize this (as Windows NT 4 is beginning to, by granting
> programmers a little bit of access to the pixels and some ports if =
they
> buy an expensive game developers kit), programmers must resort to
> some not very nice practices in order to meet the performance =
requirements
> of the software.
>=20
>=20
with StandardDisclaimer; use StandardDisclaimer;
package Sig is
--,----------------------------------------------------------------------=
---.
--|Simon K. Johnston - Technical Architect  (C++/Ada95) |ICL Retail =
Systems |
--|-----------------------------------------------------|St Martins =
Place   |
--|Internet : skj@acm.org                               |51 Bath Road    =
   |
--|Telephone: +44 (0)1753 793600 Fax: +44 (0)1753 793636|Slough          =
   |
--|Internal : 7286 4617   OP Mail: S.K.Johnston@BRA0801 |Berkshire, SL1 =
3UG |
--|WWW URL  : http://www.acm.org/~skj/                  |United Kingdom  =
   |
--`----------------------------------------------------------------------=
---'
end Sig;

Re: Port I/O

[Robert Dewar]

Michael Brenner said

"According to an NT worldwide web site, the Microsoft Developers
Network costs five hundred dollars the first year, and then
five hundred dollars each year thereafter, and it includes
the game developers kit (GDK or G-SDK) for that price. This is far
enough from being <free> that the comments on NT can be considered
fair."

I am not sure what you mean by "far enough from being free", this is
a pretty trivial amount, equivalent to less than one programmer day,
so I cannot see it being a barrier to any serious project.

Re: Port I/O

[Michael F Brenner]

According to an NT worldwide web site, the Microsoft Developers
Network costs five hundred dollars the first year, and then
five hundred dollars each year thereafter, and it includes
the game developers kit (GDK or G-SDK) for that price. This is far 
enough from being <free> that the comments on NT can be considered    
fair. Protection of databases from hardware access can decrease the
cost of the databases by making them platform independent. However,
protection of the pixels and ports from the programmers makes the
games and simulations more expensive, by reducing the number of
programmers with access to them, in particular, since not every
programmer prioritizes Microsoft Game Developers Kit as the most
important five hundred dollars to be spent. When a programmer
becomes debt-free, perhaps this is the best way to spend 500 dollars,
but according to statistics most programmers are in debt, and
might be better advised to pay off their debt before buying the
GDK. On the other hand, the quickest way to pay off debt is to
produce a best selling game, so the First thing to buy is the GDK?

Simon Johnston <skj@ACM.ORG> wrote:

:the comments on NT are a little unfair, we are using it in a
:high-speed near real-time mission critical environment (150+ lane
:hypermarkets) where throughput is very much dependant on O/S
:performance. ... we have had to develop our own NT drivers ...
:As far as the game SDK is concerned I again question the comment on
:price, I got two copies free with our MSDN subscription (if your
:developing MS based software without MSDN you deserve everything you
:don't get!) and I'm sure if you talk nicely to MS they can get you a
:copy. With the game SDK Windows 95 and Windows NT have full DirectX,
:DirectSound, DirectDraw, DirectPlay etc. which do provide port level
:access to the hardware, fast enough for game programming.

Mike had originally written:
> Ed Falis of Thomson Software
>  > you might ask yourself why you're trying to do what you're doing 
>  > (presumably direct hardware manipulation) from user code under NT 
> NT does not provide device drivers, or fast enough device drivers
> to do the kind of animation, serial & parallel & disk & sound access
> that games, simulatons, & robots require. A high level OS has
> advantages for databases where speed is not important. However, when 
> controlling industrial or game processes, NT requires you to purchase 
> expensive additional parts, such as the game developers kit, to put a
> pixel directly to the screen, address a memory location, or handle a 
> port interrupt.