The Sinclair QL Forum

Anyone know of a hack to get a system's screen y-limit? The line length in bytes can be had from the channel definition block (sd_linel), so given the mode and the line length x-lim is easy to work out. Im talking about a system without the PI installed. Due to xQLx etc one cant assume 256. Any idea? Im stuck..

That had me puzzled for a moment, Photon seemed to cope without PE and larger screens (at least with UQLX) . But then UQLX will respond to SCR_YLIM. I can only assume then at least IOP.FLIM has been implemented.

Per,

in my opinion, there is no way to do that reliably, but essentially two relatively naive methods:

• Check if PE installed, if yes, ask PE - It will give you an exact answer. If PE is not there and we're in MODE 4 or 8, assume you are on a real QL and assume 256 (You'll be missing out uqlx that can do MODE 4 hi-res and any other platform that just happens to be in MODE 4 for whatever reason). That's what I tend to do.
• Use a trial-and-error-routine: Install a WHEN ERROR handler, resize a main window to some educated guesses of screen size and assume you've reached SCR_YLIM when it freaks out. (DP's Editor does it like that)

Tobias

First suggestion - if you do that UQLX will respond PE not present and you fall at first fence - best just call IOP.FLIM, it'll tell you if PE is there or not, but for UQLX it'll always tell you X/Y. It would only be polite for other emulators to do same, if they support larger screens.

Second suggestion - Ugh!

Well, neither Q40/Q60 in QDOS Classic mode Aurora seem to support IOP.FLIM (is that BTW documented for uqlx somewhere? Calling IOP.FLIM without PE loaded might as well lead to a crash or bogus answers on other machines).

The trial-and-error way of detecting the screen size isn't that bad either, if you keep the window width for the probing window small with no borders (and no CLS, of course), it can be made relatively invisible, and if you do the equivalent of a binary search for the limit, even relatively fast. It actually works quite well in The Editor.

The original Aurora screen driver (mode 4/8) was only implemented with PE. Otherwise it only worked in 512x256 (I offered ability in Photon to carefully demo high colour modes in QDOS/Minerva).

Wasn't aware QDOS Classic implemented 1024x512 on Q40.

Can't recall UQLX documented it, just know for BASIC that SCR_XLIM/SCR_YLIM and for m/c IOP.FLIM are implmented. It seemed eminently sensible that if you provide higher screen resolutions that you provide means of detection.

A bit poor if you crash your emulation if TRAP D0 code is unimplemented

Which emulation require trial-and-error ?

The uQLx big screen feature is a horrible hack where basically just CON open and sd.wdef are replaced/augmented with PC code. I don't see any support for IOP.FLIM in the code, but it's incredibly hard to read (motto was probably "it was hard to write, it should be even harder to read"). Why would you want to support that abomination?

I made various "compatibility toolkits" over the years so that
compiled programs that contained commands from SMSQ/E or Minerva could
still run under Qdos if the only thing preventing them from doing so
was the use of the odd command. Theres nothing stopping Qdos from
working with OUTLN, QUIT, ERT, various enhanced DATE commands,
SCR_xxx, DISP_TYPE, JOBID, FDEL, SUSJB, etc. (Some have since been
added to TK2.)

Having various sets like this available opens the field a bit, I find.
Theyre usually easy to do, and sometimes fun. Until now: I recently
discovered, to my annoyance, that my SCR_xxx suit (mainly extracted
from SMSQ/E sources and re-packaged) didnt work with unadulterated
Qdos but relied on the PI being present. So naturally I wanted to
remedy this.

In another toolkit I wrote I took the screen limits directly from
sys_clnk, and if that was zero just returned $02000100, ie QL
standard. But I feel this is a bit of a cop out. So this is how far I
got:
For a toolkit to be creating trial windows in the background, even if
invisible, any time it is called, is not the thing, I think. Its ok
for a program, I guess. (Although one might ask why the hell it has
to!) Clearly, that sort of essential information should be presented
by the OS and provided by the platform implementers. They, after all,
must know the answer as it is determined by the platform and/or user
interaction.

But what all the sage heads here seem to be telling me, is that there
is no sane way to get this information except by going on a heuristic
rampage. Yet here we all are, OS designers and maintainers, platform-
implementers, and tinkerers. Cant we decide on a standard and see it
implemented in future iterations of updates? Some system variable, or
some under-used Channel Definition Block location to contain the at
all times prevalent screen limits? The method chosen would, obviously
have to cater for the fact that Qdos ROMs are locked forever, but
anything that can provide a variable screen geometry should also be
able to provide an accurate metric at a known location or by some
known method.

mk79 wrote:The uQLx big screen feature is a horrible hack where basically just CON open and sd.wdef are replaced/augmented with PC code. I don't see any support for IOP.FLIM in the code, but it's incredibly hard to read (motto was probably "it was hard to write, it should be even harder to read"). Why would you want to support that abomination?

How was this checked with the Extended Mode 4 emulator on Atari? I can't remember as I have never used without PE.

pjw wrote:Cant we decide on a standard and see it implemented in future iterations of updates? Some system variable, or some under-used Channel Definition Block location to contain the at all times prevalent screen limits?

Sure. I'd call this new standard "PE" and have these variables available at address $f2 and $f4 of the CON driver definition block... I guarantee all new platforms will conform to it!

Othwerise: https://xkcd.com/927/