ROMable SMSQ/E

Anything QL Software or Programming Related.
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: ROMable SMSQ/E

Post by Peter »

tofro wrote:
Peter wrote:
tofro wrote:Q68 doesn't have ROM at all (at least not in a classic sense), so it is a bit hard on this box to put SMSQ/E into there ;)
The Q68 also has ROM, containing the bootloader. The ROM area has shadow RAM, but the same goes for (S)GC. SMSQ/E won't work otherwise.
That's what I meant with the part in brackets - The ROM doesn't (and I guess wouldn't even be large enough to) hold the OS.

The second part of the statement is actually new to me - I was not aware that SMSQ/E needs to be able to write to the lower memory area once it's up and running. Have you got any details what it is actually trying to do there? I have my doubts. Surely the standard version does load as a binary blob of modules relocating to their intended locations - But once it's done that, does it still try to write itself?
No, but the process to get it up always includes writing exception vectors etc. to lower memory at runtime. AFAIK there is no static version on any platform.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: ROMable SMSQ/E

Post by tofro »

That was my assumption. You could simply bypass the loader and burn an "already loaded" dump to the ROMs.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
XorA
Site Admin
Posts: 1359
Joined: Thu Jun 02, 2011 11:31 am
Location: Shotts, North Lanarkshire, Scotland, UK

Re: ROMable SMSQ/E

Post by XorA »

So the Amiga "solves" the booting from 0 problem with reprogrammable vectors by having kickstart shadow at 0 and 10M on switch on, it then jumps to 10M and turns off the shadow at 0 leaving rom running high in memory map for initialisation of the vectors then OS.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: ROMable SMSQ/E

Post by Peter »

tofro wrote:That was my assumption. You could simply bypass the loader and burn an "already loaded" dump to the ROMs.
Yes in principle, if it is derived from an SMSQ/E version that does not relocate itself from a "load address" to a "work address" in RAM.
Just using an "already loaded" dump might skip some early initializations, so I'm not sure it is quite that simple.


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: ROMable SMSQ/E

Post by tofro »

Peter wrote:
tofro wrote:That was my assumption. You could simply bypass the loader and burn an "already loaded" dump to the ROMs.
Just using an "already loaded" dump might skip some early initializations, so I'm not sure it is quite that simple.
It does. Had a short look into the code and found that sms_init starts with setting the trap vectors in low memory - Stuff like that obviously would need to change (Or rather: much of the initialisation code would need to...)

Maybe putting a small loader in a reasonably small ROM shadowed at 0 that loads the OS from SD card or whatever media like the Q68 does is really the most effective solution.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: ROMable SMSQ/E

Post by Nasta »

IF SMSQ/E does not have to relocate it's code, there is no need to re-write the exception vectors. If it has to re-locate, then the need to rewrite the vectors is obvious as they have to track the relocation of the code.

As far as I can tell, a static version is possible, but it needs more than access to the exception vectors. SMSQ/E is after all a 'QDOS compatible' and QDOS has vectored routines, with word (16 bit) vector addresses. This means that in case of a static SMSQ/E, the first 48k of ROM must be available for SMSQ/E code. This obviously covers the need to have exception vectors available since they reside in the first 256 bytes (and most are actually not used).
Modularity enables the rest of the code to reside elsewhere, for instance somewhere at the top of the memory map.

All that being said, this only has a real use in a system where code execution from ROM is not appreciably slower than from RAM. GC/SGC are definitely NOT that, and as far as I can tell neither is Q40/60 although the former are far worse in that respect because the ROM width is only 8 bits, whereas on the Q40/60 it's the full 32 bits, so even at the same access speed it would be 4x faster. But... how about on something closer to the original QL hardware, based on, say, a 68008FN so that a larger address map is available? One could provide 512k of storage, the top 384k located at the top of the 4M address map. The bottom 128k is divided into two 64k blocks, of which either can be mapped into the first 64k of the address map. Point being, a 'backup' OS like Minerva in one, the first 64k of SMSQ/E in the other 64k. The backup is in case you 'brick' the flash :P
In such a system it would be indeed feasible to run SMSQ/E directly from ROM.

This means there is no need for relocation, so a static image can be produced. In GC and SGC, relocation is used because both of them use shadow RAM to execute 'ROM' code, rather than real ROM, because the ram is full width and much faster than ROM, so they actually execute any ROM from a RAM copy. Also, normally there is no ROM storage in such a system where the SMSQ/E code could fit in any form (*) so it has to be loaded by an already running OS (**) so some form of relocation is needed anyway, fortunately GC/SGC provides the mechanism by default due to it's use of ROM shadowing.
Since SMSQ/E requires code to reside in the first 48k of the address map (for reasons mentioned above, CPU vectors plus OS vectored routines) just like any other QL OS, it uses the same mechanism of copying itself to shadow RAM in those positions. The remaining code runs from what the OS sees as actual real RAM. No idea about Q40/60 but on GC/SGC, there was already a discussion on this, and there are 3 major code portions, one in the shadow of the regular QL ROM (first 48k), another in the 32k space starting from $10000 (this is where the GC/SGC ROM copies itself) and the third one at the top of RAM. This way at least some of the code runs from 'emulated ROM' and increases the amount of working RAM available to the OS by that much.

Also, what is the current size of SMSQ/E? If I remember correctly it's around 256k for GC/SGC, and indeed running it on a slower 68008 system would probably use the GC/SGC version as a template. In the above example it would leave some of the flash capacity free for other ROM images or extensions. Bare SMSQ/E code would not be recognized by a different running OS as extensions since it does not have the required ROM header flags at modulo 16k intervals.

(*) Aurora provides a mechanism to fit a 512k ROM (or pre-programmed flash (***)) into it's ROM socket. The contents of the entire 512k ROM can be accessed as 16 pages of 32k (using a paging register) and page 0 (first 32k of the ROM chip) automatically appears as the first 32k of the address map, as usual. The following 16k (making a total of 48k ROM as original) is always the 16k of the ROM chip above the first 32k, but for this example it's not important).
A ROM image can be constructed that holds a small loader at the start, followed by the code of any OS you want (or multiple OSs for that matter). The loader would then execute instead of an actual OS and knowing it runs on a SGC, it could easily copy a static SMSQ/E map into all the proper places on the SGC, including shadowed areas, instead of the SGC ROM running and copying ROM to RAM etc...) establishing a copy of the SMSQ/E code where it needs to be, and then simply jump to the starting point for the code to be executed. And, you have ROM based SMSQ/E. Unfortunately, this was never supported. I suppose now that SMSQ/E is in the public domain, someone could generate an image for such a ROM.

(**) Alternatively, the SGC ROM itself could contain a loader and copy code either via this mechanism on Aurora or obtain it from another medium such as floppy or whatever.

(***) SGC does not generate write cycles to either of the ROM spaces it implements. Yes, there are two - one is initially the 'real' ROM at address zero, but there is also a copy always available (even after the actual ROM is replaced by shadow RAM) at $400000 if memory serves me correctly. But, in either case it can only be read, so there is no way the Aurora can write a flash chip if it was used instead of a read-only EPROM. Sadly :(


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: ROMable SMSQ/E

Post by Peter »

Nasta wrote:IF SMSQ/E does not have to relocate it's code, there is no need to re-write the exception vectors.
I didn't say SMSQ/E can not be changed so it doesn't write exception vectors etc. to RAM. But at the moment it simply does write. At least on the hardware I'm a bit familiar with. On most versions, including the Q68, SMSQ/E also relocates. Only exception I'm aware of, is Q40/Q60, if it is running from ROM. (The same binary can also be LRESPRed.)
Nasta wrote:SMSQ/E is after all a 'QDOS compatible' and QDOS has vectored routines, with word (16 bit) vector addresses.
When I said exception vectors, I always meant that also. Just too lazy to write it all again, as it was detailed in earlier discussions. ;)
Nasta wrote:This means that in case of a static SMSQ/E, the first 48k of ROM must be available for SMSQ/E code.
Not the full 48K, but that doesn't change the priciple.
Nasta wrote:Also, what is the current size of SMSQ/E? If I remember correctly it's around 256k for GC/SGC, and indeed running it on a slower 68008 system would probably use the GC/SGC version as a template.
Maybe, but not necessarily. SMSQ/E on a QL requires additional hardware anyway. Depending on the peripherals coming with that hardware (SDHC card or PS/2 keyboard/mouse could make sense), it could be easier to start with the Q68 version. Except the issue of shadow RAM at $0, the Q68 version (prepared for smaller RAM) should boot on a QL without changes. I once had the idea to test that by replacing the QL-SD EPROM with a Q68-like loader, that also contains everything Q68 SMSQ/E writes to the lower area, like Tobias wrote. This trick would of course only work for a specific version of SMSQ/E, not updateable.
Nasta wrote:A ROM image can be constructed that holds a small loader at the start, followed by the code of any OS you want (or multiple OSs for that matter).
It really depends on the piece of hardware which would make the QL SMSQ/E-ready. Personally, I prefer a loader which does not use Flash, but SD card for the OS.

Peter


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: ROMable SMSQ/E

Post by pjw »

Currently SMSQ/E (3.32) varies in size from 223k (gold8) to 316k (QPC2) The Q68 version is the
second largest at 304k. Of course, not all modules are loaded on all systems, and some are
optional across the board (eg the Recent Thing) and could be eliminated altogether. With a bit
of effort I suspect the size could be pared down further by, for example, by pushing some
options into external toolkits - to be loaded by the only two people who use them, at their
leisure. However, I suspect that the tendency will be towards growing even further over time,
so planning for 512k might be sensible, to cover the next 34 years..


Per
dont be happy. worry
- ?
User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: ROMable SMSQ/E

Post by Peter »

pjw wrote:Currently SMSQ/E (3.32) varies in size from 223k (gold8) to 316k (QPC2) The Q68 version is the second largest at 304k.
The Q68 SMSQ/E size comes from the two large screen drivers for Aurora and Q40/Q60 style graphics. Would be interesting to compile with QL screen support only. (There is no graphics upgrade for QL, Aurora always needs GC/SGC.)


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: ROMable SMSQ/E

Post by mk79 »

Peter wrote:At least on the hardware I'm a bit familiar with. On most versions, including the Q68, SMSQ/E also relocates. Only exception I'm aware of, is Q40/Q60, if it is running from ROM. (The same binary can also be LRESPRed.)
The ROM version relocates one time less than the LRESPR version, but as that relocates 2 times you still got one relocation left Image SMSQ/E (so far) never runs from ROM.
Peter wrote:
Nasta wrote:SMSQ/E is after all a 'QDOS compatible' and QDOS has vectored routines, with word (16 bit) vector addresses.
When I said exception vectors, I always meant that also. Just too lazy to write it all again, as it was detailed in earlier discussions. ;)
SMSQ/E also has an area for internal variables within the lower 64k, though I think it's constant once booting has finished.

Marcel


Post Reply