The Sinclair QL Forum

Hi,

I have seen that SMSQ/E has been ported to Qemulator, now that it is free software. Makes me wonder whether there any plans or even ongoing projects to port SMSQ/E to the QL?

With at least 512K RAM extension, i.e. 640K total, I can not see why SMSQ/E would not work.

Peter

The port to q-emulator was fairly easy - as it is just the Gold Card version.

I guess the main issue is whether SMSQ/e would fit on a Trump Card or smaller - the high colour drivers and high resolution modes could be stripped out (as they would only work with QubIDE which does not work with a Trump Card so far as I recall). I wonder how much free memory that would leave for the QL...

It would also be a matter of checking whether any of the code is incompatible with a 68008 processor (as compared with the 68000 on the Gold Card).....

The 68008 is functionally identical to the 68000, apart from addressable memory and data bus width - No difference in the instruction sets. It was only until the 68010 that Motorola dared to change something for the first time. That wouldn't be a problem.

And it's the Aurora card that has the colors and resolution, not the QubIDE The current build system allows to exclude the Aurora drivers from the build already (The resulting binary isn't that much smaller, though)

I think most people who still have a QL today keep it for nostalgic reasons and because there are still some programs (especially games) that will only run on the original black box. SMSQ/E can be had better and faster on Emulators today.

SMSQ/E for the GoldCard today has a size of ~220k - That would obviously not fit in the ROM space and use up 1/3rd of the memory of a typical fully expanded QL - Not sure if that would be a desirable solution, although the original QL would very well benefit from the much faster Basic.

The next technical problem is that, as SMSQ/E obviously wouldn't fit in the ROM space available on the original QL (at least not the whole thing), it would still have to be at least partially ROM-based because of the interrupt and reset vectors - So it is not easily doable without hardware modifications. GC went around this by implementing RAM starting from address 0 and copying things around. If you would start to go in this direction, in the end you would probably end up with something very close to a Gold Card, except the CPU.

The other problem is that SMSQ/E for the GC only had to address one single piece of hardware. Once you extend this to other cards, the floppy drivers all have to be implemented in separate versions.

Regards,
Tobias

There are 16x16K ROM slots available higher in the memory map. That's about the only place it could theoretically fit, and then you'd not be able to use expansions that expected their ROMs to be mapped there.

I asked a few years ago if there was any interest in an SMSQ/E ROM card for J1 and was politely told, no, it would serve no purpose even if it were possible.

My hope would be to do a replacement QL board which was designed for SMSQ/E, but SMSQ/E would have to meet it half way. That's unlikely, so it looks like Minerva is a more likely target.

Since both SMSQ/E and Minerva are open source, is it possible for the BASIC interpreter from SMSQ/E to be spooned to work with Minerva? Cats playing with dogs!

Dave wrote:There are 16x16K ROM slots available higher in the memory map. That's about the only place it could theoretically fit, and then you'd not be able to use expansions that expected their ROMs to be mapped there.

Ehm, Not quite. RAM starts at 128k with the screen area. 48k of the ROM plus some I/O space at the upper end of the 128k are used by the original ROMs. That leaves space for 4 expansion slot ROMs and board I/O 16k each plus 16k for the ROM slot. Somewhere in there is also the bare-bone QL's I/O space that also needs a bit or room (although this is only a few registers, it takes quite a bit of space because it shows up multiple times due to only partial address decoding) I guess it would be quite a challenge to fit today's SMSQ/E in there and leaving (at least a bit of) I/O space.

Dave wrote: Since both SMSQ/E and Minerva are open source, is it possible for the BASIC interpreter from SMSQ/E to be spooned to work with Minerva? Cats playing with dogs!

Possible? I guess yes - In the end it's all software. But the Basic interpreter of both Minerva (a bit more) and SMSQ/E (a bit less) is so closely interwoven with the respective operating system that I think that would be an even bigger challenge. Especially Minerva is such a condensed piece of software that I wouldn't dare starting that effort. (Note: I'm not saying it's bad - The opposite is true - It does a lot of very tricky things to be as close to the original as possible, add functionality and still fit into the same space)

And still you need RAM or replacement ROM for the vector area at address 0.

Tobias

Let's put it this way:

If you were to put SMSQ/E on a custom-built QL-style machine that had a 4MB address range, what would you do?

RWAP wrote:The port to q-emulator was fairly easy - as it is just the Gold Card version.

Qemulator has always been able to emulate the Gold Card binary of SMSQ/E. I didn't mean that.

New is a specific Q-emuLator port of SMSQ/E with additional features, see
http://www.terdina.net/ql/rom/SMSQ_QEM.zip

tofro wrote:SMSQ/E can be had better and faster on Emulators today.

Minerva can also be had "better and faster" on emulators, so that's pointless. People want Minerva on the QL for the improvements it offers. Same reasoning for SMSQ/E.

The fast SMSQ/E BASIC and screen is even more important for the QL than for the other machines. The QL lacks speed, very much unlike PC emulators. As the recent numbers of returning QL users and the demand for QL-SD shows, expanded QLs are actually used today.

Another point for SMSQ/E on the QL would be the option to run the same basic OS on all QL style architectures, for software which is not memory hungry (and really memory hungry software won't work on a QL anyway).

tofro wrote:SMSQ/E for the GoldCard today has a size of ~220k - That would obviously not fit in the ROM space and use up 1/3rd of the memory of a typical fully expanded QL

Of course I'm aware of the RAM footprint, but there would still be a lot of usability. The GC version contains features unnecessary on the QL, like Aurora graphics and GC specific device support. Also, SMSQ/E reduces the need to load additional extensions on a QL, such as TK2, lightning, etc. which makes the balance look better.

Obviously one would not bother supporting all QL configurations by SMSQ/E - 128K is impossible anyway. Expect Minerva in ROM, or - if it helps porting - even expect other hardware people can get for the QL today. One might need a patch to Minerva, so the Interrupt can be redirected (not sure, maybe the actual code in Minerva ROM allows something else).

tofro wrote:The other problem is that SMSQ/E for the GC only had to address one single piece of hardware. Once you extend this to other cards, the floppy drivers all have to be implemented in separate versions.

SMSQ/E happily lives with other pieces of QL storage hardware, e.g. Qubide, Romdisq and QL-SD. If there is a QL floppy, it brings it's own driver, and SMSQ/E should in principle be able to run such a driver (GC pitfalls like ROM shadowing are not here). If not, simply forget that piece of hardware under SMSQ/E or stick with Minerva. No system has ever been compatible to everything.

tofro wrote:And still you need RAM or replacement ROM for the vector area at address 0.

I can see no need to replace something at address 0. Reset vector and initial stackpointer can remain. The OS in ROM will boot first, anyway. I have not yet looked at all exceptions.

Update: There are less exception redirection possibilities than I remembered. Much more patching than just interrupt is probably required in Minerva ROM.

Peter

I had not seen the specific version for q-emulator - thankyou.

I agree with Peter that the standard QL does indeed need SMSQ/e moreso than any other implementations - to get the maximum speed increase.

There is very little software which uses more than 512K so I don't (at the moment) perceive an issue with memory - although if a bootstrap device (or similar) could be provided on a ROM board, so that maybe part of SMSQ/e could use the 48K ROM space, that would help reduce its footprint.

I've had a quick word with Wolfgang about this....

His response:

I believe that stripping out the high resolution and colour drivers is just a question of amending the
SMSQEmake prog - 5 minutes work....

What isn't trivial would be a rewrite of, at least, the

'smsq_gold_host_link'
'smsq_gold_hwinit_link'
'smsq_gold_nasty_link'
'smsq_gold_nasty_s_link'
'smsq_gold_roms_link'

targets - and probably also the

'smsq_gold_qimi_link'
'smsq_gold_kbd_lang_link'
'smsq_gold_kbd_abc_lng_link'
'smsq_gold_kbd_abc_link'

targets.

Especially the mdv code that I presume is somewhere in there will be difficult (timings).

If a person with sufficient knowledge loves to port SMSQ/E, I might be able to give some support, time permitting:

1. OS-independent QL boot system in EPROM for startup and exception vector redirection
2. Special version of QL-SD to hold that boot system plus the QL-SD driver in EPROM
3. SDHC loader which can load a fixed length SMSQ/E binary from FAT32

Except microdrive and network code, it might be a manageable task for someone who is familiar with SMSQ/E and has the above tools. For example, porting QDOS Classic to the Q68 took only a few days, which is quite similar to a QL without microdrives. In the long run, a patched Minerva instead of a special boot EPROM might be better.

I didn't touch SMSQ/E for more than a decade, so it makes no sense to port SMSQ/E myself. Also the original QL is certainly not my personal priority. I was more or less wondering whether someone else is doing something toward the QL, now that SMSQ/E is free.

Peter