Platform Levels

[pjw]

One of the problems, I find, writing "QL" software intended for
sharing, is that there are so many utterly different combinations of
hardware (or platforms) and "core" software out there that it is
impossible to make assumptions about them. It is, of course, great that
each user can create their own unique world, but a nightmare for hobby
programmers (as we all must be these days), who dont have the
motivation or resources to cater for every configuration or test every
combination, but who would still like to create something useful or
fun.

What if we could agree on some basic standards about what a possible QL
system might look like? That way both programmers and users (thats all
of us!) can have some idea about what to expect. As mentioned, there
are QL worlds out there which seem strange, not to say bizarre, to me.
Equally, I expect, my outlook will seem strange and bizarre to some of
you. But maybe we need to start talking about our worlds so as to get
to know each other better.. The point of this would be to encourage
development by evening out some of the rough edges that create
unnecessary incompatibilities.

So, I propose dividing the QL worlds into five levels:

0 = basic, 1 = basic+, 2 and 2+ = intermediary, 3 = advanced (or
modern)

Each level would be expected to have certain capabilities regarding
hardware and what I would call core software, mainly system extensions
loaded at boot time. Users, while free to make whatever additions they
like, would be expected to have at least those capabilities if they
want to run software labelled for a given level. They would not be
permitted to grumble or troll authors if they tried to run software
labelled at a higher level on a lower level configuration or if they
did not fulfill the requirements of the level specification they claimed
to have, and it did not work - or completely trashed their machine

Take a toolkit like ENV_bin. It enables the use of Environmental
Variables, ie variables that can be set as part of the boot process and
then be accessed by programs at runtime. Great for making user
configuration settings, inter-job communication, etc. It takes up < 1k
bytes and has no processing overhead except for a brief flash when
used. A user might set TMP=win2_tmp_ and any program that needs to know
where to put temporary information would know where this user wants it
to go. It would be great if a programmer could be certain that such a
toolkit would be available. It would simplify programming efforts and
make life easier for users too. Although a user may not remember this
minute whether or not he has any program that uses ENV_bin, any future
program download targeting a given level, could assume this toolkit
would be available and that the user would know how to carry out the
instruction to use it. So Ive suggested that this goes in as a
requirement for all but the most basic levels.

In addition to the level specification, software might require
additional toolkits, of course, or a particular front-end. That would
be up to the programmer to decide and the user to accept or decline as
the case may be.

Now, Im not in a position to dictate this proposal, or my version of
it, to anyone (and even if I were, I probably wouldnt Those who
only indulge in nostalgia will probably not be interested in any of this.
They are relegated to level 0 and 1 and can do as they please. For
the rest of us, I believe it is necessary to forge some kind of sane
environment if we wish to improve on the production of new software
or, since there have been a number of returnee programmers recently,
to relaunch or update their original offerings.

I found it hard to format in any QL-compatible way, so I publish a
screenshot of my proposal here that, hopefully, is readable. A M$/Open
Office spreadsheet version is available for download and editing. This
proposal has evolved over many years, it is not a mere brain fart, (or
a trump, to coin a phrase). That being said, there may be entirely
different ways of looking at the issue, and there are platforms and
things Im not sure about, so there be errors and omissions. Remember
also that Im trying to define minimum specifications here. Bloat is
unwelcome AFAIAC. What I hope for is general agreement, or lively,
constructive argument - even scuffles in the aisles would make me happy.
What I expect, however, is a wide collective yawn, lethargy, and
thundering silence as per usual..

Apologies for the length of this post, if you got this far. This is the
cut-down version, believe me. But now its over to you!

Platform Levels

[tofro]

Per,

I don't think I'd ever write anything for a QL with less than a full memory extension and not at least floppy disks. That's just not fun (If it turns out the thing runs on low-level machines in the end, fine, but I wouldn't want to unnecessarily limit myself). Software for these systems must be written with performance in mind, often trading memory for speed.

On the top end, there are systems capable of running SMSQ/E (regardless of GC, SGC, QXL, QPC, Q68) that's the other end of the bandwidth. Unfortunately, there are systems in that category that are not capable of displaying at least 256 colours - For graphics-heavy software, or games that can greatly benefit from >=256 colours, those systems fall into the first category, I'm afraid. It's pretty hard to write software that can run equally well on an expanded QL and still use the better graphics on a Q40...

With regards to software - I tend to use anything that makes sense and makes my or the user's life easier. With most of the former commercial stuff freely available, I don't think we should bother so much wether we use Menu extension or Turbo Toolkit or anything else- Nearly all of that is there for anyone to grab, the situation has greatly improved during the last few years. The only thing we should need to do is properly document what we see as pre-conditions.

So the only question I see here is: Is software intended for a QL - or something better.

BTW: I am afraid you are under-estimating uqlx a bit: Apart from not being able to display hi-color graphics modes, it's pretty much a "modern system" that can run at close to QPC or Q-Emulator performance and with similar software equipped once beefed up a bit with Minerva and PE and runnining in hi-res.

Tobias

[RWAP]

The other consideration (and something I have never really understood), is that even if you decide to write for a top end system - QPC2 uses a different colour scheme to Q68, Q40 and Q60 - how is this catered for if you do not use the system colour palette?

Take QWord for example as a game written for modern systems. The engine was written so that it can support mode 4 graphics, although we never implemented this becuase it made it too boring a game. However, we had to release 3 different versions - for Aurora, QPC2 and for Q40/Q60.

Presumably the QPC2 version will work on SMSQmulator (I have not had chance to try!) and the Q40/Q60 version should work on the Q68.

[tofro]

Hmm. The system palette is not really a problem - A PE program will just display what it's asked to. After all, this only affects some decorations.

The only thing you need to be able to cope with is differing screen resolutions and colour depth. The first must be covered by your layout, the second you can hand over to the PE.

As long as you provide the graphics in the proper formats, A PE program can run on nearly anything you throw it at.

QJewels, for example, which is graphically not far away from what QWord does, runs on QXL (in hi-colour mode), Q40/60, QPC2 (in 256 and hi-colour mode), SMSQmulator and Q68 - Same binary, no changes. (Although SMSQ/E has definitely improved since the time QWord was written)

I had to supply two switchable screen layouts to cope with resolution differences and two sprite sets to cope with that and bitmap depth, that was all in terms of extra work to make it run practically everywhere I could lay my hands on to test. And (shame on me, but a praise to the system designers): I didn't even think about supporting all of those systems when I started...

I go with you it's different if you want to support original QL graphics as well, that is sometimes simply too limited.

Tobias

[RWAP]

Yes, I agree the system palette is fine for menus etc - but the graphics for a game are a pain if there is detailed graphics and they need converting for the various platforms.

From memory, the difference between QPC2 and Q40/Q60 etc is the byte order for graphics - maybe what we are missing is the ability for SMSQ/e to work with one system (say QPC2) and switch the output accordingly to cope with the hardware.

QWord does not use pointer environment calls except to handle the mouse - we did not use pointer environment icons, in case we decided to develop a version for standard QLs.

Does QJewel not support Aurora's 256 colour mode? That would not work even if SMSQ/e was adapted as above

[tofro]

Does QJewel not support Aurora's 256 colour mode? That would not work even if SMSQ/e was adapted as above

It should. Don't really know, though, as I'm missing real hardware to test. 256-colour mode was only tested on QPC2.

Tobias

[Giorgio Garabello]

I agree with Per's idea.
One thing you could do to get started is a survey to find out which systems are the most common and give priority to these when we develop software.

To make an example: there are certainly many QPC2 users, I'm not sure there are more than two or three users using QDOS4AMIGA so I never bothered to check if Black Phoenix or QTImage work on it.

Giorgio

[Derek_Stewart]

Hi,

All great ideas.

I use all systems QPC2 (registrated - this pre Free version), Q-emulator (Registrated), SMSQmulator, QDOS4AMIGA, UQLX.

I use QXL1, QXL2, Aurora, Atari TT030 QVME, Atari QL Mode 8, Extended 4 emulators, Q40, Q60. Multi array original QL hardware.

There appears to be a political question Mode 32 or Mode 33.

The Mode 33 PIC I converted 15 years from JPEG, on Q60 work on the Q68. As you would expect the Mode 33 is the same.

I am sure someone will say Mode 'xx' was there before Mode 'yy', so use that.

Which you a so called QL Today expert I am a dying breed. Not what he meant, maying talking rubbish as usually. How he got multipage access to a magazine, with no editiorial intervention. Is why we are here today.

If there any good new QL software this be problem. 15 years bringing 68060 hardware to the QL. I was expected to make software that was 20 years old work. The hardware too fast, the operating system was faulty and applications software used bad prorgamming practices.

New hardware can be made. So why standard graphics mode standards be written.

Maybe GMODE command to flip the graphics environment to either Mode 32 or Mode 33.

I doubt this can be done, whether implementation or MYMODE is the mode

I have more Mode 33 hardware than Mode 32. Living a democtracial life I use the populus view.

The new Q68 is Mode 33 with QL emulation mode.

Which is the best to use?

[pjw]

I don't think I'd ever write anything for a QL with less than a
full memory extension and not at least floppy disks. That's just not
fun

Me neither. But some people still use those systems and, presumably,
still write or want software for them.

The nub of what Im trying to achieve is COMPATIBILITY. One dimension of
this is CAPABILITY. This is a dimension where we may deliberately
choose to sacrifice compatibility for the sake of improved efficiency,
functionality, ease of use, presentation, etc. But at the same level of
capability it would be "nice" if we could work together to achieve the
highest possible degree of compatibility.

This post could get very long again, so let me try on a few concrete
examples:

1. In a recent post on a different thread, someone pointed out that a
newly released program used a keyword, SET, that conflicts with the
eponymous ENV_bin keyword. Had it been clear to the author that ENV_bin
was not just some incidental toolkit, but was considered to be part of
the system above a certain platform level, it would have been a non-
issue.

A next step to the graphic I presented above would be to maintain lists
of S*BASIC keywords that would be considered part of the system at each
level.

2. I sent a piece of software Im writing to a QL alpha pundit for
testing. It turns out he doesnt, as a matter of course, use ptrmen, the
essential EasyPtr toolkit (although there are "hundreds" of modern
programs that use EasyPtr!) As he was only testing my software he,
naturally, loaded ptrmen_cde in a SBASIC daughter job and crashed his
machine.

EayPtr is one of the most popular systems for writing PE programs. It
should be unnecessary to include details of how to use its "systems
toolkit", ptrmen_cde, with every program. Anyone with a capable enough
machine who does not have the ptrmen toolkit loaded will not be in the
market for any of the stuff produced by those who do! thereby loosing a
proportion of remaining users to "unnecessary incompatibility".
Honorable mention should be made of QPTR, QJUMP's attempt at making PE
accessible for S*BASIC programmers. While there is some overlap
between these two systems, no PE capable system can afford to be
without both, unless a user's needs are very limited, ie Quill and two
games.

3. So why not just include/compile these essential toolkits (in (2)
above) in with every program that uses them? Because it is inefficient
and dumb. Including them makes trying out new stuff fraught and off-
putting. Compiling them in means having each of any number of these
toolkits loaded multiple times, once for each program running. Also, as
some may have taken on board from a recent exchange on the QL-users
mailing list, compiling in toolkits that cover machines with different
capability levels, eg Turbo_tk_res, negates any (admittedly marginal)
advantage SMSQ/E users would gain from simply having Turbo_tk_sms
loaded as part of their system.

On the top end, there are systems capable of running SMSQ/E
(regardless of GC, SGC, QXL, QPC, Q68) that's the other end of the
bandwidth. Unfortunately, there are systems in that category that are
not capable of displaying at least 256 colours - For graphics-heavy
software, or games that can greatly benefit from >=256 colours, those
systems fall into the first category, I'm afraid. It's pretty hard to
write software that can run equally well on an expanded QL and still
use the better graphics on a Q40...

Yes, there will always be exceptions, and my suggestion on how to
categorise different capabilities my be the wrong one. Perhaps we
should rather be talking in terms of PE, colour depth, MDV-FDD-HDD,
Speed, etc. I dont really care how its done, as long as we get some
sanity. What Im against is

1. Unnecessary incompatibilities, ie where two different, but
essentially similar platforms, use different keywords to achieve the
same thing, for no good reason. (For example: QPC_EXIT vs JVA_EXIT,
WIN_DRIVE (QPC) vs WIN_USE (JVA).. Some of these incompatibilities
are being ironed out as we speak!)

2. Where doing the same thing on different platforms produced different
results for no good reason. Colour, especially stipples and the like,
and sound, spring to mind.

3. Bloat (see Wikipedia, for example, for a detailed explanation) where
software, particularly systems software, grows more and more unwieldy,
inefficient, messy, and ugly, due to ignorance, idiosyncrasy, laziness,
politics, or whatever.

Some incompatibilities, quirks, and bloat are of course unavoidable for
various technical reasons. Some could be straightened out, but would
cost an inordinate amount of effort. These we have to live with, and
may find them less frustrating when we understand that they cant be
helped. Its the remaining ones we need to do something about to avoid
further fragmentation (ponding?) of an environment many of us have
invested so much time, effort and treasure in.

With regards to software - I tend to use anything that makes
sense and makes my or the user's life easier. With most of the former
commercial stuff freely available, I don't think we should bother so
much wether we use Menu extension or Turbo Toolkit or anything else-
Nearly all of that is there for anyone to grab, the situation has
greatly improved during the last few years. The only thing we should
need to do is properly document what we see as pre-conditions.

Agreed. All Id like to achieve is systemising that, helping the
decision-making process for programmers and users alike; A map of
normality.

So the only question I see here is: Is software intended for a
QL - or something better.

BTW: I am afraid you are under-estimating uqlx a bit: Apart from
not being able to display hi-color graphics modes, it's pretty much a
"modern system" that can run at close to QPC or Q-Emulator performance
and with similar software equipped once beefed up a bit with Minerva
and PE and runnining in hi-res.

Its been some years since I used it, so thanks for the correction. I
guess my main reason for not putting it in the superduper bracket is
the lack of colour, sound and SMSQ/E?

Ive been out of play for some days with the flu' and am still not quite up
to scratch. If any of you got this far you may be relieved to know (but
please excuse) that I cant reply to most of the remaining posts!

[Derek_Stewart]

Hi Per,

I am assuming you mean the DIY Toolkit SET command written in 1991. (There is SET contanined HCO Toolkit)

SET only seems to work on non-SMS systems and MInerva up to v1.66

The SETENV command in ENV_BIN works SMSQ/E, Minerva, JS etc...

If you are after compatibility, it look like the DIYTK SET command is that is not compatible.

For that reason I would ENV_BIN over DIY Tooklkit. But since all the source code is available, both extensions could be made compatible.

Do you thikn this is worth perform this level of compatibility programming?