The Sinclair QL Forum

You may have noticed from another thread, that I am trying to decompile Parser_task from SuperCharge.

Is anyone interested in this, other than for preservation? Is anyone interested in trying to update/improve SuperCharge? Or is everyone happy to use Turbo instead.

I'm just trying to gauge the level of interest, for how much effort to put into this project.

I've almost got the decompiled Parser_task to a state where it will load without error. But I don't yet know if there are any problems with the decompile.

Ideally I would like to try to recompile it back to an exact copy of the original Parser_task. But it looks like it was compiled with an earlier version of SuperCharge than the one I have, Version 2.0.

Has anyone got an earlier version, I believe 1.19 was the previous one. I know earlier versions used the Lenslock, but I can probably work around that. The Parser_task I have decompiled looks like the Lenslock stuff is still there. But I don't yet know how it got bypassed in SuperCharge version 2.0.

Some years ago SNG sent me some interesting papers on SuperCharge/Turbo. One is his BSc Hons Final Year Project Report which explains the philosophy and design of SuperCharge (SuperCharge was the project!) Another describes some of the internal workings, like the intermediate file format. They may be helpful to your efforts, or to anyone who is interested in this project (or indeed true compilers in general.)

HOWEVER, they are not really mine to publish. They may, of course, be available online somewhere already.. In particular intfile.txt and intcode.txt, which were published in QL World, June 1991. His BSc Project Report may be found as TurboRep.txt.

Since they are not private, secret or commercially sensitive, Im sure Simon wouldnt mind me sharing one-on-one with specially interested parties. In fact, he may even be willing to open up the SuperCharge source code, if asked nicely. He has a website at Simon.mooli.org

SNG writes (on his website):

It took another year to develop the academic project into a commercial product - QL Supercharge, £60 boxed with a 100 page manual (written in Scripsit on my Video Genie, printed with a Juki 6100 daisywheel printer). The compiler ran overnight for weeks, parsing itself in slow interpreted BASIC, usually to fall over in the small hours with some unanticipated problem. The aim was to get it to compile itself, and after weeks of trying it got all the way to the end and emitted a complete intermediate file. A few weeks later that assembled into an executable program. It took weeks more to get that to compile itself, and further weeks to get the compiled compiler to match the compiled compiled compiler! Compiler bootstrapping is not as simple, or as easy, as academics often make it seem.

I personally chose SuperCharge over Turbo because of its capabilities to run on an unexpanded BBQL -- I know that's a weird criteria but I love exploring the QL's original capabilities not its enhanced ones since I can just run an emulator and get max performance and memory, etc (so where's the fun in that). It seems Turbo is a derivative of SuperCharge, though I don't know if they started with the same code-base or just re-wrote it (I've read some of the documentation but it's a bit over the top at times with its greatness claims :-/). So if work were to happen on SuperCharge, I personally would love the scope to be limited so as to not just create another Turbo that got bigger to work on extra hardware and the PE environment. It's also nice that the entire installation fits in less than 128K of disk-space.

The interface could use improvements. Not sure what it's doing with the display (haven't read the manual to understand what that represents). Plus, I think I understand why they have you load in the program into QDOS first (i.e. it lets QDOS check for errors with its parse) and then re-parses it (presumably with a slightly less strict parser) to generate the internal representation to then code-generate. But I like DP's C idea better where you give a filename and then generate the _obj file and feed that into the code generator. If it could be transformed to a more traditional compiler, that might be useful...one that works within the 85K limited free memory and can still compile and generate say a 50K executable (like DP's C can).

Independent of all that, having a de-compiled version that is modified so it could be re-compiled with version 2.0 of SuperCharge would be neat (and eventually that could be re-compiled by its compiled version) Then, anyone could tweak it if so desired. Plus, seeing the code would be cool too, so even if no work is done on improving it, your plan to decmopile the whole thing would be very useful.

Would like to see Supercharge compiled with QLiberator.

Hi Folks,
Bwinkel wrote : << I personally chose SuperCharge over Turbo because of its capabilities to run on an unexpanded BBQL >>

I bought and successfully ran Turbo on my 128 ko JM. There was not much free memory and microdrive use was heavy as a result. The trick was not to use CHARGE, but parser_task and codegen task seperately.... (At the time my work programs were written as short modules which could be compiled seperately).

But Turbo had such powerful potential, that I saved up my pennies and bought a Gold Card. I still haven't used all the features. Speedwise, Turbo's acceleration became less of an advantage when the highly optimised SMSQ/E basic arrived.

The Turbo manual taught me how to greatly improve my programming, which previously relied on the QL User Guide tutorial.

Many of Simon Goodwin's DIY Tollkit programs are still of great value...

Steve.

stevepoole wrote: I bought and successfully ran Turbo on my 128 ko JM. There was not much free memory and microdrive use was heavy as a result. The trick was not to use CHARGE, but parser_task and codegen task seperately.... (At the time my work programs were written as short modules which could be compiled seperately).

I don't know about the original version of Turbo, but if you download the one on Dilwyn's site, the parser execuable has grown to 81K so there is just not enougth memory, with the needed dataspace, to run on what is generally left over from a 128K QL (about 85K). So the latest development of it (last updated in 2014 I think) just grew too big to run on an unexpanded BBQL. The version of SuperCharge on Dilwyn's site does work fine.

In any case, that's what I meant when giving reason as to why I chose SuperCharge...and that's my point with regard, that in upgrading SuperCharge, to keep the original BBQL in mind. Unfortunately websites don't tend to collect every version of the software as a) takes too much space and b) too confusing for the average user to figure out which to use.

Additionally, I didn't like the new interface that Turbo had...SuperCharge looked more like Digital C and so I was very used to that type of intterface. Perhaps adding one additional question during the compile, where it asks for dataspace size, would make it a tiny bit better (as opposed to having to run a second program).

Also, for whatever reason, I've had issues compiling things successfully with Turbo. It wouldn't comile the QBits Exploring QL Sounds program, nor my Baton Twirler that Peter Hale wrote (I think he wrote it) but both compiled fine with SuperCharge (though the former had a couple of lines where and END IF was needed but the compiler gave clear error messages).

bwinkel67 wrote:I personally chose SuperCharge over Turbo because of its capabilities to run on an unexpanded BBQL -- I know that's a weird criteria but I love exploring the QL's original capabilities not its enhanced ones since I can just run an emulator and get max performance and memory, etc (so where's the fun in that).<>

To my mind it seems you are chasing a figment of your own imagination.
I dont believe the 128k BBQL was ever meant to be the be-all and end-
all of creation - nor even of the QL itself. The limited design that
arrived in the shops was based on commercial, not technical criteria.
It was merely a gateway, a taster, to lure us in.

In reality it was supposed to be a multitasking machine, yet it
couldnt even multitask the software bundled with it due, mainly, to
limited memory. Even SuperBASIC was barely shoe-horned in, in a two
stage dongle kludge (first the dongle proper, then TK2, which without
with SuperBASIC is pretty useless).

So the idea that there was some pure, pristine Golden Age that since
got polluted with memory expansion and disk drives and what not is
arbitrary and fallacious. In fact the machine was meant to be
expanded! Otherwise, where do you draw the line? 128k AH + dongle +
B&W TV? A better place to draw the line would be, IMAO, at QL JS +
512k + TK2 + FDD, plus some simple systems software such as Taskmaster
or similar to enable basic multitasking. Do yourself (or yourselves if
there are more of you out there) a favour, dont beat yourself up:
upgrade the machine of your dream to one that is actually a real,
useable 1980s computer!

pjw wrote:To my mind it seems you are chasing a figment of your own imagination...

It's how I used the QL in the late 80's and early 90's and it worked quite well for me. I used Quill quite a lot for any type of letter/document and had a Brother M1109 printer hooked to it so I could get a hard copy. I also used Abacus at times (never really used Easel or Archive). More importantly, I was able to develop some software with it using Digital C SE and QED: two of which, that I ended up using extensively, were a terminal program and a command shell (which I ported to the Mac for a product I ended up selling). More recently I also created the ZXSimulator as a hobby during COVID to keep me sane, and it compiles quite nicely -- in fact, Digital C does quite a nice job (as C does) in efficiently being able to compile a larger codebase in smaller chunks and re-linking all on a BBQL (i.e. only compile the changed code, not the whole thing).

Before buying a Mac in 93 it was my main machine from 89 to 93 and I think I got a floppy in 92 with a Kempston disk interface, but never a Gold Card or memory expansion. I think I had to make a choice between Gold Card or a more expensive Mac and I chose the latter. I found it neat that I could write small utility software that would multitask under QDOS (I wrote an analog clock and an eyes program for fun). QDOS also has some cool hidden gems within it, like how it supports dynamic file caching, something most micros didn't even attempt and moderns OSes do now...so it's always fun to find these things in the original QDOS. Even without Toolkit II, Tony Tebby did a brilliant job creating a Unix-like OS in QDOS. Add to that the fact that ICE ended up being a ROM expansion that ate very little memory and gave you a GUI, was pretty cool too.

So for me, an unexpanded BBQL is about nostalgia of how I personally used it, and presently seeing what I can do with it, that's all. Everyone has a different idea of how to use it and they are all valid -- it's a hobby after all. But I doubt anyone is beating themselves up over it since there is plenty of computing horsepower out there that one can buy cheaply if needed (like a Raspberry Pi). I appreciate those that try and get their QL's to act like a modern computer and I think cool things come from that, and I'm always excited to see that. For me, I'm drawn to the 80's when it comes to the QL, and seeing what was available back then, so that is always my first choice.

To get back to the topic of this thread...

Martin_Head wrote:I've almost got the decompiled Parser_task to a state where it will load without error. But I don't yet know if there are any problems with the decompile.

I'm a bit confused here. So once decompiled, it can be recompiled with SuperCharge, so then the decompilation is in SuperBASIC. SuperCharge works by compiling a loaded BASIC, so if you run the loaded SuperBASIC Parser_task, I'm guessing that all it code could do is just parse itself? (This feels like Inception :-/) Also, where does it capture the object code (before the codgenerator is called? Is that what the weird screen display does (again, should read the manual as it may explain that)?