Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!brutus.cs.uiuc.edu!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: The Inevitable 1.4 Rom Problem
Message-ID: <9252@cbmvax.commodore.com>
Date: 9 Jan 90 03:28:37 GMT
References: <13616@s.ms.uky.edu>
Organization: Commodore, West Chester, PA
Lines: 64

in article <13616@s.ms.uky.edu>, sean@ms.uky.edu (Sean Casey) says:

> How difficult is it to write software that has a reasonable chance of
> running on all configurations?

It's in general harder to do it wrong than right.  The vast majority of
programs that have had trouble on Amigas between OS revs have been 
games that throw out the OS, and similar things (like the Transformer).
For example, making calls to the OS.  If you're programming in the 
standard way, either assembly or HL, you'll have to go out of your way
to calculate a fixed ROM location, while using the library interface
is natural.  Same with jumping into ROM internals and other evil tricks;
you wouldn't naturally disassemble the ROM and look for code you can 
use.  

The next compatibility problem is the issue of CPU type.  The OS provides
the simple stuff, like the GetCC() call that handles the MOVE SR,<ea>
vs. MOVE CC, <ea> problem.  The more complex stuff is more along the lines
of simple guidelines; don't write self-modifying code, check the trap
type if you're processing exceptions, don't stuff data in the upper 8
bits of address, that kind of thing.  These guidelines have been around in 
some form since before the A1000 was out, and you can tell -- 99% of the
software out there works on the 68030; even many games.  We've also 
published expanded compatibility guidelines in AmigaMail for developers,
and I even did a presentation/paper on it at last a Developer's Conference
awhile back.  Nothing's kept secret here.

Secrets probably account for the third compatibility problem.  The Amiga
software folks publish the interface guidelines for various system
structures and routines.  Sometimes, a structure definition contains
private data, included to help the developer have some idea of what's
going on.  They generall have a warning like:

	/* **** THE FOLLOWING PART OF THIS STRUCTURE IS PRIVATE.  IT
		WILL CHANGE IN THE NEXT REVISION OF THE OS.  THIS IS
		FOR REFERENCE ONLY, DON'T YOU DARE USE THIS IN YOUR
		PROGRAM OR WE'LL SEND GREG BERLIN OVER TO YOUR HOUSE
		TO DO YOU SOME SERIOUS HURTS.
	**** */

Maybe I got the wording wrong, but you get the picture.  If a developer
were to ignore such a warning, and depend on the secret parts of such
OS implementation details, their software would break, as it's supposed
to.

> If I follow the rules, and find out what the "tricks and traps" of
> using the faster processors, is it feasable to write portable games on
> my old trusty A1000?

The stuff I wrote with Lattice 3.xx, a couple floppies, and 512K of RAM
on my A1000 runs on an A3000 (ooooh!) with the beta version of the 1.4 
OS (ooooh!).

> If you answered yes, would you bet your paycheck on it?

In some sense, anyone who's income depends on the Amiga probably is
already.

> Sean

-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough