Dynamic program loading in SuperBASIC

[badaman]

Can you imagine that your SuperBASIC program could show a progress bar while it is loading with LOAD or LRUN, or show the user how long it took to load this program using only SuperBASIC, without needing any extension? These are some of the things that we can achieve with the method that I explain here.

It is possible that this is already known to SuperBASIC experts, or that it has been documented before, but for me it has been quite a discovery recently, and so I share it.

You can see how it's done here

https://retrowiki.es/viewtopic.php?f=98&t=200040477

and here

https://sinclairqles.wordpress.com/2024 ... uperbasic/

In both links the text is in Spanish, but you can use an automatic translator.

This method goes a long way if you use your imagination and dynamically shows us information that the user of our SuperBASIC programs will appreciate, especially if the loading time is long.

Showing progress in loading, information about requirements or even usage tricks will help keep the user interested in the program and make the loading more bearable.

But it is important to mention that this will only work with program listings in SuperBASIC, since compiled programs They do not give us this possibility.

[BSJR]

Can you imagine that your SuperBASIC program could show a progress bar while it is loading with LOAD or LRUN, or show the user how long it took to load this program using only SuperBASIC, without needing any extension? These are some of the things that we can achieve with the method that I explain here.

I have not yet read your links but in general there are two way to show progress.

1. In the case of a Basic LOAD, it's a closed process so you can start a seperate module to show something is happening and stop it when done, like a turning clock or repeated moving item, as W$ often does.

2. When a Loading process can be split into sections, it's possible to make assumptions on the total number of steps and the steps done sofar. Despite the extra processing time involved, seeing the progress makes the waiting seem shorter.
In SuQcess Basic the database is read into an array one record at the time so with each record progress can be checked and the bar window filled further. When I wrote this my SGC was the fastest platform I had and loading a database took long enough to justify the progress bar.

Getting any reliable timing of the whole process is more difficult with the very different QL systems around and even W$ often gives very unreliable timing numbers.

BSJR

[badaman]

Interesting what you say.

What I explain in the link is something else, and is only used for loading programs in SuperBASIC. It is easy to calculate the charging progress. If a program has 100 lines, and we want to show the progress of the load every 10%, it is enough to put a PRINT instruction every 10 lines indicating 10%, 20%...

[RWAP]

That is indeed a very interesting finding - I had not realised that lines without line numbers are executed as soon as the loading process reaches that line.

The discussion on the Spanish forums is well worth a read and the uploaded video shows it in action:

https://www.youtube.com/watch?v=Ppv3Ued5jxM

[dilwyn]

I suppose it depends on not adding too many "progress" lines in between lines of SuperBASIC so as not to have too much effect on loading times.

[badaman]

I suppose it depends on not adding too many "progress" lines in between lines of SuperBASIC so as not to have too much effect on loading times.

Correct. It is "useful" for programs with many lines, where the loading time is long, or, for example, when reading _bas files from a microdrive. For short programs it is not necessary, as it is enough to type "Loading..." and wait a few seconds. In those long programs, executing about 10 or more interleaved lines does not make much difference in the loading time, but, as #BSJR said, it makes a difference for the user.

[badaman]

That is indeed a very interesting finding - I had not realised that lines without line numbers are executed as soon as the loading process reaches that line.

The discussion on the Spanish forums is well worth a read and the uploaded video shows it in action:

https://www.youtube.com/watch?v=Ppv3Ued5jxM

For me it was an unexpected discovery, although the clues were there, when using complete programs without line numbers in the BOOT files or when using the DO instruction in TK2, we did not see them.

[Derek_Stewart]

Hi

Great idea, just need this added to part of the QL ROM, or assembler extension.

so that no extra programming lines have to be added.

[badaman]

Hi

Great idea, just need this added to part of the QL ROM, or assembler extension.

so that no extra programming lines have to be added.

Are you talking about implementing a routine in the system that shows, by default, a load percentage for the programs?

How would it be?

[RWAP]

As the QL does not know the number of lines in the listing until it is fully loaded using a similar mechanism could not be programmed too easily.

However, a ROM routine could be incorporated within the LOAD routine to calculate the % loaded based on the byte size of the program / bytes loaded.

The only other option would be to have a generic machine code procedure to display the loading, and you still add the extra lines to the program, but calling that specific procedure.

The main issue is that the progress loading lines have to be added by manually editing the saved program - so the easiest might be to develop a variant of the SAVE routine to insert them automatically (as that can work out the total number of lines and where to insert the progress loading lines).