Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: blakespot on March 29, 2021, 11:24:42 PM
-
I have an Amiga 1000 w/ a Parceiro device (8MB FAST RAM, RTC, SD card volume named "SD:"). I boot with a floppy that gets things loading, handing everything off to a script on the SD: drive (script = "StartupII"). It's been fine, but I wanted to load the FAST/CHIP/CLOCK prog "mclk" at boot (the orig, older version written for 1.3). A guy on FB is loading it in his S-S just fine and it works great. I hit a problem, though (and we are using the same version; he sent the file to me directly).
For me, the program loads and is visible, and WB loads, but the startup CLI does not close. It just sits there until I close mclk, then the CLI closes and it's to off to WB.
This is what it looks like, when it hold and just sits there:
(https://blakespot.com/files/mclk_stuck_th.jpg)
I am posting a listing of both df0:s/Startup-Sequence and sd:s/StartupII below. I hope someone who'se more savvy w/ AmigaDOS than I can find the reason this little program is holding up the works on boot.
;;;;;;Filename: df0:s/Startup-Sequence
mount sd0: ;mounting SD card volume in Parceiro device
sd0:c/assign c: sd0:c
resident c:assign
assign sys: sd0:
assign libs: sd0:libs
assign devs: sd0:devs
assign fonts: sd0:fonts
assign l: sd0:l
assign s: sd0:s
Sys:System/FastMemFirst
RTC LOAD ;get datetime from Parceiro clock
Date
c:SetPatch >NIL: ;patch system functions
Addbuffers df0: 45
Addbuffers df1: 45
cd c:
echo "Amiga Workbench Disk. Release 1.3.3 version 34.34"
BindDrivers
FF >NIL: -0 ;speed up Text
resident CLI L:Shell-Seg SYSTEM pure add; activate Shell
resident c:Execute pure
mount newcon:
failat 11
run execute s:StartupII ;This lets resident be used for rest of script
wait >NIL: 5 mins ;wait for StartupII to complete (will signal when done)
path ram: c: sys:system s: sys:prefs add ;set path for Workbench
LoadWB delay ;wait for inhibit to end before continuing
endcli >NIL:
;;;;;;Filename: SD:s/StartupII
echo "StartupII - start"
resident c:Resident pure
resident c:List pure ;pre-load LIST and CD
resident c:CD pure
resident c:Mount pure ;the next 3 are loaded for speed during startup
resident c:Assign pure
resident c:Makedir pure
;make IF, ENDIF, ELSE, SKIP, ENDSKIP, and ECHO resident if
;you use scripts much, and can afford the ram.
;also make Failat, WAIT, and ENDCLI resident if you use IconX a lot
makedir ram:t
assign T: ram:t ;set up T: directory for scripts
makedir ram:env ; set up ENV: directory
assign ENV: ram:env
makedir ram:clipboards ;set up CLIPS: assign
assign CLIPS: ram:clipboards
mount speak: ;just mounting doesn't take much ram at all
mount aux:
mount pipe:
;resident Mount remove ;if you have enough ram, keep these resident
;resident Assign remove ;by removing these lines
;resident Makedir remove
;
run >NIL: mclk ; *** THIS is what's holding up boot CLI from ending
echo "StartupII - end"
break 1 C ;signal to other process its ok to finish
Now, note that the guy who set this up, David Dunklee who makes the Parceiro, is using LoadWB w/ "delay" attrib and is sending a "Break 1 C" in the script called from within the S-S. I tried removing these, simplifying. When I do, the same thing happens, but I noticed if I happen to hit CTRL-C while it's sitting there with mclk loaded and the boot CLI not closed, the system will GURU. Not so, as listed above -- for what that's worth.
The mclk program I am using is located here:
https://blakespot.com/files/orig_mclk.zip
For some reason, the guy on FB has it loading fine, but not me. These are his scripts, he showed me:
(https://blakespot.com/files/mclk_s-s_works.jpg)
(https://blakespot.com/files/mclk_u-s_works.jpg)
Any ideas would be greatly appreciated. OR, if there is an alternative to mclk that works on 1.3 and will show CHIP/FAST (clock not important), that might not have this issue, I'd be happy to hear what it is. I'm not married to mclk but can't find alternatives and I definitely want it auto-loading at boot.
Thanks!
bp
-
EDIT: The other person isn't using RUN EXECUTE, just EXECUTE...
startii won't finish until LoadWB has ended (Workbench has been closed). Don't bother waiting, just endcli after you've executed startupii.
An alternative to mclk is to use the AVAIL command somewhere to print available memory.
EDIT EDIT;
RUN MCLK >nil:
Different from
RUN >NIL: MCLK
The program you are trying to run has to be immediately after the RUN. On 1.3 anyway.
Am baffled why you are using the >NIL: Isn't the whole point that you want to see the output printed rather than suppressed?
-
I tried all the modifications you suggest, to no avail. Nothing changed.
As far as AVAIL, I'm looking for a real-time readout, which is the point of the app vs running AVAIL in CLI, right?
There is no CLI output, just a window display, which is why >NIL: isn't affecting my seeing the output -- nothing goes to the command line.
Thanks for the suggestions, though. I hope to eventually get this solved.
bp
-
<scratches head>
Well... you definitely need an endcli at the end of startupii. After the Break command. I wouldn't bother with the Break there an failat in startup-sequence. Or the Wait. I guess the Wait does help you read any messages though,.
You have a DELAY option on the LoadWB after the 5 minute timer in your startup-sequence, if a sub process hasn't ended, that might cause it?
I always just use LoadWB without any options.
It's a good idea to click on the "Window to back" icons to see if Workbench has actually loaded behind the opening Amiga Dos screen.
And it's a very good idea to leave out the >NIL: flags to dump the output on commands when debugging a startup sequence. It might be printing an error code, which can help you find causes to problems.
-
I don’t have a direct solution to this issue, but I do have a workaround. DOpus 4.11 (and older) is 1.3 compatible and produces an identical memory/clock window when iconified. Plus it comes with DOpus :).
You might also want to look at alu (http://aminet.net/package/util/batch/alu).
-
Did you also try:
run >NIL: <NIL: mclk
This could help detach it from the CLI.
Another option to try, move it to your s:startup-sequence from startupII in case the problem is that it is started from a shell instead of the initial CLI.
The reason StartupII exists is not because it is a "user-startup" style thing, but so that resident and other shell-seg provided services can be used in the 1.3 startup-sequence to speed up execution.
-
I don’t have a direct solution to this issue, but I do have a workaround. DOpus 4.11 (and older) is 1.3 compatible and produces an identical memory/clock window when iconified. Plus it comes with DOpus :).
You might also want to look at alu (http://aminet.net/package/util/batch/alu).
Yea, but I feel like leaving DOpus running (even "idle" as iconified) on an unaccelerated A1000 (even w/ 8MB FAST) is kind of "much."
I will look at alu, thanks.
bp
-
Did you also try:
run >NIL: <NIL: mclk
This could help detach it from the CLI.
Another option to try, move it to your s:startup-sequence from startupII in case the problem is that it is started from a shell instead of the initial CLI.
The reason StartupII exists is not because it is a "user-startup" style thing, but so that resident and other shell-seg provided services can be used in the 1.3 startup-sequence to speed up execution.
Ok, I moved the command from StartupII to S-S, one line before "LoadWB delay" and there's no change.
I also tried the "run >NIL: <NIL: milk" in that spot, no change. Is it about mclk, or the way it's being called?
Thanks.
bp
-
"mclk" was written using the MANX compiler and the used startup-code operates with the genuine input and output handles (no redirection possible) so that the underlying CLI cannot be closed once "mclk" was fired up.
Fortunately, the used startup-code by "mclk" offers to start it via Workbench (one may create a tool icon for it), so instead of "Run >NIL: <NIL: mclk" one may use either "WBRun mclk" or "alu WB mclk" from inside of a CLI environment, which allows to shut down this environment afterwards.
Hi Matt_H,
If I am right you state that there is a tool called "WBRun", right? :-)
@blakespot
I don't know how "WBRun" really has to be invoked, so if you want to launch "mclk" using "WBRun" please read "WBRun's" manual first.
For "alu" is important to turn on the "WB" switch, otherwise "mclk" gets executed like an ordinary CLI command.
Regards
-
"mclk" was written using the MANX compiler and the used startup-code operates with the genuine input and output handles (no redirection possible) so that the underlying CLI cannot be closed once "mclk" was fired up.
Fortunately, the used startup-code by "mclk" offers to start it via Workbench (one may create a tool icon for it), so instead of "Run >NIL: <NIL: mclk" one may use either "WBRun mclk" or "alu WB mclk" from inside of a CLI environment, which allows to shut down this environment afterwards.
Ok, I grabbed alu and replaced the S-S line with (after playing w/ alu's attribs a bit): alu PATH=c:mclk WB
And the same thing happens. The boot cli just sits there still open... I tried replacing WB with CLI but it makes no diff. I also tried preceeding this with 'run' in the CLI on WB but then I can't end the CLI.
Should this be working? If I do 'alu PATH=c:mclk WB" in a CLI after WB is loaded, I can't continue in WB -- it's not like I used 'run.'
I see no docs anywhere on alu, also, sadly.
bp
-
Two differences between your startup-sequence and "the other guys" - first, they are running rexxmast, which means they're likely running Workbench 2 or higher.
The other thing I noticed was that they run popcli before they try to run mclk. May or may not be how they get around the old mclk not liking detaching when it is run from a cli, as opposed to clicked on from an icon. (Which is what alu is supposed to do).
It would appear you are both using the old version of mclk... although I wonder why they are exactly? When there's mclk32 for more recent Kickstarts.
If alu doesn't help getting mclk running, perhaps WBRun can.
https://aminet.net/package/util/cli/WBRun
-
Yea, but I feel like leaving DOpus running (even "idle" as iconified) on an unaccelerated A1000 (even w/ 8MB FAST) is kind of "much."
Iconified, I think it uses negligible CPU power and RAM usage is about half a meg. That's like a drop in the ocean for an 8MB 1.3 system.
Gotta embrace the DOpus, man! 8)
-
Two differences between your startup-sequence and "the other guys" - first, they are running rexxmast, which means they're likely running Workbench 2 or higher.
The other thing I noticed was that they run popcli before they try to run mclk. May or may not be how they get around the old mclk not liking detaching when it is run from a cli, as opposed to clicked on from an icon. (Which is what alu is supposed to do).
It would appear you are both using the old version of mclk... although I wonder why they are exactly? When there's mclk32 for more recent Kickstarts.
Ahh, I thought he was under 1.3. Perhaps that's it.
There is mclk32 and mclkBB (or some such) that were written to handle > 8MB RAM properly. Neither of these will run under 1.3 for me. I asked the orig guy how he was running it (assuming he was under 1.3) and he sent me his binary -- we have the exact same, which seems to be the original, which will report negative RAM amounts for RAM levels > 8MB FAST, apparently. Not a problem for me -- I have 8MB FAST and can't add more.
I shall try WBrun. I also want to get PopCLI on the system, maybe will try that as well now, hoping it makes a diff. Thanks.
bp
-
"alu" didn't run programs as if started through Workbench when there is no icon present for the program in question; that was meant as insurance to not launch programs which weren't designed to be run from Workbench.
Turned out to be no good idea...
This "insurance" is now removed.
New version on old place, http://amimedic.de/private/alu.lha (http://amimedic.de/private/alu.lha)
-
"alu" didn't run programs as if started through Workbench when there is no icon present for the program in question; that was meant as insurance to not launch programs which weren't designed to be run from Workbench.
Turned out to be no good idea...
This "insurance" is now removed.
New version on old place, http://amimedic.de/private/alu.lha (http://amimedic.de/private/alu.lha)
Aaaand, this worked. Many thanks! Good to have this util for other such needs that will come, surely.
I notice your nick and the author's first name are the same initial; you didn't write alu, did you?
Now I need to play with mclk and see if it's possible to disable the clock on the display and chose its position when opened. (I wonder if alu can set position of what its opening?).
Thanks, again.
bp
bp
-
I notice your nick and the author's first name are the same initial; you didn't write alu, did you?
No, in case you want to complain about "alu", yes, if you say "alu" is alright. :)
Seriously, I am the author, while Matt_H is the moving spirit behind "alu".
Now I need to play with mclk and see if it's possible to disable the clock on the display and chose its position when opened.
If I am no mistaken, this isn't possible. When I visited the binary file, using a hex viewer, I couldn't spot any text that makes conclusions about customising. I am afraid all is rigid designed with no chance to personalise.
I wonder if alu can set position of what its opening?
Not for programs launched as if started through Workbench.
If "mclk" would support keywords for positioning, one may pass those keywords using the "ARGS" directive, but as said, "mclk" doesn't support it. Next, keywords for programs are only supported if programs get fired up as if typed in a CLI environment.
One the other hand, for programs launched as if started through Workbench, "alu" would have to create an icon file and place therein tool types, which the launched program can evaluate. It is possible to implement this, but I don't see the necessity for it, because a program that shall be launched by Workbench requires anyhow an icon file and then it should support tool types anyway.
"mclk" is an exception: It is a tool that can be launched by Workbench but its authors forgot to enclose an icon...
Regards
-
alu saves the day again!
@ blakespot
Joloo generously took on the task of creating it based on my issue in this thread (https://forum.amiga.org/index.php?topic=74738).
Maybe you'll want to create your own 1.3 WBStartup drawer? ;)
-
Maybe you'll want to create your own 1.3 WBStartup drawer? ;)
Do not lead me into temptation... - I could be tempted to realise this! :)
Everything for this is already there - "AltLoadWB" and "alu". The only question to be answered is: Accepts and especially frees the Workbench replied messages sent by application programs not launched through Workbench? No, no, no! I don't going to think about it, otherwise I'll again end on the hook... ;)