The Sinclair QL Forum

bwinkel67 wrote: Sun Jan 19, 2025 9:27 pm So this question is not directed at the BASIC code here but just a general one. I'm surprised this hadn't ever been addressed by any of those Sinclair QL World Simon Goodwin DIY code bits, or by the many add-on toolkits that someone wrote. Really LRUN, EXEC, and EXEC_W ought to set some system variable that could be checked (similar to ver$, maybe called dev$) to see which device a program was loaded or executed from,

That would be the perfect and the best solution, 30 years ago. Completely agree.
But it was not done, so this that I have share solve partially the problem. Another way is a keylogger and the logic to extract the last unit referenced. What also gives an extra beneficts of recall last N commands executed or typed.
Now, Let's imagine that it is done what was not 30 or 40 years ago (1984). To change the QDOS implies that those software that will use this var will be used only for people with the new ROM version. Because is using a var that doesn't exist before. The main part of new users as I am, won't be able to use it. Or people who don't want to change their ROMs or open their QLs due to lack of skills.
So this one can solve the problem, not the best way, that's true. What you have exposed is how it should have be done. Still a solution.

bwinkel67 wrote: Sun Jan 19, 2025 9:27 pm otherwise it's easy enough to add a one-liner: INPUT #0, "Device? ";dev$

I don't know that, what does this code do?
Remember that I am new and my skills with basic are not too high

Derek_Stewart wrote: Sun Jan 19, 2025 9:34 pm Personally, I will stick to using Toolkit 2 data and program defaults and PTH for path searching.

And that is a nice option.
I don't know how TKII can manage it, but I would love to know because that is very useful.
Path is something common. One reason why it is used is what I have described and the cost of searching in the tree of the file structure. The cost is too high even using heuristics algorithm. good for few files but the rest... not good idea. That is why the Path give you a direct reference (well to say to your program) to find the rest. In fact you can think about the path like a similar concept to what I have done here with unit$ var and how it is used when programming.

Derek_Stewart wrote: Sun Jan 19, 2025 9:34 pm You coukd have a search path of MDV1 to MDV8, so do not really need to know the location of the program. But this is a personally opinion on how I set a QL environment.

In fact... this demo code is what try to do. But requires nothing and you can run it in QLs that has not TKII. Not even loading it with your program because it takes more memory that an stock QL could have.
Let's imagine to load it with only 128KB of RAM on your QL, using original ROMs, and then load QUILL or something "heavy" and try to load also from your Microdrive (same one) the TKII. Too much for so little capacity. Note, no idea if QUILL requires a lot or not, it is just an example.

Derek_Stewart wrote: Sun Jan 19, 2025 9:34 pm I the flexibilty, of being able customise the way the system is setup otherwise we end with a Windows, Linux or MAC system.

That is nice, the focus here is not how each user customize his system but giving a way to load a new software (in some cases old software) from different unit. I code a program to run from MDV1, but your MDV1 is faulty so you won't be able to run it from your MDV2 or any other place. With this algorithm or the use of the method it won't be a problem at all.

Derek_Stewart wrote: Sun Jan 19, 2025 9:34 pm I only use Minerva or SMSQ/E anything else does allow multitasking Basic.

This is a naive question but since I have no idea... is there any ROM that is not multitasking for QL?.
It is interesting because perhaps I will implement some multitasking parts of the demo and If there is a ROM or QL that is not multitasking, then won't be useful for me.

Hi Popopo

The effort in getting stuff to work on different media or from different locations is frustrating.
It's a problem worth fixing and I'm impressed by your efforts.

I mentioned that I have also been looking at the same issue recently.
It looks like we hit the problem from different angles.

Mine was an attempt to create a short cut down version of HOME_DIR$ that can return the boot device. This could be used as a way to load a fuller version of HOME_DIR$ or to load other extensions from the boot drive.

My proof of concept is below.
It's influenced by the many programs without line numbers and by the the Unzip_bas and Job2Bas programs.
Its a program that relies on having no line numbers.
Save it to any drive. When it is loaded it should print that drive name to screen.
The code could be appended to an existing boot program.

Please note that HOMED_POC$ is a temporary name that I have named the function while it's in proof of concept.
The code is not yet complete.

For example, the value of HOMED_POC$ is only currently available while the file is being loaded.
This is because it interrogates the BASICs command channel which contains a file channel during a LOAD or MERGE.
I will need to store its value in a persistent location so that it's available to other programs after the LOAD is complete.
I'll probably use a THING.

Mark

Popopo wrote: Sun Jan 19, 2025 10:08 pm

bwinkel67 wrote: Sun Jan 19, 2025 9:27 pm otherwise it's easy enough to add a one-liner: INPUT #0, "Device? ";dev$

I don't know that, what does this code do?
Remember that I am new and my skills with basic are not too high

Give it a try. It just prints "Device? " in your console window and awaits for you to type "mdv1_" or "flp1_" or whatever (obviously the quotes only used to highlight things here and aren't actually typed).

Mark Swift wrote: Sun Jan 19, 2025 10:23 pm <>

Code: Select all

REMark --- Install the BASIC extension 'HOMED_POC$' ---
F$=HOMED_POC$
IF F$="" THEN R=RESPR(180):P=R
<>

<>

Nice thinking, Mark, but that particular strategy wont work in SuperBASIC. SuperBASIC errors on unset variables. SBASIC doesnt, and I forget about MBASIC.

Popopo wrote: Sun Jan 19, 2025 10:20 pm

Derek_Stewart wrote: Sun Jan 19, 2025 9:34 pm I only use Minerva or SMSQ/E anything else does allow multitasking Basic.

This is a naive question but since I have no idea... is there any ROM that is not multitasking for QL?.
It is interesting because perhaps I will implement some multitasking parts of the demo and If there is a ROM or QL that is not multitasking, then won't be useful for me.

In QDOS, SuperBASIC can't multitask, you only have one instance. In other ROMs you could have multiple non-compiled SuperBASIC programs running.

bwinkel67 wrote: Sun Jan 19, 2025 10:37 pm
Give it a try. It just prints "Device? " in your console window and awaits for you to type "mdv1_" or "flp1_" or whatever (obviously the quotes only used to highlight things here and aren't actually typed).

Ah! OK... hehehe lack of enough sleep.
I was thinking it returns a sys var.

bwinkel67 wrote: Sun Jan 19, 2025 10:44 pm In QDOS, SuperBASIC can't multitask, you only have one instance. In other ROMs you could have multiple non-compiled SuperBASIC programs running.

Hum...
So I need to figure out what to use in order to avoid multitasking.

How do you check in basic that a var exist?
I mean, when I print a non declaraed var, it write in the screen the asterisk symbol '*'
In C or others languages I get null.
But in basic in QL, what I get in return? in order to detect an existing previous var as a parameter and if it is not declared before running the program, take the default inner value.

Example,
IF CTOKEN <> * THEN GO TO N
it is not a valid line (of course), but also I cannot compare it with a number (ie 0) when it is not declared before the IF.

I am open to pass a parameter in a more elegant way if there is.

So the main question here is "from what path was the program started"
I think that popopo's idea has a lot of drawbacks and tofro summarized them very well, but some of them could be fixed in future versions. So Popopo, continue to develop your idea and by doing this you will also learn SuperBasic.
However, I feel that as soon as we take into acount win drives (QL-SD, QUBIDE) with sizes of 100-200Mb and tenth or hundreds of directories, the algorithm will soon become painfully slow in finding a token.

What other options do we have today?

1. Home_Thing: works only in SMSQ/E, both in SBasic and compiled programs. It would be nice to have a working Home _Thing for QDOS

2. For Basic programs we can use the old way: just have this as the first line in your program: Thus you can easily change it when you install the program on a drive and/or directory.

3. For basic and compiled programs: Use a line like this: The user will have to enter the full path. It's annoying, but it works.

4. For compiled programs: use Execute parameters.
Turbo has OPTION_CMD$, QLiberator has CMD$
Then all we have to do is start the program with: 5. For compiled programs: use Config Blocks
(Popopo, you can read about Level 1 and Level 2 config blocks here: https://dilwyn.theqlforum.com/docs/asm/index.html )

In my opinion the best thing for QL world is to have some standardisation across all the platforms.
Config Blocks and Execute Parameters are useful in many other ways, not only to get the program's directory.
So the best thing would be to also have a Home_Thing for QDOS.