[comp.sys.amiga.tech] Non-ADOS Bootstrapping

ditto@cbmvax.UUCP (Michael "Ford" Ditto) (12/06/88)

In article <379@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes:
>This brings up an apropos point.  I have been trying to think of a way
>(but haven't actually gotten much coding done) of booting a non-AmigaDos
>OS.

This is described briefly in the RKM: It's Appendix L in the old one-
volume RKM.

>What I would like to do, is be able to use the trackdisk driver,
>rather than talk directly to the drive (ick).

Actually, what you want to do is to use the device driver for
whatever device you are booting from, whether it's trackdisk or
something else.

>                                              However, since I don't
>want to use Exec, I am unsure if trackdisk will work (is it
>multitasking, or just a routine?).

Trackdisk won't work without Exec, since the only way to talk to it
is with Exec I/O requests.

>                                    Another alternative would be to
>keep everything running under Exec until I get enough stuff loaded
>into memory, and then take over.

That's the way to go.  When your boot-block code is executed, it is
passed a pointer to an I/O request which can be used to read the rest
of your boot code or whatever else you want to do with the device.

>                                  It might even be possible to do an
>OpenLibrary and use that to load the new OS, but would this work before
>DOS is initialized?

OpenLibrary will work, but you won't have any disk-based libraries
because DOS is not initialized.  You should be able to do everything
you need with Exec functions like DoIo(), assuming your boot code
knows what format the disk is in, etc.; you won't be able to Open()
any AmigaDos-disk-format files.  For that matter, I don't think you'll
even be able to OpenLibarary("dos.library").

>Does anyone have any interesting ideas about how Amiga UNIX does/will
>do this (since they have to bootstrap also...)?

Currently, Unix doesn't use the Exec boot procedure, it has boot code
in ROM on the 2620 card.  This has sevaral disadvantages, primarily
that this code only knows how to boot from a floppy or 2090 disk.

>Other wierd problems...  The RKM manual is vague about what state
>the machine is in during/after the bootstrap code.

This is certainly true.

>                                                    When I return from
>the bootblock code, is the Amiga non-multitasking, or do I have to
>disable Exec?  

I don't think much of anything happens between the time you return
from the boot code and when Exec calls the address you return.  Exec
is "running", so you can use it to create tasks or whatever...  if
you intend to take over, you will need to take over everything,
meaning that you must provide *all* device drivers, interrupt
handlers, and memory allocation, among other things.  If you're
going to "take over" right away, you might not bother returning from
the boot code.

>               Also, since I would like to create executables from
>Manx (or Asm68K) object files, should I just be compatable with
>the standard executable format and use 'ln' or 'blink'?  If not, how
>does one actually link something (this isn't discussed in any of my
>compiler design books)?

Since you'll have to provide our own routines for loading executables,
there is no real advantage to booting from the AmigaDos file format,
but there are still reasons why you would want to, mainly that you
could use standard linkers, etc.  The same argument applies toward
using COFF format files if you were using a COFF linker, etc.

> Of course, now I plan on getting mail from people wondering why I'm not
> satisfied with AmigaDOS, why kick out Exec, etc.

Not from me, although if you're writing your own OS from scratch, I
would recommend that you consider throwing out AmigaDos but keeping
Exec -- it's a real nice platform for just about any type of OS you
would want to run.
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford@kenobi.cts.com
- The Unix Programmer's Manual,		...!sdcsvax!crash!elgar!ford
  2nd Edition, June, 1972.		ditto@cbmvax.commodore.com