Accessing dos.library during boot time

[Leffmann]

Is it possible to open dos.library and get DOS file access during boot time? OpenLibrary fails, and calling FindResident and InitResident will just put me right in AmigaDOS with the CLI open.

[Samurai_Crow]

Dos.library should always be accessible. It is in the Kickstart. I don't know why OpenLibrary would fail. Are you specifying an incompatible version number?

[StingRay]

Originally Posted by Leffmann

Is it possible to open dos.library and get DOS file access during boot time? OpenLibrary fails, and calling FindResident and InitResident will just put me right in AmigaDOS with the CLI open.

I don't think that loading files via dos.library during boot is possible. Why do you need something like that anyway? "Workaround" would be to use trackdisk.device to load files directly.

[Leffmann]

Originally Posted by Samurai_Crow

Dos.library should always be accessible. It is in the Kickstart. I don't know why OpenLibrary would fail. Are you specifying an incompatible version number?

Nope I'm calling it correctly, specifying version 33 for 1.2.

I don't really need to open files during boot time but I'm very curious to know if it's doable without that expansion.library trick. Using trackdisk.device works I guess, though if you intend to store data as DOS files it will be one hell of a workaround.

If anyone knows how to, please post

[Toni Wilen]

dos isn't available at boot time, it gets initialized after boot block returns and it can't be initialized like other libraries. Dos is special case..

[Leffmann]

Alright I'll take that as a definite answer. Thanks.

[Toni Wilen]

Create task from boot block that polls library list and continue when dos.library appears?

Note that even if dos.library is available, you couldn't call any interesting functions because boot block code isn't using Process environment.

btw, WinUAE clipboard sharing does some (stupid) tricks. It starts a task during boot phase, checks every few seconds if dos.library is initialized, opens it, creates a process which finally can open clipboard.device..

[StingRay]

I'd just store the pointer to the filename somewhere and then just have a small loader which would load the file (like it was done in all the boot menus back in the day). This of course is not exactly what you want (as the file is not loaded during boot) but may be ok as workaround?

[Leffmann]

Originally Posted by Toni Wilen

Note that even if dos.library is available, you couldn't call any interesting functions because boot block code isn't using Process environment.

Which means no reading of DOS files. I should've realized it wasn't doable since no one else had done it before.

Originally Posted by StingRay

I'd just store the pointer to the filename somewhere and then just have a small loader which would load the file (like it was done in all the boot menus back in the day). This of course is not exactly what you want (as the file is not loaded during boot) but may be ok as workaround?

You mean to exit to the CLI and let a loader take over from there? Loading from inside the boot block would be neatest though. I've digested files straight to the disk and used trackdisk.device to do it before and it still seems to be the only option I guess.

[StingRay]

Originally Posted by Leffmann

You mean to exit to the CLI and let a loader take over from there? Loading from inside the boot block would be neatest though. I've digested files straight to the disk and used trackdisk.device to do it before and it still seems to be the only option I guess.

Yeah, that's what I meant. If you really want to load directly from bootblock you need to use trackdisk.device. If you save your files on disk with a custom tool which saves all offsets/lengths in a table it shouldn't be much of a problem to do that.