Path: utzoo!attcan!uunet!clyde.concordia.ca!mcgill-vision!snorkelwacker!apple!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.sys.amiga.tech
Subject: Re: More assembly questions
Keywords: Abacus Book
Message-ID: <12836@netcom.UUCP>
Date: 6 Jun 90 05:04:49 GMT
References: <11891@cbmvax.commodore.com> <17861@ultima.cs.uts.oz> <18345@well.sf.ca.us>
Organization: Dave McMahan @ NetCom Services
Lines: 52


 In a previous article, farren@well.sf.ca.us (Mike Farren) writes:
>vilkas@ultima.cs.uts.oz (Iron Wolf) writes:
>>If for instance, you were working on a commercial game, you would want the 
>>fastest routines and such with which to work. In this case...out goes the OS,
>>program the hardware! (not a good practice for application programming) 
>
>Wrong!  In stays the OS, program the hardware.  It isn't hard - why do
>you people have such a hard time comprehending this?  YOU CAN PROGRAM
>THE HARDWARE IN AN OS-FRIENDLY WAY.  Really.

There are mechanisms for this, and in general I have found it to be true.  But..

>You don't need to kill the OS.  You don't need to kill the multitasking
>(usually).  You don't need to take over anything, and you damned well don't
>need to write directly to hardware locations which probably will not
>exist five years from now, or will do different things.

..the program I have written for the amiga does have a problem with AmigaDos
in that the Dos inhibits interrupts for up to 250 uSeconds every 'once in a
while'.  This screws with my data, as I use interrupts to detect events, and
the events are VERY sensitive to even that much time delay.  The problem is
minor, but it IS noticable if you look.  It does show up in the image being
created.  The interrupt is from an external data source, and comes in via
the parallel port.  I have spoken via phone with Bob 'Kodiak' Burns in Los
Gatos (an original Amiga Design team member and can be classified as One-who-
should-know-what-he-is-talking-about) and he said that the only way to get
the problem to go away is to start shutting down various portions of AmigaDos.
Throwing out AmigaDos is something I REALLY don't want to do, so I have
decided to live with the slight (but noticable) problem.  I could make the
external hardware supplying the signal more complicated, but the idea was
to keep it ultra-simple so anyone with a little experience could build it.

>Besides, I've seen a lot of games programmers who claimed to need
>"every cycle the machine has to offer", and every one who made such a
>claim was simply a less-than-competent programmer, disguising his own
>inability to be truly creative by blaming it on the OS.  I haven't seen
>one single game for the Amiga yet which I could not replicate, given
>time, in an OS-friendly way.  Not one.  And almost every time I've
>actually had the chance to see some of the "lightning fast" code that
>people have actually produced, there have been eleventy-seven different
>ways of improving their speed by a factor of four or more, simply by
>analyzing the code and eliminating deadwood.  And I've been doing this
>professionally (games, that is) since 1978, so I suggest that perhaps I
>know what I'm talking about :-)

Well, if you can figure out how to get around my little dilema without adding
anything to the cost or complexity of the external hardware, I'm ALL ears.

>Mike Farren 				     farren@well.sf.ca.us

   -dave