Friday, 31 May 2019

Sinclair QL SMSQ/E experience on Super Gold Card

What makes QL literature near unreadable is that there is a long tradition of naming everything in an obfuscated manner :) So, we have QL, SMSQ/E, MDV0_, TK2, QL-SD, WMAN, PENV blah blah blah.

For text-based environment it's handy to have somewhat shorter names for things but damned if it ain't difficult sometimes to remember the keywords.

So welcome again to the Sinclair QL world both wonderful and strange (to borrow a phrase).

What I am mostly looking at is the SBASIC with the Sinclair QL SMSQ/E operating system.

I realised SMSQ/E can nowadays be downloaded freely as a binary and made to work on a Goldcard or Super Goldcard-equipped computer. It's not possible to have a replacement ROM, but the loading time is bearable with Super Gold card and QL-SD card reader.

To distinquish from SuperBASIC, the BASIC in SMSQ/E is called SBASIC. I think in the past I may have used "SBASIC" or "Sbasic" as a shorthand for SuperBASIC but it really is a bit different thing.

I usually feel it's more interesting if the BASIC is contained in ROM, because that is what makes it the standard for that machine, part of the experience of that machine. However, SBASIC doesn't differ that much from SuperBASIC, it's more of an extension than an alternative. So I feel like I'm not violating a huge principle here.

The SMSQ/E integrates the Pointer Environment, Window Manager and the Hotkeys System 2, so I'll touch on these topics too.

Getting SMSQ/E to run and boot

Download the goldcard.bin and rename it for example as SMSQGC_BIN

It's one kind of ordeal to transfer files over to the QL. I used my own solution for transferring files using the HxC Floppy Emulator hfe disk format.

When the file is on your QL disk, it can then be LRESPR'd. (Here we go again with the handy keywords)

I needed the Toolkit 2 to get the LRESPR command. It's a pity that although TK2 is also integrated in the SMSQ/E, it has to be invoked before it can be loaded? Handily the extension is part of the Super Gold Card, although it's curiously slow to activate. But anyway, TK2_EXT is the command.

Then, use LRESPR FLP1_SMSQGC_BIN (or SDC1 if the file is on QL-SD) and the file will be loaded and run like a resident extension.

Well, I can use

LBYTES sdc1_smsqe_bin,a
call a run the SMSQ/E file without resorting to TK2. I'm not sure if there are any downsides, seeing as the new system discards everything that happened at that point. At least this way I save a few seconds of boot time.

Using JOBS and HOT_LIST after booting through various files
Now we have the familiar divided red-white-black screen. The WTV command might be the first remedy if the image does not fit the screen.

I found I can't use the SDC1_ to reboot to a boot file on that drive after the SMSQ/E has started. The BOOT file has to be on FLP1_ so for the purposes of writing boot files I have my HxC connected to the disk interface of the Super Gold Card.

For example, as suggested above, the boot has to first activate TK2_EXT, then LRESPR the SMSQE_BIN. But after this has been done, the boot will not continue executing the lines, but SMSQ/E will boot again the BOOT file from FLP1_ drive.

So, in the worst case it will simply start reloading the SMSQ/E binary file again! This can be avoided by using


...which means the file will not load if we are running the boot from inside that version of the system. Obviously the correct version string has to be checked from within the SMSQ/E by PRINT VER$.

After this my system will turn over to the SDC1_ as it is faster than the floppy emulator.

I've understood SMSQ/E uses many of the screen and graphics speed-up routines similar to what used to be in separate extensions over the years. This is not especially noticeable when drawing lines, but the BLOCK command is indeed lightning fast compared to normal SuperBASIC. It might be the Minerva ROM already speeded the lines up, if anything.

Multiple SBASIC interpreters

The Pointer Environment does not mean that on running SMSQ/E you'll automatically see a mouse pointer and menus, it is up to the programs to do all that. But what the PE does do is that the multitasking SBASICs will handle the screen area in a more ordered manner when switching between jobs. Let's look at multitasking SBASIC.

Ineffective, but there it is: Two SBASICs drawing on their windows, on the same screen.
A new multitasking interpreter can be invoked by simply typing SBASIC. You might make a couple of interpreters, and put a program looping in each one of them. It's possible to switch between these jobs with CTRL-C.

QUIT exits the current job. RJOB removes a job with name. JOB_NAME "kekkonen" gives that name to the current job. JOBS lists to jobs as with Toolkit 2, with the job names given.

Sometimes I've experienced that a stopped program may be 'unfinished' so that it can't be removed with QUIT or RJOB. Could it be that files have been left open, I don't know.

On a whim I created a program I called 'jobkeeper', that simply clears the screen, prints the DATE$, lists the existing jobs using the JOBS. It also shows the remaining memory. The contents are refreshed every 5 seconds or so. PAUSE is used for timekeeping.

This way very little resources are taken from the other jobs. It was educational in looking how multiple SBASICS could be set up and viewed from this little 'jobkeeper'.

I notice there are not many ways the jobs can interact with each other via BASIC, I suppose switching to another job screen through a command is a no-no, and can only be achieved with the CTRL-C key or a Hotkey.

I've not looked too much into how jobs might communicate with each other. I've understood they can share channels. In recent versions SEND_EVENT and WAIT_EVENT can be used to send bits between SBASIC jobs. The program that is on x=WAIT_EVENT will be on hold, and after receiving an event the x will contain the information.

Screens grabbed on a real physical QL. I'm so proud! The date is printed by a different job.
As I said the integrated Pointer Environment helps keep the screens clean when switching between jobs. If the different BASIC jobs don't have overlapping windows, you can see the jobs using the screen at the same time. In the above example another SBASIC job prints the clock on top of the screen, above the default window area supplied by WTV. The clock stays visible and be updated while I work on the BASIC program that displays a chessboard.

Messing with multiple windows at the same time can get quite slow quite quickly even on 68020, but by managing time and pauses a couple of SBASICs can happily coexist on the same screen. Jobs that work completely on the background don't slow the computer that much.

One nag I have is the screen MODE is forgotten when switching between the jobs, which results in messy screens when changing to a job that was originally on a different MODE. However this may be intentional and there are situations where it might be impossible to resolve the correct MODE in a satisfactory way. So better try to stick to one mode.


This is one of the neat extensions integrated to SMSQ/E. You have to HOT_GO to activate it. A new job will remain resident and keyboard can be aliased into commands that should work throughout your system. The normal ALTKEY would just push the commands into current keyboard buffer, which is not that useful. The hot keys can activate other programs and BASIC commands even if you are not on the BASIC console.

This does not mean you can simply activate a compiler via a BASIC command, though.

Normally in basic, supposing I have copied both my compiler, linker and sources to RAM1_ I can do this:

EXEC_W ram1_qmac;ram1_source: EXEC_W ram1_qlink;ram1_source

and make it into an altkey, which again will not work from inside the QED editor as it would simply paste the command there.

QED job window on top of BASIC windows
And, although the above can be run as a BASIC command with the hotkeys HOT_CMD, as far as I see it won't really fly.

Instead you could associate the compiler and the linker to two hot keys, r and t respectively:

PRINT HOT_LOAD ("r","ram1_qmac";"ram1_source")
PRINT HOT_LOAD ("t","ram1_qlink";"ram1_source")

...passing the source file name trunk as a parameter.

Now I can work on a source inside QED editor, and use the hotkeys to compile to check it for errors, without exiting the editor. The fact that I've removed the wait time from my compiler end results becomes harmful; it goes back to QED so quickly I can't really see what the result is!

The HOT_LOAD won't simply accept a raw output binary, and it might be wiser to call the binary outside the QED editor anyways.

Although I can't run the compiler by a BASIC command through the HOT_CMD call, I can get around this by setting a separate, parallel SBASIC program that can be invoked using HOT_PICK. This program could then call the assembler, linker and even execute the result.

I used a bit similar technique for getting the above screengrab from QED. A separate basic job waits for keypress, then waits 5 seconds (for me to switch to the QED job) and stores the screenbuffer using SBYTES ram1_screen,131072,32768. Because this happens no matter what is on the screen at that point, the QED job screen can be grabbed.


Years ago, when the standard QL was the only thing I had tried, I asked what would have happened if the Sinclair QL approach got to mature over the years? Well, SMSQ/E and SBASIC is one step in that process.

SMSQ/E and SBASIC powered with the Pointer Extension and Hotkeys shows how cool the original Sinclair QL environment can be when some more thought and development has been put into it.

I like that with Sinclair QL, there is less distinction between using the machine and programming it than in computers like Apple Macintosh (and pretty much everything that came after). This makes it it interesting to tinker with.

I have not really compared the role and functionalities between the Minerva ROM and SMSQ/E.  Minerva functions would deserve a blog post in itself, perhaps some other day. The one thing I notice the dual-screen boot option of Minerva does not seem to mean anything after the SMSQ/E has been launched. This means the code I wrote utilizing page flipping on the assumption of Minerva being present, won't work. The lesson is perhaps: don't assume the presence of Minerva.


This was the first time I started experiencing hiccups with the QL-SD card reader. At one point the card simply refused to write or delete anything, instead locking up the entire machine at that point, jobs and all.

I tried to re-format the card and copy the BDI disk image there, and this worked for a bit but alas the problem reappeared. I've been told QL-SD is not very compatible with Gold Cards, but as I had so far had no problems I felt I might be lucky. Alas, apparently no. Some more investigation is in order.

Wednesday, 15 May 2019

Linux games test

I noticed there's quite a lot of "big" games available for Linux on Steam. Partly inspired by this, I switched my computer setup to a slightly more able 1050 GPU-based system.

Now I don't have to resort to playing Half-Life 2, Portal or 2D indie games.

Here's a few more 3D-intensive games I've tried, with some completely unscientific notes on how they performed on my 64-bit Linux Mint 19, i5 3.00GHz × 4, 16 GB, 1050 GPU computer.

The native resolution of my display is 1920 x 1200 which is bit too optimistic for recent games.

Tomb Raider (2013)

Already somewhat old game, I could bear to play this through last year on my old setup. This was possible because the play doesn't need to be that smooth.

I recall that I lowered the resolution quite a lot, and turned off the more involved hair simulation(!) that brought the speed down.

At native 1920 x 1200
What was left for me to try how Tomb Raider benefits from the 1050 GPU.

At first I experienced surprising slowdown and tried to remedy the situation by lowering the resolution to 1024 x 768. This resolution can even look a bit crude without the anti-aliasing as the environments are quite detailed at times.

But then I found out that "somehow" it does work quite nicely with 1920 x 1200 by changing various settings, especially when using the FXAA anti-aliasing, which is what you might expect from a 5-year old game. It didn't seem to need the triple-buffering either for syncing.

at 1024 x 768, no AA, scaled to 1920 x 1200
2013's Tomb Raider is a well balanced combination of exploration, climbing and action shooting with some roller coaster type run/jump sequences thrown in.

The puzzle elements are now in optional sub-quest tombs which I felt was a good idea.

Besides the main quest there's bunch of things to do and collect, different weapons and equipment to wield and stats and items to upgrade. Instead of toting the dual-pistols, Lara's main weapon of choice now seems to be the fashionable bow.

1920 x 1200

Everspace (2017)

If there's one game that inspired me to upgrade my computer a bit, it's Everspace, because without 1050-level GPU it just quite didn't work.

Even now I went for 1440 x 900 to make it faster. Strangely I could not get the in-game resolution switcher to work so I pre-set the resolution through desktop.

Gorgeus locations at 1440 x 900
The play requires quite fast frame rate, otherwise maneuvering in the battles becomes too confusing. However, a better resolution would be helpful as you want to sort out details from far off so a balance needs to be struck.

A long time ago, I wanted to play Elite: Dangerous, but as that game is not available for Linux I turned to this as a consolation. In some ways Everspace is really closer to the original Elite, although in many ways it's not. It's been described as a rogue-like in space, which is quite nice description.

The Gunship
The universe is structured as a sequence of bounded small locations, accessed through jump points and jump gates. If you think about it this is not unlike the original Elite, except here the galaxy is not open for free exploration.

The locations are most often filled with detail, multitudes of asteroids and derelict spaceships and other wrecks. Realism and space simulation has been thrown away in favor of condensed situations, again, much like Elite.

Combat can get intensive with drones and auto-turrets blazing.
You'll often encounter hostile ships, either outlaws or the dreaded Okkars, but sometimes you can manipulate different factions to fight each other and only enter the fray at a more opportune moment.

Again, as in most modern games, it's possible to customize and upgrade your ship endlessly, switch weapon systems and acquire special one-off items.

The Long Dark (2014)

Another "oldie", and not too big either, this game would have worked rather nicely on the old setting, as the 3D is not very complex. Now I can play it on 1920 x 1200 resolution with all detail on.

I've not looked at the story mode, as the plain survival mode felt more interesting to me. The game places you somewhere in the wintry northern Canada, and a geomagnetic (read "magical") storm has broken all electrical equipment. You'll simply have to find a ways to stay alive in the harsh environment.

That fog isn't there to clip the view distance... it's there to kill you.
Some of the first moments with the game were quite intense. A lot of effort has been put into producing dynamic weather effects, literally the most atmospheric part of the game.

There's something satisfying in wandering desperately in a snowstorm and then finding refuge in an old cottage in the middle of nowhere. Then you try to get a fire up and running and arrange food and drink before opening the bedroll.

The Maintenance Yard. Those planks will be transformed into firewood.
The illusion begins to break for me as I realized the areas are meticulously designed to have certain amount of exits and inroads to other areas. (Possibly to facilitate the story mode) You really can't get that lost, and the cliffs are really un-climbable, ultimate constraints of the maze.

It turns out that as an abandoned national park, the neighborhood is filled to the brim with equipment, buildings and pathways to follow. A somewhat more generative universe would have been welcome for the survival mode.

Yet again, stuff to be crafted, broken apart to component pieces, repaired and so on and on, but in this game concept this seems more justified.