From: brett@visix.com (Brett Bourbin)
Subject: Re: Going to the metal
Date: Wed, 30 Dec 1992 16:43:49 GMT
Reply-To: brett@visix.com
Organization: Visix Software, Reston, Virginia

In article <lk1di9INNrsa@exodus.Eng.Sun.COM> cmcmanis@pepper.Eng.Sun.COM  
(Chuck McManis) writes:
[interesting article deleted]

Chuck talks about development time differences in coding "to the metal"  
and using the OS. While his example of reading the joystick port is  
effective (although not using the correct processor 8^) ), there are  
things that go into creating a game the seems to be ignored by most people  
in these newsgroups (since most are NOT using a low-end Amiga with minimum  
resources).

When writing a game, the first thing you must do is identify who your  
customer is going to be. Many people here think that should be EVERY Amiga  
owner, which would be really nice, but sometimes, not realistic. With this  
in mind, when I write games, I first think about the majority of Amigas.  
This happens to be 68000-based 512K machines, with 1M machines starting to  
make its way to the top. So now I have a "target" machine to develop for.

The first thing I did when starting to write games is I learned the OS. I  
did things with graphics and exec and input and gameport OS calls. Know  
what, it was too slow to take on what was being done on other machines and  
other games on the Amiga (the competition). I guess I might add the type  
of games I write are 3D perspective, arcade-type action titles (not  
everyones "cup of tee").

So what I did next (and I will try to give some pointers here, so this  
article has some validity) was create a new OS. This OS takes over at boot  
time and gives me a basically empty machine. A quick list of some of the  
functions my OS has are:
	Kernel manager
		revectoring kernel functions
		timing
		vertical blank processing and hooks
		processor cache manipulation
	Display manager
		can create an build "Views" like the AmigaOS
		color control (fading and such)
		can create special Copper tricks
		double-buffering
	Event manager
		handles mouse, joystick and keyboard inputs
	Process manager
		handles multiple process for "multi-tasking"
	Object manager
		maintains image objects
		handles animation language programs
		efficient use of Blitter for sprites
	Memory manager
		clearing memory
		filling memory
		drawing lines and plotting points
		scaling, shearing and rotation image memory
	Math manager
		handles trig functions
		matrix operations
		random numbers
	Debug manager
		revectors processor exceptions
		serial debugging between target->host
	Disk manager
		handles floppy disk reads and writes
	etc...
All of this fits in 8K of code (excluding buffers and images), is written  
in assembly and can be assembled for different 68K-based machines. It also  
uses the whole memory map for its use (remember there is no AmigaOS  
running at this point).

So how does it get started? During the boot process:
	allocs a section of CHIP memory for the kernel
	reads the tracks that have the kernel into this memory
	extracts what type of machine we are on
		gets ExecBase->AttnFlags
		gets VBR
		figures out how much and type of memory
	opens graphics library
	loads NULL View
	waits a few frames
	shuts down the AmigaOS
	saves all the info gathered in kernel memory
	clears caches if needed
	jumps to kernel
	relocates kernel to its home and initializes

Yes, I have already passed the point of no return (almost). I also have a  
boot loader that works from my harddrive that will do all the same things  
that the bootblock loader does and save state so it can restore on exit.

Now all of this was not "easy" but it does go down to the metal. It also  
works on all the machines I have tested from 68000 to 68040s and A500 to  
A3000s. All my games (application code) is written to my gameOS (kernel)  
and is reused. I paid the development cost once. The application is free  
to use the extra memory for its own caching (disk tracks, images, sounds,  
etc.)

I am very sorry that C= is not releasing info on the AGA chip set, since I  
would add support in the kernel for it.

So, as you see, going to the metal may not be always easier, but it does  
allow writing a game that will work almost as good on a A500 as on a A3000  
with extended resources. This is the MAIN reason why I wrote my kernel as  
the hardware level and not the AmigaOS level (along with being able to  
write for SEGA machines).

--			 _  _    _      _
Brett Bourbin		(_ |_ | /__ | |(_  4431 Lehigh Road, Suite 151
  brett@visix.com	__)|_ |_\_/ \_/__) College Park, Maryland 20740
  ..uupsi!visix!brett	      LIMITED	   703.758.2733