Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load  (Read 1579 times)

0 Members and 1 Guest are viewing this topic.

Offline blakespot

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:



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.

Quote
;;;;;;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:

Quote
;;;;;;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:





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
« Last Edit: March 29, 2021, 11:26:23 PM by blakespot »
:: ByteCellar.com - The Vintage Computing Weblog
:: Amigas: 1000, 2000 '020, SAM440ep-Flex
 

Offline Pat the Cat

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #1 on: March 30, 2021, 12:32:26 AM »
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?
« Last Edit: March 30, 2021, 01:05:02 AM by Pat the Cat »
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline blakespot

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #2 on: March 30, 2021, 03:10:22 AM »
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
:: ByteCellar.com - The Vintage Computing Weblog
:: Amigas: 1000, 2000 '020, SAM440ep-Flex
 

Offline Pat the Cat

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #3 on: March 30, 2021, 03:49:32 AM »
<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.
« Last Edit: March 30, 2021, 04:31:50 AM by Pat the Cat »
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline Matt_H

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #4 on: March 30, 2021, 07:50:12 AM »
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.
 

Offline Jope

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #5 on: March 30, 2021, 07:54:25 AM »
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.
« Last Edit: March 30, 2021, 07:57:40 AM by Jope »
 

Offline blakespot

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #6 on: March 30, 2021, 03:44:43 PM »
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.
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
:: ByteCellar.com - The Vintage Computing Weblog
:: Amigas: 1000, 2000 '020, SAM440ep-Flex
 

Offline blakespot

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #7 on: March 30, 2021, 04:13:57 PM »
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
:: ByteCellar.com - The Vintage Computing Weblog
:: Amigas: 1000, 2000 '020, SAM440ep-Flex
 

Offline Joloo

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #8 on: March 30, 2021, 05:31:39 PM »
"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
 
The following users thanked this post: Pat the Cat

Offline blakespot

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #9 on: March 31, 2021, 12:04:14 AM »
"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
:: ByteCellar.com - The Vintage Computing Weblog
:: Amigas: 1000, 2000 '020, SAM440ep-Flex
 

Offline Pat the Cat

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #10 on: March 31, 2021, 05:18:31 AM »
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
« Last Edit: March 31, 2021, 05:32:29 AM by Pat the Cat »
"To recurse is human. To iterate, divine."

A1200, Vanilla, Surf Squirrel, SD Card, KS 3.0/3.z, PCMCIA dev
A500, Vanilla, A570, Rev 5, KS 1.2/1.3 Testbench system
Rasp Pi, UAE4ARM, 3D laser scanner, experimental, hoping for AmigaOS4Arm, based on Watterott Fabscan Pi
 

Offline Matt_H

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #11 on: March 31, 2021, 07:01:09 AM »
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)
 

Offline blakespot

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #12 on: March 31, 2021, 03:12:19 PM »
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
:: ByteCellar.com - The Vintage Computing Weblog
:: Amigas: 1000, 2000 '020, SAM440ep-Flex
 

Offline Joloo

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #13 on: March 31, 2021, 05:09:59 PM »
"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
 
The following users thanked this post: Pat the Cat

Offline blakespot

Re: WB 1.3 Startup-Sequence issue - boot CLI not closing w/ app load
« Reply #14 on: March 31, 2021, 07:03:59 PM »
"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
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
« Last Edit: March 31, 2021, 07:24:35 PM by blakespot »
:: ByteCellar.com - The Vintage Computing Weblog
:: Amigas: 1000, 2000 '020, SAM440ep-Flex