Re: Port I/O

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

[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. 

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.

$500 <= chump change, was Re: Port I/O

[Tom Moran]

There do exist companies where $500 is beyond the petty cash aloowance
of a low level manager.  More to the point, here in Silicon Valley, a
lot of games, and other things, were initiated by programmers in their
'off hours' and using their own money.  To my high school son, for
instance, $500 is not 'a pretty trivial amount'.  If you expect the next
original game, Ada killer app, or whatever, to come from MS, Lockheed,
IBM, or such, then $500 or $1K/year is a low hurdle.  History, however,
suggests innovations often come from kids with a bright idea, and I
suspect such prices will steer their creativity elsewhere.
  But perhaps $500/yr is a straw man, a monopoly price paid only by a
very small segment of the market.  Perhaps "starving students" get their
copy for free from school, and bright young employees of "serious
project" companies just take a copy home with them.  I personally
dislike such hypocrisy, but "when in Rome, do as the Romans do" is
usually practical advice.

Re: $500 <= chump change, was Re: Port I/O

[Robert Dewar]

Tom Moran says

"There do exist companies where $500 is beyond the petty cash aloowance
of a low level manager.  More to the point, here in Silicon Valley, a
lot of games, and other things, were initiated by programmers in their
'off hours' and using their own money.  To my high school son, for
instance, $500 is not 'a pretty trivial amount'.  If you expect the next
original game, Ada killer app, or whatever, to come from MS, Lockheed,
IBM, or such, then $500 or $1K/year is a low hurdle.  History, however,
suggests innovations often come from kids with a bright idea, and I
suspect such prices will steer their creativity elsewhere."

I think you are creating a fantasy world here, and not the kind of
fantasy world that we are interested in!

These days, sucessful video games cost well into 7 figures to develop
(they can gross hundreds of millions if they are successful, so that's
not out of line by any means), but the days when high school students
could do interesting things in the game market is long gone!

Re: $500 <= chump change, was Re: Port I/O

[Tom Moran]

>These days, sucessful video games cost well into 7 figures to develop
>...
>but the days when high school students could do interesting things in
>the game market is long gone!
  Perhaps that's why my 8 year old was moved to ask "Why are the games
with the best graphics the most boring?" :(

Re: $500 <= chump change, was Re: Port I/O

[Robert Dewar]

Tim Moran says

"  Perhaps that's why my 8 year old was moved to ask "Why are the games
with the best graphics the most boring?" :("

Interesting, but in this country, the big market winners in the game market
are precisely violent action games with good graphics. Not my taste, I 
much prefer RPG games with interesting puzzles and the graphics are
secondary, but I am afraid we are in a minority (interestinly enough,
in Japan, such RPG games are the big sellers).

Re: $500 <= chump change, was Re: Port I/O

[Tom Moran]

>These days, sucessful video games cost well into 7 figures to develop
>...
>but the days when high school students could do interesting things in
>the game market is long gone!
  The problem with $500 for the game SDK is not that I expect high
school kids to develope Wolfenstein XXXVII, but that the real
innovations, the first computer game, etc, usually do not arise from
heavily funded projects.  And if doing port IO on a PC requires high
up-front expenditures, it greatly reduces the likelihood of any really
novel thing using port IO.  Of course successfull players are rarely
eager to change the rules of the game, and MS in particular is probably
not eager to repeat anything like their recent experience with the Web
and Netscape etc so it makes eminent economic sense for them to
encourage all new products to be minor variations of current ones, with
MS getting a slice of the pie.

Re: $500 <= chump change, was Re: Port I/O

[Richard Riehle]

On 17 Nov 1996, Robert Dewar wrote:

  In response to Tom Moran's notion that high-schoolers and other
  "amateurs" could introduce any new game ideas into the market.

> I think you are creating a fantasy world here, and not the kind of
> fantasy world that we are interested in!

  Methinks you dismiss this notion with excessive haste, Robert. I still
  live here in Silicon Valley and lots of high-school, community
  college, and university students are experimenting with ideas
  for new games. 

> These days, sucessful video games cost well into 7 figures to develop
> (they can gross hundreds of millions if they are successful, so that's
> not out of line by any means), but the days when high school students
> could do interesting things in the game market is long gone!

  I disagree with this.  What first comes to mind is Tetris. A simple
  game, hugely successful, and continuing to be popular.  The 7 figures
  you mention is true of the elaborate games with sophisticated graphics,
  but some high-school student somewhere is going to invent some 
  clever game with the simplicity of Tetris that will be every bit
  as successful as the games from established game publishers.

  Moreover, with the growing use of Internet-based games, and other
  telecommunications services, games programmed in Java will become
  more important.  And those fancy graphics that cost millions, will
  be, for the near term, more of a nuisance than a blessing because of
  the slow transfer data rates still in use in the average household.

  The advent of telephone-based computing provides fertile ground for
  a completely new set of games that we cannot even imagine -- but some
  eighth-grader is already planning.

  Richard Riehle

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.

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