Sparta Commander Option To Stop Press Space Prompt

[Paul Hocker]

Apologies if this was discussed before but I am hoping that someone knows if there is an option to remove the "--- Press SPACE  when done ---" from happening everytime I do something with SC? I looked in the SC.INI file, but nothing stood out to me to control this. Perhaps it is not documented?

 

Thanks.

[_The Doctor__]

toolkit, shells, sc107.arc

might be some instructions in there after decompressing.

@drac030 is the expert, could try asking if it's you don't find your answer there.

 

[+Stephen]

I am not aware that this is possible.  But - there are built in (and configurable) viewer and editors for text files.  When using these, and exiting them, you get taken right back to the SC shell.  What are you doing that is giving you the "press space to continue" prompt?

[Paul Hocker]

It seems like anything I do in SC, after it completes asks me to press the space key. Doing a DIR command, viewing a file. Quite irritating actually. Here are some screenies.

 

Perhaps it is a Sparta setting in general?

 

First one after starting it

 

 

After viewing a file

 

 

after doing a DIR command

 

 

Thanks for the help.

[flashjazzcat]

Surely this is necessary to allow the user to see what's on the screen before the SC UI comes back up?

[Mark loves Stella]

For the first screen loading the ramdisk, edit your CONFIG.SYS file and add a (, Y) to the SCMAIN.OVL line.  Mine reads: SET SC=D1:\SCMAIN.OVL, Y

[Paul Hocker]

3 hours ago, flashjazzcat said:

Surely this is necessary to allow the user to see what's on the screen before the SC UI comes back up?

I am sure that was probably the reason but when I am done viewing a file, I really don't want to be interrupted to press a key again, right?

[Paul Hocker]

58 minutes ago, Mark loves Stella said:

For the first screen loading the ramdisk, edit your CONFIG.SYS file and add a (, Y) to the SCMAIN.OVL line.  Mine reads: SET SC=D1:\SCMAIN.OVL, Y

That cleared up the initial prompt, which is awesome, thank you. Still get that nagging press space key tho. 

 

I had mine on D5 so I had to change the SET command to this.

 

SET SC=D5:\SCMAIN.OVL, Y

 

Edited January 16, 2023 by Paul Hocker

[_The Doctor__]

I think what he's saying is, I consciously hit Q to quit etc in the viewer why must I press space now as well. That sort of thing.

[Paul Hocker]

4 minutes ago, _The Doctor__ said:

I think what he's saying is, I consciously hit Q to quit etc in the viewer why must I press space now as well. That sort of thing.

Correct.

[flashjazzcat]

1 hour ago, Paul Hocker said:

Correct.

I see. 'Press Space to Continue' is presumably there to cater (in a universal manner) for other tools which don't block on a keystroke before returning to the shell (which would be almost every command line utility written for SpartaDOS). I am not sure how SC could divine whether a given tool immediately returns to DOS or not.

[_The Doctor__]

they would have to be aware of each other and then either close sending a space or not ask for the space bar based on that switch or detection. I have not set my stuff up after all the goings on so I can't truly look at it. I don't do emu except for simple things.

SD already has form of identification for version etc. it's not that it isn't possible.

Maybe the simpler idea of just a switch of some kind would suffice, not sure.

Edited January 16, 2023 by _The Doctor__

[flashjazzcat]

It's easy enough for a program to discern whether it's running under SpartaDOS, and thus whether it was launched from a command-line or menu-based DOS. RWTEST is a good example: when launched from a DOS other than Sparta/SDX, it presents a 'press any key to continue' prompt after presenting the benchmark results. The only way I can get RWTEST to not present that prompt under my FATFMS DOS, for example, is to spoof the SpartaDOS ID and version bytes at $70x, although this can have unwelcome side-effects if the program then thinks it can call the SDX kernel, etc.

 

The SC viewer is a special case in as much as it uses the 'LESS' viewer, which is a self-contained, interactive tool which blocks regardless of whether it was launched from a shell or command line. Since the behaviour of LESS is known, I suppose SC could quite legitimately bypass the 'Press space' prompt after running it, although for all I know, the author's intention might be that the 'stock' file viewer could be supplanted by a different tool with undetermined behaviour.

[Paul Hocker]

3 hours ago, flashjazzcat said:

It's easy enough for a program to discern whether it's running under SpartaDOS, and thus whether it was launched from a command-line or menu-based DOS. RWTEST is a good example: when launched from a DOS other than Sparta/SDX, it presents a 'press any key to continue' prompt after presenting the benchmark results. The only way I can get RWTEST to not present that prompt under my FATFMS DOS, for example, is to spoof the SpartaDOS ID and version bytes at $70x, although this can have unwelcome side-effects if the program then thinks it can call the SDX kernel, etc.

 

The SC viewer is a special case in as much as it uses the 'LESS' viewer, which is a self-contained, interactive tool which blocks regardless of whether it was launched from a shell or command line. Since the behaviour of LESS is known, I suppose SC could quite legitimately bypass the 'Press space' prompt after running it, although for all I know, the author's intention might be that the 'stock' file viewer could be supplanted by a different tool with undetermined behaviour.

Don't get me wrong. This is a "minor" inconvenience at best. I just felt it was strange that it did this and could not detemine if it was SDX, SC or a combination of the two. Either way, there is no option I can see to supress it. I appreciate eveyones input on this. I certainly cannot be the only person who has noticed this, or maybe many folks just don't use SC?

 

Happy belated New Year everyone!

 

[_The Doctor__]

many people are silent on the forums, they often feel it's best to be quiet and listen. Don't want to complain, look like a newb, or get a tongue lashing.

 

Windows or late DOS days used to be full of it,  DO this... y/n... are you sure... y/n... doing this could cause blah blah blah... do it anyway y/n... ok press any key to continue you can't undo this.

 

 

[drac030]

On 1/15/2023 at 5:40 PM, Paul Hocker said:

Apologies if this was discussed before but I am hoping that someone knows if there is an option to remove the "--- Press SPACE  when done ---" from happening everytime I do something with SC? I looked in the SC.INI file, but nothing stood out to me to control this. Perhaps it is not documented?

There is no such option. SC displays the prompt you are talking about when, while reloading the SC after a program's termination, the cursor is not in the HOME position (i.e. when the cursor's X position is different than LMARGN, or the cursor's Y position is not 0). This means that the program has displayed something and SC makes it possible for the user to read (as already pointed out). Otherwise - when the cursor is in the HOME position - the SC goes on to display its panels immediately without holding the screen.

 

The VIEW function uses LESS.COM by default. This one - and also XLESS, which can be used instead - block the screen when the file to be displayed does not entirely fit on the screen (i.e. has more than 22 lines, IIRC). Otherwise - when the text is short and does fit on the screen - both viewers do not hold the screen and return immediately to the shell.

 

The SC has no way to know, if the screen was being held by the viewer while displaying the file, thus, when the viewer exits, the SC behaves as described above, i.e. holds the screen when the cursor is not in the HOME position etc.

 

On 1/16/2023 at 8:33 PM, flashjazzcat said:

The only way I can get RWTEST to not present that prompt under my FATFMS DOS, for example, is to spoof the SpartaDOS ID and version bytes at $70x, although this can have unwelcome side-effects if the program then thinks it can call the SDX kernel, etc.

Oups. Indeed. I will have to fix that.

[drac030]

On 1/16/2023 at 8:33 PM, flashjazzcat said:

The only way I can get RWTEST to not present that prompt under my FATFMS DOS, for example, is to spoof the SpartaDOS ID and version bytes at $70x, although this can have unwelcome side-effects if the program then thinks it can call the SDX kernel, etc.

Fixed, I think.

rwtest.co_

[flashjazzcat]

46 minutes ago, drac030 said:

Fixed, I think.

Fantastic - thanks!

 

Does this depend on any particular DOS ID, or is it generating the prompt only when a specific non-CLI DOS is sensed?

 

I noticed a while ago that another useful tool - RWCRC - can't be 'spoofed' with SD ID bytes, since when it senses them, it calls the kernel (for formatted numeric output?), and quite understandably crashes. If the same change can be made there, it would be most welcome.

Edited February 5, 2023 by flashjazzcat

[drac030]

It depends on the OSS CLI interface having been detected or not.

 

On 2/5/2023 at 10:38 PM, flashjazzcat said:

RWCRC - can't be 'spoofed' with SD ID bytes, since when it senses them, it calls the kernel (for formatted numeric output?), and quite understandably crashes

If it crashes, this cannot be the cause, because I cannot see the program making any SDX-specific calls under any circumstances. Besides, you can always "spoof" SpartaDOS 3.

rwcrc.co_

[flashjazzcat]

9 hours ago, drac030 said:

It depends on the OSS CLI interface having been detected or not.

Ah - thanks!

9 hours ago, drac030 said:

If it crashes, this cannot be the cause, because I cannot see the program making any SDX-specific calls under any circumstances. Besides, you can always "spoof" SpartaDOS 3.

Which is exactly what I did (spoof SpartaDOS 3), but although this worked with RWTEST, RWCRC (now that I actually look properly into it with the Altirra debugger) spins endlessly looking for $9B at the end of the arg buffer (which corresponds to the 28-byte COMFNAM buffer in Sparta), since I happened to terminate the string with $00 instead. I guess I should change this for compatibility reasons.

 

Thanks so much for the amended RWCRC, anyway. It works perfectly without the Sparta 3.x spoofing.

Now I suppose I should address the issue of such tools, when launched directly from the SIDE3 loader, returning immediately to the loader without waiting for a keystroke (by obfuscating the OSS CLI interface, I suppose, at least until such time as the loader is capable of passing parameters directly to the launched application via said CLI interface).