Compiling a SuperBasic program

[Popopo]

Hi again & happy 2025

I was trying to proceed but shame of me...

Assume you have a QL with enough memory and TK2 loaded. Further assume you have a floppy drive

I have 640KB if necessary in real QL. But I use for first testing QEmulator in free version.
It has a floppy option but I couldn't make it work. All time error message "not a QDOS disk". Without even allows me to choose a directory or ZIP or MDV image to treat it as Floppy.

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_

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.

The actually are a lot of switches and fiddly screws to mess with. But the above should get you going and we can take it from there. And you should really read the manuals, both the Toolkit and Compiler manual. They're really good and worth a read.

I have gotten some manuals and ready to read once I get work your easy example firstly. Otherwise I'll get stack on the first step (loading the compiler).

2025-01-01_16-24.png (7.13 KiB) Viewed 964 times

[QLvsJAGUAR]

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.

[QLvsJAGUAR]

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

[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.

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

[bwinkel67]

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.

I think Popopo wants to run on a BBQL with extra memory, and it's nicer to use emulation that mimics that environment more closely when running something on your desktop. I think the same can be argued in other communities, like the Amiga for instance, where many hobbyist prefer WB 1.3, or WB 2.0, versus the modern AmigaOne/AOS4 platform that's trying to be a Windows/MacOS/Gnome replacement. Nothing wrong with that, but if you are in it for the nostalgia, then likely those modern-like interfaces aren't for you.

[Peter]

Happy 2025 Derek and all!

you could also look at Turbo Compiler, which gives faster compiled programs, but not as compatible as Qliberator.

Qliberator is terribly incompatible with the 68040 and 68060. To execute QLiberated code, those CPUs have to be crippled to run without copyback cache. The worst case for Q40/Q60 - just because of some badly written code in Qliberator. I suspect self-modifying code, but even the Qliberator maintainers don't know the cause, let alone being able fix it.

This leads to people complaining about the 68060 being too slow - while the actual cause is Qliberator. For my interpretation of compatibility, Turbo is much better.

The sad thing is that some great programs like Dilwyn's Q-Dock are only availble in QLiberated form, unsuitable for Q40/Q60. Even uncompiled would be much better.

[Derek_Stewart]

Happy New Year.

The problems associated with Qliberator were in v3.36, there was attempts to patch the Qlib Runtime code, which nearly worked. But the suggested solution was to switch of off the copyback cache instead of finding the correct software solution. Which I found to be ridiculous, switching any cached system will slow the system down, even on a PCs. Maybe this was political issue rather than a software issue. As the Q40/60 was not seen in the best light by the major QL Influencers of that time.

Since then the Qliberator compiler system has been de-compiled by Martin Head's brilliant Qliberator decompiler software and the source code is now freely available, I would hope there are software solutions to the Q40/60 Qliberator issue.

[Maskenlos]

Hi,

Happy new year to everyone!

Here we go. Extract the attached *.zip on a PC. There is a *.win container in it.
Open QemuLator. Attach the *.win container to mdv1 slot.
Try "dir flp1_". You should see all the required files
"Lrespr flp1_Turbo_tk_code" -> you will see if it is loaded correctly
"Default_device flp1_"

Load your S*BASIC program

"CHARGE" -> Turbo should open
I assume you have to press "Space" to compile. But as I sad, I never used Turbo, better read the manual from here onwards.

Here it worked very well with QemuLator

Stephan

[QLvsJAGUAR]

I think Popopo wants to run on a BBQL with extra memory, and it's nicer to use emulation that mimics that environment more closely when running something on your desktop. I think the same can be argued in other communities, like the Amiga for instance, where many hobbyist prefer WB 1.3, or WB 2.0, versus the modern AmigaOne/AOS4 platform that's trying to be a Windows/MacOS/Gnome replacement. Nothing wrong with that, but if you are in it for the nostalgia, then likely those modern-like interfaces aren't for you.

Fully understand. That's well within the scope of QL/E, QL/E is for all QL platforms from the BBQL with at least 640KB RAM. From time to time, I personally also like to see what original 1980s HW/SW can do.

Popopo stated: By now using QEmulator in a virtual machine.

Here's a screenshot of the very same scenario on an 640KB QL with QL Speed (emulated with QemuLator as I don't have any of my BBQLs at hand right now).

[Peter]

Since then the Qliberator compiler system has been de-compiled by Martin Head's brilliant Qliberator decompiler software and the source code is now freely available, I would hope there are software solutions to the Q40/60 Qliberator issue.

Hi Derek,

I'm pretty sure it can somehow be solved. But I can not do that myself. I did ask, but the QLiberator maintainers didn't seem to have enough insight or motivation. I also found nobody else who was able to help yet.

The Qliberator problem is especially sad when I think of designing a new Q60, which would cost me an insane amount of work. More work than the original, because the time of ISA I/O cards is over. And at the end of the day SMSQ/E runs with copyback cache switched off, just because of QLiberator? Losing most of the speed gained by a huge hardware design effort?

Most annoyingly, QLiberator does not even bring a speed advantage under SMSQ/E. Just having a single QLiberated program running, cripples the rest of the machine for no user advantage.

I wonder if there is a different way to hide the sources of a S*BASIC program? Which seems the only remaining reason for QLiberated software under SMSQ/E at all.

All the best, Peter