Calling LoadSeg() from Bootblock?

[mcgeezer]

Hi all,

I'm hoping you can answer what is probably a simple yes or no question for me.

Is it possible to call LoadSeg from within the Bootblock? I'm having fun trying to even open the dos.library from within the bootblock, but I just wanted to know even when I do manage to do that is it simply a case of calling LoadSeg on my executable program?

The end game here is to simply save ram and load my game straight away without the system having to open Workbench and startup sequence stuff.

Any help is really appreciated.

Cheers,
Graeme

[ross]

Short answer: no

[mcgeezer]

Originally Posted by ross

Short answer: no

Heheheh Cheers Ross!

[admiral]

LoadSeg() is a dos.library function.

http://amigadev.elowar.com/read/ADCD.../node0279.html

However, when the bootblock runs, dos is still not initialized.

A bootblock's job is to tell the kickstart's strap module what to run next, by returning a pointer. Then strap frees the memory the bootblock uses, and jumps to that pointer (remember this, as you seem to care about available memory!).

Generally, that's a pointer to dos.library's Init routine (a fixed offset in the structure FindResident() returns).

If you were to init dos.library from your bootblock (via exec's InitResident()), dos would literally take over, so your bootblock code wouldn't run anymore, and on top of that, the bootblock would never be freed from memory.

Thus, there's two general approaches to take here:

- Load the executable you want to run by yourself, without dos.library's help. This is what you want, but you have to take care that your game's startup/exit code will not misbehave if you run it from AmigaOS, think RAM: or HDD.
- Take over the system completely from your game. This is inconvenient, as you can't use exec for allocations (because you can't free dos.library's memory). It also means AmigaOS might not be usable anymore (crash) if you attempted to use it, so you shouldn't. Now your game can't "exit" but by reboot/poweroff.

You'll find games generally use either approach.

The "without dos.library help" will mean in practice that you either write your own "trackloader", use trackdisk.device (preferable!) or use some code with a compatible license written by somebody else for comfortably loading from floppies. Some might even be able to understand standard filesystems.

You can still launch programs as tasks using exec's AddTask(), but you need to prepare them in memory yourself.

Note that if your game is self-contained in a single file, there's definitely tools out there that will prepare a floppy image for you that just loads and runs your game without ever opening dos.library.

[mcgeezer]

Thanks admiral - that is useful info.

[admiral]

Originally Posted by mcgeezer

Thanks admiral - that is useful info.

You're welcome. Just give AmigaXfer a go if you haven't yet.

[Don_Adan]

Perhaps if your exe file will be not very complicated, you can create easy and short LoadSeg routine and place this routine in game bootblock.
Im not 100% sure, but if i remember right some old Amiga HD systems used external LoadSeg routine (supplied by Commodore) for loading HD drivers. No dos.library accesses.

[Bruce Abbott]

Originally Posted by mcgeezer

The end game here is to simply save ram and load my game straight away without the system having to open Workbench and startup sequence stuff.

You don't ever have to open Workbench, and startup-sequence stuff doesn't use much memory or time.

Unless you want to kick out the operating system and take over the whole machine I suggest you use it as intended. This will make your program more compatible and user-friendly.

[defor]

If you really want to take over the whole OS (and loose all its available functions), you may take a look at recently released Leonard's LDOS system. It allows you to load execs and data from the floppy.

[Galahad/FLT]

Simply allocate memory in bootblock, then use track disk which is already active to load code, if needs be you can then use a relocate routine, and away you go.

If you wanted to absolutely have all memory available to you, every last byte, then taking over system and utilising a hardware banging sector loader is the other way forward.

[mcgeezer]

Originally Posted by Galahad/FLT

Simply allocate memory in bootblock, then use track disk which is already active to load code, if needs be you can then use a relocate routine, and away you go.

If you wanted to absolutely have all memory available to you, every last byte, then taking over system and utilising a hardware banging sector loader is the other way forward.

This all then leads back to the whole WHDload saga. If I create a track loader I then eliminate hard drive users unless I use WHDload.

[jotd]

One possibility would be to format the disk as DOS, use a trackloader (like Rob Northen) to read the executable file in memory and execute it with a minimalist loadseg/relocate routine. There are several available.

And leave your exe runnable from hard disk. Run with a give argument (ex: HD) to read files using trackloader or DOS. Include trackloader in your exe but use it only in the case you booted from floppy.

Simpler: don't use the bootblock but let the OS load your exe, but depending on an argument (same idea as above) use the OS or trackloader to load.

supercars2 has IFD directives to read from MFM track or OS for instance. This was for dev stages and was disabled in production but you can make it dynamic.

[Galahad/FLT]

Originally Posted by mcgeezer

This all then leads back to the whole WHDload saga. If I create a track loader I then eliminate hard drive users unless I use WHDload.

Nope.

If you so wanted to, you could write a bespoke hard drive installer for your game, hiding the AmigaDOS executable on the disk.

But in all honesty, a whdload version would come any way.

[admiral]

Originally Posted by Galahad/FLT

hiding the AmigaDOS executable on the disk.

Let's not give people data-destroying ideas :/

[Galahad/FLT]

Originally Posted by admiral

Let's not give people data-destroying ideas :/

Well I'd hope no "cracked" version appears, but if they fuck it up, thats on them not Graeme

[admiral]

Originally Posted by Galahad/FLT

Well I'd hope no "cracked" version appears, but if they fuck it up, thats on them not Graeme

It's never OK to bypass the filesystem the user selected as install target, and just clobber blocks somewhere.

[Galahad/FLT]

Originally Posted by admiral

It's never OK to bypass the filesystem the user selected as install target, and just clobber blocks somewhere.

What filesystem?

Its whatever Graeme wants it to be, its not on him to guess what others would do with the disk, and he isn't obliged to worry about it either.