SGC Games Compatibility

[stephen_usher]

That's a bit misleading: In an exception, the CPU is always in supervisor mode.

Well, if games don't run on Minerva they're obviously not following the rules, probably including running in supervisor mode and turning off the mutlitasking and hitting the hardware directly.

This is the way of games developers (and demo writers).

[tofro]

That's a bit misleading: In an exception, the CPU is always in supervisor mode.

Well, if games don't run on Minerva they're obviously not following the rules, probably including running in supervisor mode and turning off the mutlitasking and hitting the hardware directly.

This is the way of games developers (and demo writers).

Well, there's mainly two, maybe three sins that game writers tend to commit frequently (for no good reason, actually):

1. Patch the first entry in the polling interrupt list with your own code address, basically killing the interrupt system - On Minerva, which relies on complete execution of the list to run properly, that is the main culprits for non-running games. There's in fact not much reason to do that when you can add your VSYNC code properly to the polling interrupt with a system call instead of doing that nonsense for a totally insignificant loss of performance. (If you properly use the polling interrupt, the OS will also normally take care of the differences in exception stack layout between various CPUs for free...)
2. Run in supervisor mode. This doesn't normally affect Minerva, but keyboard and sound handling on the Q68, QIMSI Gold, and some emulators, for example. On an otherwise empty system, your performance gain will also only be very minimal.
3. Some games try to re-implement the IPC comms in their own code in the hope to have more direct influence on sound timing. Yes, IPC comms is pretty slow in most QL OSs, but that's more due to the crippled hardware. You can squeeze a bit of sound (and maybe keyboard) responsiveness out of the systems, but you basically loose all of your "customer base" outside the BBQL. (To my knowledge, currently the only QL-alike that properly implements the IPC is the NextQL)

[RalfR]

Some games try to re-implement the IPC comms in their own code in the hope to have more direct influence on sound timing.

As you can see in "Scrabble".

[M68008]

Well, there's mainly two, maybe three sins that game writers tend to commit frequently (for no good reason, actually):

1. Patch the first entry in the polling interrupt list with your own code address, basically killing the interrupt system - On Minerva, which relies on complete execution of the list to run properly, that is the main culprits for non-running games. There's in fact not much reason to do that when you can add your VSYNC code properly to the polling interrupt with a system call instead of doing that nonsense for a totally insignificant loss of performance. (If you properly use the polling interrupt, the OS will also normally take care of the differences in exception stack layout between various CPUs for free...)
2. Run in supervisor mode. This doesn't normally affect Minerva, but keyboard and sound handling on the Q68, QIMSI Gold, and some emulators, for example. On an otherwise empty system, your performance gain will also only be very minimal.
3. Some games try to re-implement the IPC comms in their own code in the hope to have more direct influence on sound timing. Yes, IPC comms is pretty slow in most QL OSs, but that's more due to the crippled hardware. You can squeeze a bit of sound (and maybe keyboard) responsiveness out of the systems, but you basically loose all of your "customer base" outside the BBQL. (To my knowledge, currently the only QL-alike that properly implements the IPC is the NextQL)

About the "for no good reason", it's hard to quantify the impact when running on the original QL hardware... I hope to run a few related benchmarks at some point.

Many games and demos were/are written more targeting the machine than the OS. Seems reasonable to me, since QDOS provided very little support for games, and areas like the CON driver had a slow implementation. Compare for example with Mac OS, where software blitting was available and fast.
A few games also need the second screen, not available in QDOS without disabling the OS. It's a pity, since a lot of the QDOS code seems to already support relocatable screens and system variables.

Other games target more modern systems that run faster, or don't need high fps to start with, and in that case I fully agree that there is no reason for 'breaking' the rules.

[janbredenbeek]

Well, there's mainly two, maybe three sins that game writers tend to commit frequently (for no good reason, actually):

1. Patch the first entry in the polling interrupt list with your own code address, basically killing the interrupt system - On Minerva, which relies on complete execution of the list to run properly, that is the main culprits for non-running games. There's in fact not much reason to do that when you can add your VSYNC code properly to the polling interrupt with a system call instead of doing that nonsense for a totally insignificant loss of performance. (If you properly use the polling interrupt, the OS will also normally take care of the differences in exception stack layout between various CPUs for free...)
2. Run in supervisor mode. This doesn't normally affect Minerva, but keyboard and sound handling on the Q68, QIMSI Gold, and some emulators, for example. On an otherwise empty system, your performance gain will also only be very minimal.

The keyboard will be scanned even in supervisor mode, unless you disable interrupts or the polled interrupt list (with Hermes and Minerva 1.93+ it will continue to be scanned, since Hermes generates an interface interrupt unlike the ordinary IPC).
Having disabled interrupts, you can still scan the keyboard using the 'keyrow' IPC function. Minerva for Q68 now emulates that function, even with interrupts disabled, if the application properly uses the IPC system call.

Another reason for games failing on Minerva might be relocation of the SSP (Supervisor Stack Pointer). Minerva relies on register A6 being in the same 32K segment as the SSP. This way, with dual screen enabled, it can correctly set A6 to point to the system variables since it cannot store it somewhere in RAM like SMSQ/E does.
If you relocate the SSP somewhere in high memory, this will fail so don't expect MT.IPCOM to continue to work (AFAIK, in Minerva it depends on A6 pointing to the SV area, unlike classic QDOS).

[Peter]

(To my knowledge, currently the only QL-alike that properly implements the IPC is the NextQL)

It's properly done in the MIST(er) implementation from which the NextQL probably took it.

[t0nyt]

I was reading thru the SBASIC online manual and came across the res_size routine for the SGC

I picked one of the programs I couldn't get to run on the JS/SGC and used "res_size 512", instead of "reset 512" (which works without the SGC) and the program ran (much too fast of course!)

Will go back thru the "problem" games for JS/SGC and see if this helps with them as well or was just a problem with my original testing