SMSQ/E

[dilwyn]

Can anyone remind me why SMSQ/E needs minimum Gold Card on QL?

Is it the processor (greater than 68008) or the amount of RAM?

[mk79]

Mostly because it needs the ability to alter the lower RAM area, where traditionally the ROMs are. GC and SGC have RAM there.

I‘ve written a version of SMSQ/E that employs some workarounds and should in theory be able to run on a QL (when flashed into the ROMs) but never actually found the time to try it.

[Nasta]

Marcel, am I right in thinking that there are no fundamental reasons why SMSQ/E could not be ROM-able?
If that was done, it would open a whole new field of use for 'QL' based hardware, that being embedded controllers. Given a fast enough CPU, controlling real world stuff using programs in Sbasic would be a nice advantage - not for every application, mind you, but there would still be a LOT of them.
BTW Aurora can use up to 512k of EPROM (or flash but not in-circuit programmable due to SGC limitations) and could be made to load SMSQ/E from flash given some code to implement it, perhaps even through a basic extension.

[mk79]

Marcel, am I right in thinking that there are no fundamental reasons why SMSQ/E could not be ROM-able?

Yes. After boot the ROM region is not touched again (AFAIK), the need for altering the data down there comes mostly from the modular structure of the OS. The sms.hdop trap for example is not defined in the "base OS", it's patched in by the platform dependent code later. But then the vector could also be just a trampoline call to a RAM region that can be changed during runtime, then it's not necessary to alter the actual vector.

The modules themselves should also be executable from ROM, I guess. The boot code must be patched to not copy them around, but apart from that it should work in theory.

The difficult thing is to debug such a change, it's basically only feasible using an Emulator, but I don't think any existing are prepared to host such non-QDOS ROMs.

Marcel