Detect dos.library/RT_INIT 'done' in BootBlock

[NicoDE]

Hi,

I'm trying to get used to m68k assembler and developed a "Hello World!" boot block in assembler. It creates a MemList for a task that uses the intuition.library to display a window with a boolean gadget with text... Seems to work fine with all the Amiga Forever 7.2 ROMs.

...but, my task is running while the dos.library init code is running. Now I'm trying to start the Workbench with dos.library/CreateProc(exec.library/FindResident("workbench.task") + sizeof(Resident)) (the undocumented LoadWB 1.x style, that is also working with 2.x and 3.x ROMs that include the Workbench) when the user clicks the boolean gadget instead of the close gadget. This works as long as the click/call is made after the Initial CLI has been opened. If one manages to click too early, this will raise an alert - which seems to be caused by using a half-initialized dos.library.

I already tried to wait until the "exec.task" can no longer be found (dos.library/RT_INIT seems to call exec.library/RemTask(NULL) at the end). But this also does not work / still seems to be too early.

1) Is there a safe way to detect if dos.library is 'ready' after RT_INIT?
2) Is there another way to run the code at the 'right' time?

--- Update 1 ---

After some research and testing, I found a quite 'reliable' workaround for 2.x/3.x ROMs. The Initial CLI process calls exec.library/InitCode() for the 'AFTERDOS' modules after the dos.library fields are more or less initialized, and before the preferences are read and the ":S/startup-sequence" is used as input. One of this modules is the "ramlib" module, which creates a process with the same name, that runs forever in a message loop. Therefore, waiting for a "ramlib" task allows to 'sync' to the dos.library initialization.

However,
a) AROS has no "ramlib" module
b) 1.x "ramlib" module does not start a "ramlib" process
c) it's still a bad idea to start the Workbench while the Initial CLI executes the startup-sequence (the user might have copied the Workbench disk files into the disk image)

--- Update 2 ---

Source code updated. Fixed non-scratchable registers save/restore (I got the MOVEM order wrong).

---

Many thanks in advance for any hints and comments,
Nico

[meynaf]

What happens if you wait until a call to OpenLibrary("dos.library") succeeds ?

[NicoDE]

Originally Posted by meynaf

What happens if you wait until a call to OpenLibrary("dos.library") succeeds ?

Already tried it (sorry, forgot to mention it). Still results in an alert if CreateProc is called right after opening the dos.library sucessfully.

I also tried using dos.library/Delay from the task (I'm not sure if this is allowed in a task), and it freezes the task. That's the reason why I assume that the dos.library is the root of the problem and not the 'workbench.task'... I have not enough experience with the Amiga development (yet ) and don't know how to debug/trace the problem in WinUAE.

[meynaf]

Have you tried to detect the presence of the initial CLI ?

[NicoDE]

Originally Posted by meynaf

Have you tried to detect the presence of the initial CLI ?

I'll give it a try tonight - but I guess that the dos.library/RT_INIT code calls start(NULL) to run the initial CLI, and that the CLI initialization code is initializing the internal dos.library structures (and therefore it might still be too early, if I only check for the presence of any CLI task in the public dos.library fields).

If there is no 'safe' way, I still could develop a LoadWB replacement and include it in the disk image (seems to be the most compatible way to go).

[meynaf]

Originally Posted by NicoDE

If there is no 'safe' way, I still could develop a LoadWB replacement and include it in the disk image (seems to be the most compatible way to go).

Why not just use loadwb ? What's the constraint that forces you to put your code in the bootblock rather than in the startup-sequence ?

[NicoDE]

Originally Posted by meynaf

Why not just use loadwb ? What's the constraint that forces you to put your code in the bootblock rather than in the startup-sequence ?

I'm just trying to get used to the way how the Amiga ROM and DOS work
It would have been nice to have all the code in the boot block, but the more I think about it, it makes more sense to develop my own LoadWB (to avoid copyright issues). The basic idea is to provide a disk image that says Hello from the boot block and includes the CLI/WB application on the disk to say Hello from the running DOS (it's easier for the user if the Workbench is running and he/she can just open the disk icon to run the HelloAmi program). Still, any background information is welcome

[Hedeon]

Wasn't it common practice to do FindResident("dos.library") to check for an initialized dos.library? Something vague rings a bell.

[Toni Wilen]

This seems to be tricky problem. For some reason dos seems to do AddLibrary("me") very early, before it is fully initialized.

Originally Posted by Hedeon

Wasn't it common practice to do FindResident("dos.library") to check for an initialized dos.library? Something vague rings a bell.

This is what boot blocks do, FindResident("dos.library") starts dos.library (if it has not been started yet) which probably is not what you want to do while dos library is still getting initialized.

[hooverphonique]

Originally Posted by NicoDE

I also tried using dos.library/Delay from the task (I'm not sure if this is allowed in a task), and it freezes the task.

If memory serves me right, in general you can't do dos-stuff from a task, it has to be a full process.

[Don_Adan]

Originally Posted by Hedeon

Wasn't it common practice to do FindResident("dos.library") to check for an initialized dos.library? Something vague rings a bell.

Yes, this is perhaps good way. If i remember right OnePlayControlProgram from Arcadia Systems is good example for correctly initialisation dos.library for similar case.

http://wt.exotica.org.uk/whdload.html

[Gorf]

Originally Posted by hooverphonique

If memory serves me right, in general you can't do dos-stuff from a task, it has to be a full process.

There is a workaround:

http://aminet.net/package/dev/misc/ExtFuncProc

"Allows execution of any library function from
simple tasks even if these functions require a process environment."

[NicoDE]

Originally Posted by Hedeon

Wasn't it common practice to do FindResident("dos.library") to check for an initialized dos.library? Something vague rings a bell.

I'm doing this right in the beginning (when the dos.library is not yet initialized).

Originally Posted by Don_Adan

Yes, this is perhaps good way. If i remember right OnePlayControlProgram from Arcadia Systems is good example for correctly initialisation dos.library for similar case.

http://wt.exotica.org.uk/whdload.html

I never used WHDLoad and don't know how to get any information out of the two binary files

Originally Posted by Gorf

There is a workaround:

http://aminet.net/package/dev/misc/ExtFuncProc

"Allows execution of any library function from
simple tasks even if these functions require a process environment."

Thanks, I'll have a look at it.

---

After some research and testing, I found a quite 'reliable' workaround for 2.x/3.x ROMs. The Initial CLI process calls exec.library/InitCode() for the 'AFTERDOS' modules after the dos.library fields are more or less initialized, and before the preferences are read and the ":S/startup-sequence" is used as input. One of this modules is the "ramlib" module, which creates a process with the same name, that runs forever in a message loop. Therefore, waiting for a "ramlib" task allows to 'sync' to the dos.library initialization.

However,
a) AROS has no "ramlib" module
b) 1.x "ramlib" module does not start a "ramlib" process
c) it's still a bad idea to start the Workbench while the Initial CLI executes the startup-sequence (the user might have copied the Workbench disk files into the disk image)

So I'll abandon the idea of running the Workbench from the boot block, and will develop my own LoadWB.

I updated the attached source code in the initial post.