A few years ago I suggested a ROMable version of SMSQ/E. The idea is that SMSQ/E could be natively in flash, so on power up it would be pre-loaded. This would provide an instant-on QL system with SMSQ/E, with no initial OS like QDOS or Minerva. Within SMSQ/E would be added code to allow for flashing new versions of SMSQ/E so updatability would be no issue. This requires stopping multitasking and programming the flash in a single-user mode, verifying, then rebooting.

It wasn't a priority, because no new QL clones were imminent.

Now the Q68 is here, and there are at least two other QL-compatibles likely within the next 12 months.

It would be a huge bonus to have a ROMable SMSQ/E that these machines can be designed around. Needing Minerva as a stepping-stone is wasteful and a limitation on how far the designs can progress away from the original QL hardware - whatever we do, it HAS to be able to boot QDOS/Minerva to launch SMSQ/E.

Well, the vector area needs to start at address 0, to tell the CPU where to start.

In case you don't want to place the whole OS starting from there, you have to implement some shadow RAM "behind" the ROM there, and at least put some minimum code that sets the Vector base register to the place where you want the "real" OS to start. Once you're running the code from there, you can activate RAM at 0. This obviously will only work with CPUs that have a VBR.

The main point is that SMSQ/E will (by far) not fit into the area that has been reserved for ROM and I/O in a "standard QL" memory map, i.e. in the lower $20000 bytes below the screen memory.

On the other hand, in case someone is willing to invest some development work: SMSQ/E is a modular OS consisting of quite some modules that can be loaded to different addresses that don't necessarily have to be contiguous. I don't think, however, that anyone has ever tried to do that in non-contiguous ROM space.

There are some tricks there that can be played - the FC lines from the CPU tell you what sort of access is being made - if memory serves me right, the first 2 vectors differ from the others in the FC code they use. That means that these vectors could be provided by a logic gate to go point to some other location to get things going from there.

RAM could then be provided at the low memory locations starting from zero.

If I've understood SMSQ/E correctly - it allows for some holes in the memory below the screen area, to accommodate the gold / super gold cards? Areas such as the 16K ROM slot space at 0c000 and the QL I/O area...

Pr0f wrote:If I've understood SMSQ/E correctly - it allows for some holes in the memory below the screen area, to accommodate the gold / super gold cards? Areas such as the 16K ROM slot space at 0c000 and the QL I/O area...

SMSQ/E for the GC/SGC is a bit different in that it run-time relocates its modules when started - There's no other way to start it than to load it from disk anyways and GC/SGC don't even have enough ROM space to run SMSQ/E from there, so this is not a waste of RAM. On a newly designed system, you probably want to start from ROM and run there, without runtime relocation.

tofro wrote:... On a newly designed system, you probably want to start from ROM and run there, without runtime relocation.

Tobias

Unless of course your RAM is 32 bits wide and your ROM is 8 or 16 bits - then you want to be running code out of the RAM, and suffer the relatively small copy overhead.

In a 68030 system for instance, where ROM and RAM can be in different parts of the wider address map - can SMSQ/E run form contiguous RAM that doesn't start at 0? Assuming VBR has been relocated into that RAM area for the vectors ?

tofro wrote:... On a newly designed system, you probably want to start from ROM and run there, without runtime relocation.

Tobias

Pr0f wrote:Unless of course your RAM is 32 bits wide and your ROM is 8 or 16 bits - then you want to be running code out of the RAM, and suffer the relatively small copy overhead.

Wastes either RAM or ROM, but well, yes.

Pr0f wrote:In a 68030 system for instance, where ROM and RAM can be in different parts of the wider address map - can SMSQ/E run form contiguous RAM that doesn't start at 0? Assuming VBR has been relocated into that RAM area for the vectors ?

Well, that exactly is not implemented in any system I know. On a GC, SMSQ/E runs in upper memory because of the "screen gap", but obviously has the vectors starting from 0 in RAM (because there is no other place the 68k likes them). I think the SGC does it the same way and doesn't use the 68020 VBR to relocate the vectors. I guess, with a bit of fiddling that could be made to work.