The Sinclair QL Forum

And if there is a 68008FN based piece of hardware with 4M (minus some QL bits) of RAM available? Possibly with ROM shadowing? Also Aurora compatible?
SMSQ/E needs a way to redirect basic exception vectors, there is really no way around that. It should actually be fairly easy to patch Minerva to get a 'special bit' of RAM holding a redirection table, for instance within the sysvar area or for that matter somewhere else, as long as a loadable version of SMSQ/E is aware of it and uses it - this is assuming Minerva is in ROM, and no RAM shadowing of the ROM. It also assumes there is no positin dependant code in Minerva, as i know for a fact unused parts of the vector table are used for code. The OS really only uses a few vectors anyway.
If the RAM shadows the ROM, then the vector table is in RAM and can be modified, also part of SMSQ/E can reside at the ROM addresses (and perhaps others between 10000h and 1FFFFh.

RWAP wrote: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.

My normal boot on QemuLator is the following

32757 IF VER$<>"HBA" THEN LRESPR WIN8_SMSQ_QEM:END IF
32758 DISP_COLOUR 0, 512, 256
32759 WMON:WDIR WIN1_
32761 INPUT #0, "Load ? from WIN1_";A$
32762 LOAD "FLP1_"&A$

works for me

Nasta wrote:And if there is a 68008FN based piece of hardware with 4M (minus some QL bits) of RAM available? Possibly with ROM shadowing? Also Aurora compatible?

Now things are starting to make sense in my opinion, thanks Nasta. SMSQ/E could really thrive in 4MB RAM on an original QL.

It would however make a lot of sense to put the redirection vectors in the top area of RAM and protect them from the RAM test, in order to keep nasty programs that assume a fixed lower memory map on the original box from crashing the system.
Both system variables area and supervisor stack (which is essentially the same) don't sound like a very good option to me (both would reduce supervisor stack area which is already pretty tight in JS-JSL).At the end of the day, you want Minnie to still be able to run old programs that wouldn't cope with SMSQ/E.

It was one of the design flaws of the QL that you couldn't bend the vector table to redirect to your own routines. All the other 68k machines of that time had that option, and even PCs could do it
(And why Tony decided to not allow per-job redirection of all or at least all of the TRAP vectors escapes me as well)

It also assumes there is no position dependant code in Minerva, as i know for a fact unused parts of the vector table are used for code. The OS really only uses a few vectors anyway.

That one I don't get - There definitively is position-dependant code in Minnie - Not in the way that it uses branches to fixed addresses to my knowledge, but the code is fiddled with in many places so that specific code entry points show up at the exact same address as on a JS ROM.

Tobias

tofro wrote:

Nasta wrote:And if there is a 68008FN based piece of hardware with 4M (minus some QL bits) of RAM available? Possibly with ROM shadowing? Also Aurora compatible?

Now things are starting to make sense in my opinion, thanks Nasta. SMSQ/E could really thrive in 4MB RAM on an original QL.

It would however make a lot of sense to put the redirection vectors in the top area of RAM and protect them from the RAM test, in order to keep nasty programs that assume a fixed lower memory map on the original box from crashing the system.
Both system variables area and supervisor stack (which is essentially the same) don't sound like a very good option to me (both would reduce supervisor stack area which is already pretty tight in JS-JSL).At the end of the day, you want Minnie to still be able to run old programs that wouldn't cope with SMSQ/E.

The problem with the top of the RAM is that it's not fixed (depends on how much RAM) and it's very difficult to protect a small area in RAM. There is however a different place but that would only work on said hardware, which might not be a problem since it has the capability to replace the motherboard ROM with it's own one (the idea bieing it could come with a slightly patched Minerva to cater for some small measure of added capability, apart from the large RAM).

It was one of the design flaws of the QL that you couldn't bend the vector table to redirect to your own routines. All the other 68k machines of that time had that option, and even PCs could do it
(And why Tony decided to not allow per-job redirection of all or at least all of the TRAP vectors escapes me as well)

Actually the way things are done in QDOS etc. it would not make sense to be able to redirect all TRAPs per job as this is how a job does things, though I suppose the user traps (5 and up) could have been redirected. Now, as for the other ones, there are not that many.

Reset vectors stay as they are as you can't assume anything about the state of the system after reset except there is a ROM with these vectors.

Then:
Bus error (BERRL asertion instead of DTACKL) - this may just as well execute a RTE...
Address Error
Illegal instruction
Zero divide
CHK instruction
TRAPV
Privilege violation
Trace
Line E emulatoin
Line F emulation
Up to 7 autovectored interrupts (though original 68008 DIL can only do levels 2, 5, 7)
16 TRAP vectors
---------------------
33 total
Since vectors are required to jump to code, this table would be one made up of jumps, 6 bytes per vector. Total required space is 198 bytes, though some of these vectors already are re-directable. Some were not and were dead ends leading to the infamous crash key combos CTRL-ALT-5 and CTRL-ALT-7 on JS. Knowing Lau, unless it broke compatibility, he did something clever with these.
The above mentioned hardware could actually provide 256 bytes of RAM (or more) out of the way of anything that could be used for a redirect table. Actually up to about 15k or so could be provided.

It also assumes there is no position dependant code in Minerva, as i know for a fact unused parts of the vector table are used for code. The OS really only uses a few vectors anyway.

That one I don't get - There definitively is position-dependant code in Minnie - Not in the way that it uses branches to fixed addresses to my knowledge, but the code is fiddled with in many places so that specific code entry points show up at the exact same address as on a JS ROM.
Tobias

Sorry, was unclear there. It assumes that no position dependent code is occupying the addresses in the vector table that need to hold vectors we want to redirect, so that it cannot be moved elsewhere, casue then we are screwed without ROM shadowing.

Well, stuff like PE could have been quite a bit easier to implement if TRAPs could have been fully re-directed. And there were quite some HW extensions using interrupts like keyboards that would have been much easier to implement as well - Instead they had to come with patched ROMs.

For quite some time I have been fiddling with a project that could also make good use of redirection of TRAP #2 and #3. Instead of redirecting a few routines into your own code and calling the original routine from there in case you need to you have to basically re-write half (or even all) of the console driver.

So, there actually is some good use cases for (complete) trap redirection, IMHO. That mechanism was used extensively on the Ataris to implement OS extensions.

And yes, TRAPs #5 and up plus some exceptions can be redirected per task which makes a lot of sense for debuggers and monitors. But somehow I always want more

Cheers,
Tobias

tofro wrote:Well, stuff like PE could have been quite a bit easier to implement if TRAPs could have been fully re-directed. And there were quite some HW extensions using interrupts like keyboards that would have been much easier to implement as well - Instead they had to come with patched ROMs.

Well, to be honest I don't know the details of the PE but as far as i understand the model QDOS uses to extend an existing device is really to link a new 'version' of the device. It has advantages and drawbacks just like any other system, most notably it does require supplying routines in the new driver even if the ones in the old one were perfectly usable (though this can be gotten around), but it does avoid problems with adding extensions out of sequence which would result in a whole lot of problems.
Regarding HW, I think this is for historic reasons which have to do with software, or rather old ROM versions. I have nothing against system maintained interrupt lists if well thought out interrupt groups are provided, even very few of them. Unfortunately only one is really provided. It has to be said that there are some pretty good reasons why one could be encouraged to implement ony a few interrupt types, Tony Tebby once very successfully argued for this approach in his writings about the Stella RTOS and in fact spoke about that the few times I've had the pleasure of talking with him.

Tobias, you seem to know these matters in-depth. Would you be willing to find out exactly what vectors are not used and not re-directable?

Nasta wrote:[
Tobias, you seem to know these matters in-depth. Would you be willing to find out exactly what vectors are not used and not re-directable?

Not that I would claim I'd know the matters in-depth, but:

Re-Directable on a per-job base are to my knowledge:
- Address Error
- Illegal Instruction
- Division by zero
- CHK
- TRAPV
- Privilege Violation
- Trace
- Interrupt Level 7 (which is, however, kind of pointless, see below)
- TRAP #5 - #15

Because $A and $F vectors are treated as illegal instruction (same entry point, see below) they can effectively also be re-directed.

Not used (in a sense) are (according to Minerva sources):
$A0 and $F0 vectors (routed to "Illegal instruction")
"Spurious" and level 1 Interrupt vectors point to an RTE
IR 3-6 point directly to an RTE
Level 7 see below

Un-used in a sense that they lead into kind of useless code (unless re-directed if possible) are most of the error exceptions (Address, DIV/0, privilege and illegal instruction as well as the $A and $F vectors) that simply enter an endless loop and thus lock up the machine in standard ROMs (Minerva does something about that, if I remember right, SMSQ/E definitely tries to kill the offending job)

And useless with respect that they render the hardware unusable is the
- level 7 interrupt that resets the co-processor and thus happens to kill the keyboard and serial ports and
- BERR (which is to my knowledge un-usable because it is hardwired to a reset)

Everything else (especially the "reserved" and "user interrupt" entries) can, I think, be considered "definitively unused" .

Hope this helps,
Tobias

EDIT: Some of the exception table entries (the "reserved" and "user interrupt" vectors) are actually used for code, and apparently this didn't start with Minnie, but even before - I found an old note that says the RAM-Test is located somewhere in the user irvs.

Checked that in Minnie 1.98:
The "hole" between $30 and $5F is just empty apart from a few bytes handling TRAP #0, space from $c0 ("reserved by Motorola") until beyond $176 is claimed by the QDOS + Minnie vectored routines table. Beyond that, "normal" code is located. (The "official" vector table would extend up to $3ff)

And, as an added comment: TT was apparently not very keen on letting you use the MT.TRAPV system call (which is documented), because that one wants to see a table in the format above - and not in the much longer M68k format - which is not documented anywhere in official Sinclair manuals.

On a standard QL (and GC, SGC...) only autovectored interrupts are used and in fact it's hardwired that way. So, user interrupt vectors are never used, hence that part of the table can be used for code.
Further, the actual hardware can only generate IR2, IR5, IR7, of which only IR2 is used, all sources are routed through the 8302 ULA.
BERR actually can be used, it's the HA:T line that is permanently tied to RESET so HALT cannot be used to, say, temporairly steal the bus from the CPU, nor van it be used in conjunction with BERR to make the CPU re-run a cycle, which are all hardware options - BERR on its own when used to finish a cycle instead of DTACK, generates the exception. In case of interrupt acknowledge, it will generate the spurious interrupt exception. This is, however, only used for hardware that is capable of supplying user interrupt vectors to the CPU, so not in auto-vectored systems, the idea beig, an interrupt occurs, but no hardware supplies a vector (this would be signalled by the vector being read off the us and the cycle ended with DTACK in the usual manner) so instead NERR is used.
On the QL, any interrupt acknowledge cycle will generate an auto-vector request, this is hardwired. To be honest I am not sure what happens if BERR is active when this happens (quick scan of the 68000 manual was not enough to find out). BERR is actually not used in any QL setup I know of.
It's original purpose is to provide a bus timeout in case something tries to access a location in the memory map that is unpopulated and will not generate DTACK, hence leaving the CPU to wait for a transfer acknowledge 'forever'. The idea is to have a timer that is reset by every DTACK, and ifit times out, BERR is generated - kind of like a bus cycle watchdog timer. However, the QL is set up in such a way that it expects that DTACK will always be generated (not to go into details about what assumptions are made for this to happen).

The reserved interrupts are mostly used by >=68010 CPUs, which includes the 68020 on the SGC, but for a normal 68000/8 based QL these can be used for code.
Usage of even useful parts of the vector table did indeed start from the very first ROM versions.
Re INT7, the IPC is reset anyway at startup, so code to deal with that does exist, the interesting question is, what do Hermes and superHermes do when CTRL-ALT-7 is pressed....
As far as interrupts go, it is possible to generate IR5 and IR7 from the expansion bus. IMHO, if interrupt vectors are redirected, it would be a good idea to actually redirect all 7 of them (in for a penny, in for a pound ).

Hi Nasta,

If a 68040/060 CPU were put into the QL, would this cause any problems with the current hardware.

With regards to SMSQ\E for a standard QL, I would vote to use Minerva, as it does not have the PTR\WMAN\HOTKEY system pre-loaded and more developement of a WIMP system could be performed without complete recompile of the operating system.

I would prefer to load the WIMP system at boot time.

Derek