Compiling a SuperBasic program

[Peter]

I wonder a little bit how all this information will help to answer Popopos question how to compile a S*Basic program?

Sorry Stephan. It was my intention quickly to remind of the QLiberator 68040/68060 issue, but had not expected a comprehensive discussion here. I hope Popopo won't mind that I used his thread - it is really important for the possibility of a new 68060 machine. I plead guilty, but I have seen other forum threads going off topic far worse. At least the issue is related to compiling SuperBasic.

[bwinkel67]

I downloaded the zips you linked but wouldn't loaded as disk images. I could mount it as directories in QEmulator I guess. But not sure if it will work. Trying it later.

Follow up from my earlier post that gave you a video of how to run SuperCharge. I wasn't home at the time so I couldn't get to my QL. Here is an MDV that I used, which works with vDrive and (unregistered) Q-emuLator. It's been customized by me to ask for which device for each BASIC program that's used. Makes using it a lot simpler -- same way my QLAmiga Workbench demo worked if you recall.

CHARGE.zip

(65.76 KiB) Downloaded 35 times

Here are the steps you take to compile a BASIC program. This works for me on a BBQL with 128K memory, so it's very compatible:

Step 1: First you must install the SuperCharge toolkit. You do this by typing the following (which assumes that you are running from device mdv2_) and when it asks Device? you simply put in that device you are running from (i.e. mdv2_ in this example):

lrun mdv2_BOOT

Step 2: Load your BASIC program (let's assume here you have it stored on mdv1_). You can run to test it, etc:

load mdv1_myProgram_bas

Step 3: Start the compiler (using its toolkit's merge command). Here again it will ask Device?, for which you put mdv2_ again.

merge mdv2_SUPERCHARGE

Step 4: Answer the questions it asks a) name of compiled program (don't save it on mdv2_ since that cartridge is almost full), b) compilation listing (I hit N), c) report file (I hit enter) d) pause after report (I hit Y).

SuperCharge now compiles your program, in four passes. It's pretty quick, and if you don't have any BASIC errors, it's pretty simple to use. You can give a report file which will list each error (part c above, where I hit return, you can give it a file).

[Popopo]

1. Load Turbo Toolkit: LRESPR flp1_turbo_tk_cde
2. Set the default drive to the device and directory where your turbo compiler is: DEFAULT_DEVICE flp1_turbo_
3. Load your S*BASIC Program: LOAD flp1_compileme_bas
4. compile it: CHARGE
5. Run it (depends on how you named it in the window before under OBJECT): EX flp1_test_task

Done.

That assumes you have downloaded Turbo Toolkit and placed it as flp1_turbo_tk_cde, then
downloaded the Turbo compiler and put the two _task files in there into flp1_Turbo_

Hi,
Trying to execute: LRESPR mdv1_turbo_tk.code
I get a error message: bad line. And doesn't continue the process.
I go to read the rest of the post in order to check any extra info about it.

Just I case, I recall that I have only QEmulator free version, that only allows 384KB RAM, and loading MDV images or Directories or QDos Floppy Disk (A or B)

edit: mdv1_turbo_tk.code didn't work due to dot char. QL doesn't like (if I am not wrong that char). Changed for underscore '_' char and that parted was fine.
After many tries I couldn't run the main compilator, so Andrei helped me with a MDV image ready for the work, and it worked perfectly.

But now, I am curious... why other images and processes didn't work? but also interested about to test the other compilators and suggestions. The code is now much faster, very much faster but still too slow. It just write and read what was wrote (first pattern 1s) the screen memory zone. few KBs, I cannot imagine if I try to check 640KB with 4 patterns (0s,1s, 01s and 10s).

Tomorrow I will read the rest of the messages posted and practice a little more

[tofro]

1. Load Turbo Toolkit: LRESPR flp1_turbo_tk_cde
2. Set the default drive to the device and directory where your turbo compiler is: DEFAULT_DEVICE flp1_turbo_
3. Load your S*BASIC Program: LOAD flp1_compileme_bas
4. compile it: CHARGE
5. Run it (depends on how you named it in the window before under OBJECT): EX flp1_test_task

Done.

That assumes you have downloaded Turbo Toolkit and placed it as flp1_turbo_tk_cde, then
downloaded the Turbo compiler and put the two _task files in there into flp1_Turbo_

Hi,
Trying to execute: LRESPR mdv1_turbo_tk.code
I get a error message: bad line. And doesn't continue the process.
I go to read the rest of the post in order to check any extra info about it.

Just I case, I recall that I have only QEmulator free version, that only allows 384KB RAM, and loading MDV images or Directories or QDos Floppy Disk (A or B)

The file name contains a dot - You need to put it in quotes.

[Popopo]

It is always great to see people learning to explore the QL world! Also great to see the help/support of QL dinosaurs answering the same or similar questions of newbies or the inexperienced. But why do people often go to the trouble of building their own kind of QL runtime environment to do their intended "job", when there are ready-to-use software distributions available? Like QL/E, in which went hundreds of hours work of very experienced QLers. Once the basics of QL are understood by using QL/E or other distributions and reading the enclosed documentation, anyone is free to configure/adapt/change/improve the environment or even ask for a change request. I mean, no one would try to build their own Windows, Mac OS or Linux system from scratch when there are installation routines available from Microsoft, Apple or the various Linux distributions.

Hi,
It is always nice to see how people helps newbies like me.
About the other points... well... I understand your POV, but perhaps if you wear a newbie shoes would be easier to understand. I mean...
The most of you have growth up with the QL and lived a lot of stages. So what you consider natural and easy is not for others. Because we have not your background. That is the most important point to understand why many decide to take apart their QLs or do not continue creating for QL systems.

The jump is too high, not because difficulties (that could too) but the lack of information in the middle way. The information is somewhere, mixed up with a lot of variants. But it is very often same than no information.

You know the tools, where they are how to use them, but pay attention: I have explained a context, also described what I have and my point to start and you kindly gave me (next post) some steps to follow. You have thought they are easy to do, but far from reality I cannot. Because there are lack of information that you supposed I have (or tools).

Your mistake? noway, my mistake? noway. So? we are in different places about acknowledge.
That is the main problem why not so many dear to introduce themselves into QL World (IMO). At least is what the most people that I suggested to travel by QL world and learn about it together tell me very often.

Perhaps we are too much get use to IDEs that automatize everything and we just code and design the APPs, so the time requirements even for programmers or engineers to start coding or creating for QL could be not short but also discouraging.

Now, what I love is all the people (like you) that are trying to help me.
Also I enjoy very much that even a repeated subject is attended and creating new comments, discussions and so on... because a forum without it, is... a site without live. Isn't it?
Of course, matter of preferences. But I prefer to ask you the basis, and request for help than take everything out and spend time in other systems with more available information and docs to start.

About Windows, Linux, OS/2... whatever. There are people doing exactly what you have said they are not doing. In many levels. And that is great. Some gets forgotten, other become very useful (Ubuntu, Mint, Mandriva, RedHat, FreeDos, OS/2 Lion, Minerva, ... ). don't they?

Let's go to the next message to reply Sorry for being late answering, crazy days

[Popopo]

Thanks for the instructions,
Let's see:

Doing the "job" using QL/E under a Windows PC is easy-peasy as follows:
1. Start QPC2.bat
2. In the 10 seconds countdown of the boot splash screen, press: m (this gives a minimal featured desktop)
3. Once QL/E boot completed, invoke: IDE
4. a) Load or type in a S*BASIC program, e.g.: LOAD WIN1_etc_SMSQETEST
4. b) If you like list it by invoking: LIST
5. a) Compile using TURBO by invoking: CHARGE
5. b) Compile using Q_Liberator by invoking: LIBERATE RAM1_QLibed,
5. c) Look for the compiled EXECutable files by invoking: WSTAT RAM1_
6. a) EXECute the TURBO compiled program by invoking: EXECUTE
6. b) EXECute the Q_Liberator compiled program by invoking: EX RAM1_QLibed_obj

No idea what QPC2 is, or where is the script BAT file.
By now I have only QEmulator.
I have not HDD driver emulator to use WIN1 unit.
TURBO doesn't load because I have no idea how to load it. So I guess CHARGE is after loading it in RAM to access to their own commands.

You mentioned RAM... I guess it is a RAM unit, isn't it? I'm sorry but no idea how to create it. Again thanks for your patience.

With your detailed instructions, I couldn't compile at all. I need to understand what else should I do or have between steps.

[Popopo]

I downloaded the zips you linked but wouldn't loaded as disk images. I could mount it as directories in QEmulator I guess. But not sure if it will work. Trying it later.

Hi,

I've used SuperCharge, a Digital Precision compiler (also free on Dilwyn's site under Turbo compiler link). It's the predecessor to the Turbo compiler and I found it really easy to run. Why did I use the oldest QL BASIC compiler on the planet? Well, I remember getting to use it back in the 90s so that's why I gravitated to it a few years ago. It runs on an unexpanded QL and microdrives with no issues, so should do fine on the free version of Q-emuLator. You just load in your BASIC program, then run MERGE to start the compiler and run it...it'll compile your code in seconds and you'll be good to go.

Here's a video for step-by-step instruction on how to run it -- I'm time stamping into the video where the guide starts...it's only about 3 minutes to watch. Note that I modified the SuperCharge BASIC boot programs to ask for which device it is running from, so you'll need to go in and hardcore the appropriate device (i.e. flp1_ or mdv1_, or whatever you use...in other words, like most QL software, it won't run out of the box unless you fiddle with device settings in boot programs so that's the minimal skill you need to run most anything on a QL):

https://www.youtube.com/watch?v=2nsfSjVfBA0&t=360s

Thank you,
It sounds promising!
I will follow and watch the whole video to understand everything. Not only the script but the context too.

Thank you for taking your time making those public videos

And now that you have mentioned it...
Isn't there any system variable that allows to know from where one command was invoked?
Or last unit/device invoked?

I have seen lot of soft that requires to define the unit from where it will work. So I guess there is not, but sounds so weird Sinclair didn't introduce something to manage it.
Thanks again

[bwinkel67]

Thank you,
It sounds promising!
I will follow and watch the whole video to understand everything. Not only the script but the context too.

Note that on a later post I also included a zip'ed MDV that you can use on an unregistered Q-emuLator to compile your program pretty quickly. It's the precursor to Turbo (i.e. SuperCharge) and works pretty quickly...so give that a try too since it avoids WIN containers and the like. Plus, I've already configured all of the basic boot files to ask for device so you just run it and put in the right info.

And now that you have mentioned it...
Isn't there any system variable that allows to know from where one command was invoked?
Or last unit/device invoked?

It would be useful that when running a command (i.e. lrun mdv2_boot) that you could have access to the argument (i.e. mdv2_boot) to parse out the device. But I don't think even TK2 gives you that. That and last line recall would have been nice addition to QDOS.

[Popopo]

The file name contains a dot - You need to put it in quotes.

Thank you,
yes, It was an issue. And after it, the compiler loaded as shown:

After using the Andrei MDV image that contains the compiler, it worked as shown:

and compiled fine.
Tomorrow I would like to explore a little more, why I couldn't with the shared files but the mdv image worked with the compilator.
It's very interesting

[Popopo]

Note that on a later post I also included a zip'ed MDV that you can use on an unregistered Q-emuLator to compile your program pretty quickly. It's the precursor to Turbo (i.e. SuperCharge) and works pretty quickly...so give that a try too since it avoids WIN containers and the like. Plus, I've already configured all of the basic boot files to ask for device so you just run it and put in the right info.

Sure I will. I appreciate your effort and time. Thank you a lot. Here I'll post results and doubts.

It would be useful that when running a command (i.e. lrun mdv2_boot) that you could have access to the argument (i.e. mdv2_boot) to parse out the device. But I don't think even TK2 gives you that. That and last line recall would have been nice addition to QDOS.

oooh yes. Like old doskey use to work in MS-Dos. Allowing to repeat last command typed, saving a lot of time
I'll try to investigate it a little more. Thank you a lot