Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Booting from EPROMS?
Message-ID: <1991Apr25.113559.30013@kuhub.cc.ukans.edu>
Date: 25 Apr 91 16:35:59 GMT
References: <1909c537.ARN0fa1@cbmami.UUCP>
Followup-To: comp.sys.amiga.programmer
Organization: University of Kansas Academic Computing Services
Lines: 54

In article <1909c537.ARN0fa1@cbmami.UUCP>, jason@cbmami.UUCP (Jason Goldberg) writes:
> 
> 	I have a customer who is a comercial video game manufactuer, who
> has reached an agreement to produce stand-alone video games using A500
> motherboards.  There programers are busy getting up to speed on the Amiga,
> but one of their concerns is how they will be able to boot off an EPROM
> rather than a floppy disk.  Their machines will not have floppies!
> 	Does anyone have any suggestions/pointers that I could pass along?

Yes.  If they dont want to use the Amiga OS, then they just burn the
EPROMs with the code they want and replace the OS ROMs.  On the Amiga,
when the CPU twiddles the RESET lines, the CIAs reset, one of these
bits forces the ROMs to Address 0x00 where the 68000 then loads the
starting PC and SP from locations 0-7.  When the OVERLAY bit in the
CIA (B?) is set, then the ROMs move to 0x00F00000 where they normally
reside.

If they want to emulate a boot disk to use the OS, one thing
to do is hang the EEPROMs off the exapnsion port emulating an
AUTOCONFIG RAM board.  The eproms get burned with a valid RAM image of
whatever RAD looks like in RAM (including ROMtags, etc) so the system
adds RAD to DOS, and then boots off it when it doesnt find any
floppies.

Or, another thing to do, would be emulate a hard disk type controller
(AUTOBOOTING/AUTOCONFIG of course) that would use EPROMs to pretend to
be a small disk, and then let the OS load the RigidDiskBlocks and
FileSystem off of the EEPROMs and it would come up in dos.

I think the RAD approach would be simpler, but much more prone to
potential problems (ie: does ramb0.device *have* to be able to write,
etc) and more portability problems.  The "silicon disk" technique
would more complex at first, but easier to change since its easier to
figure out what an "image" of a disks data should be as opposed to
RAD.  Read/Write isn't a problem since the OS can boot from read only
media.

> Thanks,
> 
> 
> -Jason-
> 
> ---------------------------------------------------------------------------
> Jason Goldberg				UUCP: ucsd!serene!cbmami!jason
> Del Mar, CA				
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  mgooderum	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~