CloseWorkBench behavior depends on Kickstart

[remz]

Hello Amiga coders,

I am having a bit of difficulty with CloseWorkBench.
My goal is to call it at startup when the game is booted from its startup-sequence only: with this I aim to be freeing up as much memory as possible.

On KS 1.3, it works perfectly. It returns 1, and the chip memory is freed.
On KS 2.04, it behaves strangely: From what I understand, KS 2.04 appears to delay the opening of the workbench screen in order to prevent showing it for games booting directly from floppy.
This means CloseWorkBench returns 0. However, if I keep repeating this call for approximately 38 frames, it eventually succeeds and returns 1!
To my understanding, this means that the Workbench eventually decided to open its screen.

On KS 3.1, CloseWorkBench always returns 0, so I assume they changed the logic and the workbench never opens.

Would you have suggestion on how I could handle this the best way possible? My current code is to attempt up to 255 times to CloseWorkBench:
It works well on KS 1.3 and 2.04; but on KS 3.1, it creates an undesirable and useless pause of about 5 seconds.

[Thomas Richter]

Under 2.0 and up, the workbench will simply not open if you boot from the startup-sequence, all provided you install the default 2.0 bootblock. Thus, there is no need to close it in first place. If, however, you or some other program in the startup-sequence prints something to the console, both the console and the workbench will open and - unless you run your program in the background and the system boots to the workbench. If a (non-workbench) window is open on the workbench screen, it cannot be closed.

In general, you cannot depend on CloseWorkBench() to succeed, either if the workbench screen is locked, or some windows are open on it. Thus, you cannot really depend on it. The best you can do is to call it, continue to run your program, and in worst case print a message that there is not sufficient memory available.

[remz]

Thank you Thomas, that is very insighful!

I didn't know about this "default 2.0 bootblock": Would this bootblock work on KS 1.2/1.3 too?

In my case I wanted to rely on CloseWorkBench because I only invoke it if the game was loaded thru its startup-sequence.
If a user installs it on a HD, then it won't be invoked. And since it is my startup I can relatively safely assume no window or other stuff should be interfering.

My startup-sequence looks like this:

c:cd data
c:run <NIL: >NIL: Hamulet.exe closeworkbench >NIL:
c:endcli >NIL:

[Nor Bert]

Try using add21k, add36k or add44k programs to get more memory.

Use ENDRUN instead of RUN

More information
http://amigadev.elowar.com/read/ADCD.../node002B.html

[jotd]

I remember that programs that call CloseWorkbench (1.3) when the workbench didn't open often froze/crashed whdload in kickemu mode.

[remz]

Originally Posted by Nor Bert

Try using add21k, add36k or add44k programs to get more memory.

Use ENDRUN instead of RUN

More information
http://amigadev.elowar.com/read/ADCD.../node002B.html

Thank you Nor Bert, that was an interesting read. I've downloaded and tried ENDRUN, and although the command would be doing exactly what we'd expect, the results are not great. Here's what I discovered by trials:

add21k: useless in this scenario, since the workbench screen is either going to be closed anyway, or won't exist at all. Also, it causes a 'Recoverable Alert 0100 000f on KS2.04 and KS3.1, probably since the workbench screen doesn't exist.


The numbers are the amount of free memory once my game has finished loading and allocated all the memory it needs:
with endrun:
c:cd data
c:endrun Hamulet.exe
ks1.3=53320 ks2.04=8400 ks3.1=7008


with run/endcli/closeworkbench combo:
c:cd data
c:run <NIL: >NIL: Hamulet.exe closeworkbench >NIL:
c:endcli >NIL:
ks1.3=52320 ks2.04=19176 ks3.1=17678


For both ks2.04 and ks3.1, there is a sizeable difference of about 10KB which I am having a hard time explaining. Behaviour-wise, both methods load exactly the same way: no workbench screen is visible.

[Thomas Richter]

Originally Posted by remz

I didn't know about this "default 2.0 bootblock": Would this bootblock work on KS 1.2/1.3 too?

As far as I recall, yes. It only sets a hidden flag in the expansion.library which is read by the shell code.

Originally Posted by remz

c:cd data
c:run <NIL: >NIL: Hamulet.exe closeworkbench >NIL:
c:endcli >NIL:

Please remove the "C:" there. This would prevent the shell from using built-in commands, noting that "cd", "endcli" and "run" are all shell-internal in v37 and onwards.


Otherwise, this looks acceptable. Remember that it may take a while for the shell to reach the "endcli" and thus for your code to close the workbench. You do not need any "third party" programs for that.

[remz]

Originally Posted by Thomas Richter

Please remove the "C:" there. This would prevent the shell from using built-in commands, noting that "cd", "endcli" and "run" are all shell-internal in v37 and onwards.

Otherwise, this looks acceptable. Remember that it may take a while for the shell to reach the "endcli" and thus for your code to close the workbench. You do not need any "third party" programs for that.

Thank you for your suggestion: strangely, it appears to save even slightly more memory on ks2.04 and ks3.1:
ks1.3=52320 ks2.04=19648 ks3.1=18216
~500 bytes more memory. I would assume the built-in run commands is more efficient, but since in both cases these processes are gone by the time my game is ready, I don't fully understand where that memory is gone to. Perhaps it is an OS buffer of some sort.

I was prefixing my commands with C: because I thought that on KS1.3 and before, it would 'help' DOS look directly at the right place: Otherwise, it starts by looking in the current directory, fails to find 'cd', then look in c:.
In any case, per your suggestion, I've changed my startup-sequence to:
cd data
run <NIL: >NIL: Hamulet.exe closeworkbench >NIL:
endcli >NIL:
and it works fine on all the kickstarts I've tried, and I've adjusted my 'closeworkbench' loop to iterate up to 50 frames.
This seems to be the best combination to free the most memory possible on small configurations (512KB chip Amiga), for ks1.2, 1.3, 2.04, and 3.1.