NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/programm/17921

Internet Message Format | 1992-12-29 | 5.3 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!pepper.Eng.Sun.COM!cmcmanis
From: [e-mail] (Chuck McManis)
Newsgroups: comp.sys.amiga.programmer
Subject: Going to the metal
Date: 29 Dec 1992 20:34:17 GMT
Organization: Sun
Lines: 86
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: pepper

Hmm, you step away from the Amiga for a couple of years and the _same_
arguments are still going on. Amazing!

I've rather enjoyed the "Senseless weenies who write to the hardware"
versus the "Enlightened brethren who use the OS" debate. Not a lot of
new information has flown back and forth but its nice to know the two
camps still think the other is the moral equivalent of pond scum. The
really interesting thing is that rarely does the _real_ reason ever
come up as to why someone writes programs to got direct to the iron
or they don't. Laziness.

You see I've got a *lot* of Amiga games (all paid for) and have talked
to *alot* of developers for those games in both Europe and the US. Some
of them use the hardware and some use the O/S, some are more playable
than others. For every developer that uses the hardware, I've had the
"Why didn't you use the O/S?" discussion. And while their arguments
always start out "I needed every ounce of performance I could wring
out of the machine ...", or "I could fit 8 times the code into the
game ..." they always end up with "and besides, its easier to do it
that way."

This is the most powerful motive. Take the most trivial example, finding
out where an 8 axis joystick is pointed. Do we open the "gameport.device"
at the begining of the game and look for messages on the input stream
to tell us where the stick is? Or do we just "mov d1,#port" ?
From the developers perspective the "life" of a game is about 6 months,
that's about how long they generate revenue before they are "old" and
no one buys them anymore. No one ever bothers to "upgrade" games because
generally the users aren't like me and they just stop playing them after
a while. This means that the developer who uses the O/S is investing
effort that for the most part will only be appreciated by a very small
percentage of their customers. The _only_ time it is a serious issue
is during an O/S transistion like the 1.3 -> 2.0 transistion or now
the 2.0 -> 3.0 transistion. And that is because _all_ of their customers
are potentially upgrading and if they don't work on the "new" O/S then
they are going to get serious negative feedback. Consequently, from
the developer perspective (and from an economic perspective) using
the O/S is a non-issue.

That aside, there are of course "hidden" costs and revenue opportunities
from being O/S friendly. In particular, the "learning curve" for the
Amiga can be quite high. Thus when a developer becomes "trained" on what
the current hardware looks like, they have to pay this cost again when
they get new hardware. Further, when a company "hires" a new programmer
they pay the cost again to bring that person up to speed. Of course the
whole *purpose* of an operating system is to provide an unchanging
"architecture" appearance to the developer while the company innovates
underneath on the hardware. Thus using the operating system insulates
the developer from having to pay these learning costs again and again.

The problem, presented in these terms, is much more simply stated:
  "The O/S model embodied in the Amiga is too complex and thus
   unsuitable for the development of short lifetime, real time
   applications."

One solution to this problem might be to provide an Operating system
model that is tuned to game writers. Clearly such an O/S would have
the appearance of writing directly to the hardware, however that
hardware could be suitably masked behind the OS. A really good example
of how one might accomplish this is the "virtual" 8086 mode of the
'386 and '486. Here a hardware page fault mechanism is used to "catch"
writes to the things that are hardware registers on the original
PC, and do something "useful" with them based on the actual hardware
of the system. Certainly something like that could be done on any
Amiga with a MMU, but it could also be done using the existing messaging
system. Imagine if you will a "spec" that says that address X contains
the X position of the mouse, Y contains the Y position, and Z contains
the state of the buttons. Further, J contains the bits associated with
joysticks 1 and 2 in the upper and lower 4 bits and at address I
is the bits for the display plane 0, I+n plane 1, etc. Now using this
virtual machine is just as easy as using the actual hardware, except
that now, the changes in the O/S are "invisible" to games that use
them.

So Commodore could do this, or an enterprising developer could (I
hear that something similar is done at Lucasfilm to minimize the
cost of "porting" between platforms.) but as long as there are people
writing code, some of them will write to the hardware and cause
people like me to use a "Kickstart tower" to keep old copies of the
ROMs around.


--
--Chuck McManis                Mr. NIS+                Sunsoft
uucp: {anywhere}!sun!cmcmanis   BIX: <none>   Internet: [e-mail]
These opinions are my own and no one elses, but you knew that didn't you.