The Sinclair QL Forum

Hi.
Is possible to put the SMSQ/e on ROMS inside the QL !?
Thanks in advance.

M.

SMSQ/E with its components has over 200 kB.
It will not fit to the 64 kB QL ROM.
However, it can be boot loaded from any mass storage device, including ROMdisq or another ROM-disk style device.

dex wrote:SMSQ/E with its components has over 200 kB.
It will not fit to the 64 kB QL ROM.
However, it can be boot loaded from any mass storage device, including ROMdisq or another ROM-disk style device.

The only version of SMSQ/E that works with the QL is SMSQ/E-GOLD, which is designed to run on a QL fitted with a Super/Gold Card.

Both the Gold Card and Super Gold Card on board ram is used for the QL memory and the QL internal memory is paged out. The SMSQ/E initialisation routine copies the SMSQ/E code to the Super/Gold Card ram.

To get SMSQ/E running on a standard QL with 640K or 896K ram, the SMSQ/E initialisation routine would have to re-written to use the QL internal memory map.

This is one of my pet project to get running, as the SMSQ/E source code is available, so should be achievable.

But a couple of questions arise:

1. Is it worth the effort, when Minerva works very well and basically does the same thing and can be extended where it does not.

The big difference, is that SMSQ/E has the Extended Environment built-in, this can be added to Minerva at boot up, as with Language tables.

Maybe a Minerva to SMSQ/E toolkit could be compiled from existing toolkit to give Minerva the SMSQ/E functionality.

2: With a Gold Card or Super Gold Card fitted, can the QL internal ram be access through some type of paging mechanism?

Hi,

I have posted the link to this thread and my response to the QL-USERS mailing list, there are excellent QL programmers that use the mailing list and not the Forum.

All,
I hope everyone knows that SMSQ/E on the Black Box requires a Gold or SuperGold Card. And I think the original poster has one, so his question implies smsqe_gold.

Derek_Stewart wrote:

dex wrote:SMSQ/E with its components has over 200 kB.
It will not fit to the 64 kB QL ROM.
However, it can be boot loaded from any mass storage device, including ROMdisq or another ROM-disk style device.

Actually, it doesn't need to fit into the ROM - For a QL with GC or SGC, SMSQ/E is not an OS ROM, but rather a bog standard executable. Once this executable runs, it boot loads SMSQ/E and replaces the original QDOS copied into the (S)GC's RAM.

Derek_Stewart wrote: Both the Gold Card and Super Gold Card on board ram is used for the QL memory and the QL internal memory is paged out. The SMSQ/E initialisation routine copies the SMSQ/E code to the Super/Gold Card ram.

Not exactly - The video circuitry and ULA will always display the contents of the original QL's video memory. That means, QL internal memory needs to stay where it is in order to retain scrren output. That also means transfers to this memory need to be 8 bits wide and severely slow down the (S)GC - As far as I know, the cards write to 16 bits wide and internal QL memory in parallel and read from 16 bits RAM in this area only.

For everything besides screen, the (S)GC use their own memory - Access to the QL RAM would be too slow, that's what was always the crux with the Thor 20 that only replaced the QL CPU with a faster one and didn't widen the bus.

Derek_Stewart wrote: To get SMSQ/E running on a standard QL with 640K or 896K ram, the SMSQ/E initialisation routine would have to re-written to use the QL internal memory map.

That's an entirely different story than with (S)GCs - Would be nice to have SMSQ/E running on, for example, a Trump card. One major thing would be that the interrupt vector table would have to be replaced with a new one, i.e. you'd either need to have some new hardware that allows you to page in RAM at low addresses or find some clever way of fitting critical parts of SMSQ/E into 64k ROM from 0-$ffff (That is how much room you'd have without a lot of HW changes, i.e. only fitting an EPROM into the original sockets) with maybe some parts above that loaded from disk.

Derek_Stewart wrote: 2: With a Gold Card or Super Gold Card fitted, can the QL internal ram be access through some type of paging mechanism?

It is possible, at least for the screen area. The question is: With an (S)GC, you have between 2M and 4M of memory available. It is kind of questionable whether the maybe 80k of additional internal (and slow) QL RAM you could gain would really be worth much effort.

Regards,
Tobias

There is a difference between physically 'paging out' a physical memory chip and not using that part of the memory map. In fact, the way the (S)GC does it is to _replace_ the physical ROM chips with a copy (somewhat patched) contents of the ROM but in the same address space. In essence, it emulates a MUCH faster ROM using RAM in it's place instead. In fact, the (S)GC also does the same thing with it's own on-board ROM, copying required code into the space right above the ROM addresses at $1000-17FF and possibly $1C00-1FFF. This is altogether 112k or so.
SMSQ/E for the (S)GC actually does use this space so part of the 200k or so of code replaces the 112k mentioned above, and the rest goes to what is normally considered RAM.
In other words, (S)GC uses it's physical RAM both to implement QL 'ROM' and QL 'RAM'. The way it does the first is to initially map the usual QL ROM and peripherals where they appear on a bog standard QL. It also maps it's physical RAM into multiple places in the memory map (easily done as unlike the 68008, the 68000 and 68EC020 CPU have a 16M address space, much larger than the total amount of RAM + ROM _ IO space fitted). It then copies the ROMs into RAM (into a copy where it's not currently replaced by actual ROM etc.). Then it write protects the areas where the actual ROMs appear initially - this does nothing as far as the ROMs are concerned since they are read only as it is. However, in the next step, the ROMs are simply unmapped, revealing their copies in RAM, It is then obviously essential that accidental writes to this RAM do not actually change it's contents or it would get corrupted, i.e. not behave like ROM

Regarding SMSQ/E in ROM, it is possible to do this in a SGC system if it is equipped with an Aurora. The Aurora has a provision for up to 512k of ROM. It is actually accessible as 16 pages of 32k each. THe Aurora takes advantage of the fact that the SGC has the actual ROM chip appear at $C00000 even once it's initialized and the ROM is not visible any more at it's usual $000000 address. Making SMSQ/E ROM-able would require some loader code and pointing to it by the initial reset vector - but at the alias visible at $C00000. Code there would then copy SMSQ/E code into the actual ROM areas (the 112k mentioned above) just like it would copy itself when loaded as an executable or in the same way the SGC would do with the original ROMs in case it was running QDOS or minerva. It would do this in 32k blocks since the code would be stored in 32k chunks to be paged out of the 512k ROM. Once done, it simply starts as SMSQ/E would usually do.

Now, the way the Aurora ROM is structured, it is possible to have both a QDOS/Minerva image and a SMSQ/E image in ROM. Placing the 48k ROM (QDOS or Minerva) into the first 2 32k blocks (so 48k used out of 64k) exactly emulates the usual ROMs. Implementing an 'SMSQE_LOAD' command in the last 16k of the ROM image would enable loading of SMSQ/E once the QL is started initially under QDOS or Minerva. The code would do exactly the same as the procedure outlined above. the first thing it needs to do is jump to it's copy (at $C0Cxxx), because this will always be there regardless of ROM paging or loading the SMSQ/E code into there the ROM copy was. The ROM paging mechanism only pages the first 32k, the remaining 16k always stays the same (first half of 32k page number 1).

Finally, there is a way to do something like this on a 'standard' QL but it needs a new RAM expansion that does exactly what the (S)GC does regarding replacing ROMs with RAM copies. Because this enables simple 'ROM emulation' without physically changing chips, not to mention that doing a RAM expansion these days almost implies something like this because of the smallest capacity of RAM chips one can get today, I think there would still be interest in something like it.

Hi Nasta,

Thank you for the clarification, I did think a standard QL with a memory expansion would be able to run SMSQ/E.

But from your description, it seems the best solution would be to have an Aurora.

Pity the Aurora, is not available anymore.

Derek_Stewart wrote:Hi Nasta,
Thank you for the clarification, I did think a standard QL with a memory expansion would be able to run SMSQ/E.
But from your description, it seems the best solution would be to have an Aurora.
Pity the Aurora, is not available anymore.

Mind you, it could be done with a RAM expansion that works similar to the (S)GC as far as RAM handling. It would be a RAM expansion similar to the Trumpcard as far as available RAM goes.
Regarding Aurora, ask Dave. I've shipped all the remaining parts to him, IIRC to build around 20 or so Auroras.

Paul was thinking along similar lines on the German QL Forum:

http://forum.tlienhard.com/phpBB3/viewt ... f=9&t=1509

Nasta wrote:Mind you, it could be done with a RAM expansion that works similar to the (S)GC as far as RAM handling. It would be a RAM expansion similar to the Trumpcard as far as available RAM goes.
Regarding Aurora, ask Dave. I've shipped all the remaining parts to him, IIRC to build around 20 or so Auroras.

I think Dave is taking a break from the QL at the moment.