How To Disable The Operating System

                          by James Margitich


    Author's Biopic:  For those who haven't read one of mine before,
  I'm an aspiring games programmer.  The first thing I needed to do
  was disable the operating system, so I thought I'd write an article
  about it in case anyone else needs (or wants) to know.

    Warning:  Programs which disable the Operating System break most
  of the rules for Amiga programming set down by Commodore.  They are
  not able to multitask and all functions must be performed by direct
  manipulation of the hardware (which is the whole point of the
  exercise anyway).


  38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38


Why?
       Why would anyone need to disable the Amiga's Operating System,
  from now on called the OS, anyway?  The multitasking that the OS
  provides is one of the major advantages of the Amiga over other
  computers.  It contains heaps of routines that can save programmers
  a LOT of work.  So why get rid of it, ever?  The answer is that
  there are two disadvantages to using the OS.  First, all it's
  structures and the structures that have to be created to use the
  various OS routines take up plenty of memory.  I read just having
  the OS enabled takes up 100K.  To some programs, mostly games, this
  is a huge amount of memory and having it used by the OS is a waste
  due to the second disadvantage of the OS.  It is S-L-O-W.
  Multitasking slows it down even more.  Most games need to run as
  fast as possible to be playable.

Is it worth it?
       If you disable the OS, you have to write everything at hardware
  level, reading and writing hardware registers directly.  This is
  (supposedly) more difficult than using the OS routines (it isn't
  that much more difficult really but you have to take care of things
  that the OS normally handles, and it's more work), so why bother?
  The reason that game programmers generally disable the OS and hit
  the hardware directly is that it's the only way.  Arcade games just
  DON'T WORK properly if they use the OS, especially if there are lots
  of animated characters on the screen.  Games with only a few
  characters and limited animation could be written using the OS but
  they tend not to be anywhere near as popular as games that don't use
  the OS.  (This is a very broad generalization and is not intended as
  an insult to people who write games which use the OS, some of which
  are quite good).  What about loss of multitasking then?  Isn't that
  a serious disadvantage?  I would argue that it isn't.  Who wants to
  multitask while playing a fast-paced action game?  Not me, that's
  for sure.  Can you imagine trying to play a shoot-'em-up with aliens
  attacking left right and centre, writing a letter with your word
  processor, entering names and addresses in a database and working
  out your tax return on a spreadsheet, all at the same time?  "To
  whom it may concern, I am writing to inform you that damn!  ran into
  it again, useless @#%& of a game!...", "Citizen, John, 23
  end-of-level guardian Road, LaserDeathville", and what about "Total
  deductions for financial year:  17 zomboids, 30
  instant-death-inducing-mutants and 2 slime splatters".

How? Method 1
       There is in fact a sort of OS legal way of disabling the OS.  I
  say "sort of" because I very seriously doubt if Commodore would
  endorse it but it does use OS routines.  All you have to do is load
  a NULL View into the system and then wait for two vertical blanks.
  Loading a NULL View disables the Intuition display and tells the OS
  to switch everything off, including some things that a lot of
  programmers (including me but then I'm only a beginner) don't know
  about (probably because they don't need to.) This makes sure that
  the program takes control of everything, whereas if the program had
  to take over things directly, you might forget something and then
  spend hours (or days, or weeks, or...) looking for some obscure bug
  causing weird effects.  Waiting for two vertical blanks just gives
  the copper list time to clear.  In C you would write a section of
  code like this:
      LoadView(NULL);
      WaitTOF();
      WaitTOF();
  assuming that you have already opened the graphics.library first
  that is.  If you want to enable the OS afterwards then you would
  save the ActiView field in GfxBase with some code like this:  struct
  View *oldActiView;
	 Forbid(); /* Make sure system doesn't change ActiView */
      oldActiView = GfxBase->ActiView;
  and then to enable the OS, then you would use this:
      LoadView(oldActiView);
      WaitTOF(); /* Give system time to get started again */
      WaitTOF();
      Permit();
  which should bring things back to normal.  I know that most games
  are written in Assembler and very rarely in C but the C code is a
  lot shorter to put in an article and you can see the Assembler
  equivalent in the files TakeSystem.s and Takesystem2.s which I have
  included.  By the way, I found out about this method of disabling
  the OS from the Programming section of the Amiga Answers Special in
  Amiga Shopper Issue 18, October 1992, which was written by Toby
  Simpson, the lead programmer for Millennium and author of Robocod
  and Diggers.

How? Method 2
       The other method of disabling the OS is to directly disable it
  by using hardware registers.  This is best done in Assembler but the
  source for this method is in the file TakeSystem2.s so I won't
  duplicate it here.  This method is not even remotely "legal" and if
  you have to disable the OS, Commodore would almost certainly prefer
  you to use the previous method.  If you want to restore the OS
  afterwards you have to save the contents of the INTENAR and DMACONR
  registers.  Once you have done that you can disable all interrupts
  and dma, shutting down the OS.  After all interrupts and dma have
  been disabled, clear out the INTREQ register to sort out any
  interrupts that might be occurring at the time, and then the OS is
  gone.  You can then do whatever you need to with the hardware.  When
  you have finished you can restore the OS by simply restoring the
  contents of the INTENA and DMACON registers with the values that you
  saved at the beginning or'ed with $8000 to set the Set/Clear bit
  appropriately and the system will take it from there.  Whew!  If
  your interested, I found out about this method from the two games
  programming tutorials in Amiga Format.  The first one was by Dave
  Jones of DMA Design (the author of Lemmings) in Issues 7-13.  The
  second was by Scott Johnston of Bullfrog (the team that wrote
  Populous) in Issues 39-43.

A Note About The Examples
       The code was written for Devpac 2 which was given away with
  Amiga Format Issue 39 to coincide with Part 1 of the Bullfrog game
  programming tutorial.  It should work with just about any assembler
  without too much trouble but you might need to make minor
  modifications for some assemblers.  Check in your assembler's manual
  if it doesn't assemble correctly.
       One more thing, don't forget that when working in binary, bit 0
  is always the last one.  For quite some time I thought you entered
  binary numbers in increasing numerical order i.e.  bit 0 first, then
  bit 1 etc., but while writing TakeSystem2.s I worked out that it was
  the other way round.  This explains a bug in a program I was writing
  quite some time ago that I just couldn't fix.  Unfortunately, I gave
  up on trying to fix it and deleted it.  @#$%!
  
How To Use The Routines In Your Own Code
       First, chose whichever method for disabling the OS you prefer.
  Then load either TakeSystem.s (if you want to use method 1) or
  TakeSystem2.s (if you want to use method 2) into your text editor.
  Delete the body of the program which does the colour changes and is
  indicated by comments, and write your code there.  REMEMBER TO SAVE
  THE RESULTING FILE UNDER A DIFFERENT NAME!!
       Alternatively, you could type in the sections that disable and
  enable the OS as required or insert them if your text editor will
  allow it.  Use whichever method you prefer.

In Closing
       The programs TakeSystem and TakeSystem2 are the assembled
  versions of TakeSystem.s and TakeSystem2.s respectively.  TakeSystem
  uses method 1 and TakeSystem2 uses method 2.  As you will see when
  (and if) you run them, there isn't really any difference in
  functionality.  Well I can't see one, if you can then please share
  it with us all via the letters page!  Because of this, I can't
  really recommend one or the other, so use whichever one you find
  easiest to work with.  Happy programming!(?)


  38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38 *^* 38