The Sinclair QL Forum

As you can see from the Off-Topic section, I've relaunched my Sinclair-related webpages.

And, seeing as there's some QL content in it to start with, I'll link to that here. I don't know of any centralised archive of QL type-in software beyond Jim Grimwood's Type Fantastic, which he admits might never be updated again as he is in the grip of a serious illness (I won't say what it is, but it's certainly not trivial, and it wasn't what I'd originally suspected). Digging through this forum I found a thread on QL User type-ins, which is a start.

JimG's site collects all the QL and SAM Coupé listings along with those from the Spectrum, and though they're few and far between, I've found QL listings in the pages of Sinclair User, ZX Computing, Popular Computing Weekly and a fair few others. JimG dealt with five listings from ZX Computing circa 2002, but those are the only ones stored on The Type Fantastic, and only as raw text listings (and not all of them were LF-only, either!) So I've translated those to .MDV format - seeing as I've now had it confirmed that'll work on QemuLator at least - and I've added the programs I typed in from Sinclair User back in April. Sinclair User's type-in listings are complete, as far as the programs JimG has indexed are concerned.

So now I'm turning my attention towards completing the QL type-ins archive, as is hosted on The Type Fantastic - and I'll add more, if I find the listings. I've found a total of 129 listings, although JimG has flagged two of them as being terminally broken, and though I've already typed in Database Diary from the 1986 Sinclair User annual, it's a series of procedure-extensions for QL Archive that I can't get to work.

I'm going to concentrate on the games first, then the most useful utilities (such as UDG and character set defining programs), then the utilities that may have ceased to be of use to anyone a long time ago. I'll probably start by completing the ZX Computing listings, seeing as JimG's already tackled a few of these. On the archive page, I've indicated whether the listing can be used with a monitor, TV or both - in some cases, particularly from authors who clearly never owned a monitor, the listing won't run properly in monitor mode - JimG tried to correct one with a WINDOW statement because he thought the author had made a mistake, when all he needed to do was switch QLAYW to TV mode and everything would have been fine.

QL screenhots are taken at 512x256 (and now that I know QemuLator has a screenshot button that outputs this size, I'll probably make a few of them en masse), but I've displayed them "full size" with an HTML page that stretches them to 1024x688. This should be "about right" for the QL aspect ratio as I'm told it's supposed to be, and I'm not going to get OCD about different-sized pixels as Opera gives the Vaseline-screen treatment to anything that's upscaled, so there'd be no point in sticking to 1024x768.

Once I've typed in a few more listings and added them to the archive, I've got a couple of SuperBASIC projects I've been thinking of for a while - one is the conversion of the F.A. Cup simulation I've mentioned on my introductory thread, the other is a conversion of my hexadecimal and dozenal fraction converters which I wrote for the Spectrum, down-converted for the ZX81 to prove it could be done, and which I think will benefit from being ported to the QL. If it doesn't sound very interesting, think of it as a proof of concept. I might be 36 years late to the QL party, but I'd at least like to show I can add something.

There are several threads with QL User type-in programs - there is the one that you found and several others which contain "QL World mdv Exchange" in the thread name.
Also I already typed other programs, but still need to test them. I will publish them when I'll be ready.

Javelin was first published in 1985 as part of Penthatlete program (see https://www.theqlforum.com/viewtopic.php?f=3&t=3441 ) but in Pethatlete it has a bug. I will check the version you published and check if the bug was fixed in the listing published in ZX Computing 1986.

Andrew wrote:Javelin was first published in 1985 as part of Penthatlete program (see https://www.theqlforum.com/viewtopic.php?f=3&t=3441 ) but in Pethatlete it has a bug. I will check the version you published and check if the bug was fixed in the listing published in ZX Computing 1986.

Interesting. It seems to run OK for me - but I remember getting very excited when I timed a throw right, it sailed over 90 metres... and then I was told I didn't qualify for the next round! Is that the bug you mean? Also, it does say "mm" when the throw's recorded, and I may be no athlete, but I can definitely throw a javelin more than 90 mm even now.

My QL type-ins project continues and I've run into trouble that my limited QL knowledge won't be able to solve. It concerns user-defined graphics and redefined character sets, both of which I could find very useful, so I'm going to have to get it right. These are the two programs I've typed in so far, and there are more to come - but I think I need to solve the problems with these first.

Both packages include an .MDV file, the raw test _bas files, and the magazine pages. Consider this first one a temporary link which will be replaced by one on Mega once I've got this sorted.

http://www.rickdangerous.co.uk/zx/ql/ud ... wotnik.zip
UDG Designer by David Nowotnik, ZX Computing Oct-Nov 1985

https://mega.nz/file/JepAhAga#aL5pWiwQN ... 3jrzUCeAdo
QL Characters by Philip Smith, Sinclair User March 1985
"To return the characters use POKE_L 167722,41304."

David Nowotnik's program from ZX Computing is from the "QL Characteristics" article, which also contains a "Lunar Lander" program which I intend to add to the Games page on Spectribution once I've sorted this problem (essentially because it's made to demonstrate UDGs). The UDG program redefines the secondary CTRL-plus-key characters, CHR$ 128 to 190. Looking through the article, there is an implication - if not an outright statement - that the JM and JS ROMs might be different when it comes to storing and pointing to UDG code:

David Nowotnik wrote:The easiest way to find the start of a particular channel information block is to refer to another information block in RAM, which (in the 'JM' version, at least) starts at 166752. Using PEEK_L(166752) will return the start address of the channel information block; the same PEEK on addresses 166756 and 166760 will give channel 1 and channel 2 start addresses, respectively. As more channels are OPENed, their information block start addresses appear 166764, 166768, etc.

So, the vector to the 'extra' character bit pattern block in channel 2 is: PEEK_L(166760)+46, and PEEK_L of the resultant address will give the start address of the bit pattern block in ROM (unless you have changed the vector).

The fact that each channel has its own vector to the character bit patterns provides the QL with a very powerful feature. You can redefine characters for one channel only (or more if you want) whilst retaining the original ones for other channels. Or, you could have several blocks of UDGs, a different one for each channel!

So far in all my (emulated) QL computing I've used the JS ROM, so to get this working (because it didn't, to start with) I switched to the JM ROM.

ACHTUNG: NOOB QUESTION ALERT! What are the differences between the two?
Context: I looked on The All-Knowing Oracle called Wikipedia and that said the early ROM that required the dongle was 32 KB, whereas the JM ROM file I have is 48 KB. And, surely, by the time David Nowotnik wrote this program (mid-1985) nobody had to put up with the dongle anymore.

Anyway - I tried this program with the JS ROM first, defined a character that I know I'm going to need soon enough at CHR$ 181 - the curly question mark, i.e. the most useless character of all. I drew my character, listed the codes (to find that the bits are stored high-end-up, so "11111" on the screen is 124 rather than 31), but when the program printed the new character... it still displayed the curly question mark.

I have tried these commands on both the JM and JS ROMs after defining CHR$ 181:
FOR z=0 to 2: PRINT #z,CHR$(181): NEXT z

It prints the curly question mark in all three default windows, and none of them appear as the redefined character.

The way the QL goes about making UDGs is far more similar to the Spectrum's ability to redefine the character set, as I see it. And for those unfamiliar, the best way to do it is to POKE the character codes starting at a high memory value that divides by 256 (e.g. 64512, the highest available) - this takes 768 bytes, eight per character. Then, POKE 23607,251 to switch the new character set on, POKE 23607,60 to switch it off. As a general rule, if the character set is stored at address a, then POKE 23607,(a/256)-1 will activate it, POKE 23607,60 will always bring back the ROM characters - useful if not all the new characters are defined, or if you get the value wrong and a load of indecipherable shash appeares instead.

I get the impression that David Nowotnik's program has left out the equivalent of the Spectrum POKEs, i.e. that there should be a line 645 that starts with POKE (or POKE_L?) that switches the UDGs onto the screen that they're printed on (channel 2 in this case), and then in line 675, a POKE that switches it back to the regular curly question mark.

And the reason that I get this impression is because I went back to the other program I'd typed in April, Philip Smith's character set definer. This does have a POKE in there, supposedly that switches the redefined character set on, but again I see no difference, whether I use the JM or JS ROM. David Nowotnik's program initially copies the 128-190 character set to a new area of memory, Philip Smith's doesn't do the same for the standard 32-127 character set, so I assume that's why each character starts off as a load of shash in the defining area when the program runs. It's also very tricky to use, running far too fast. And strangely, when I tried it on QemuLator, it failed because for some unfathomable reason, QemuLator had decided that 'ex' in lines 180 and 210 was supposed to be a keyword and it broke the code, so I had to change it to something else ('qx' in the end) to make it work. QLAY didn't do this.

It does look to this raw beginner as if UDGs and custom character sets are defined in exactly the same way, but it is still as clear as mud how they're switched on and off. Is there anything fishy going on in these two listings? I have checked them so that what you see on the _BAS file exactly matches what's in the magazine (variable 'ex' excepted as above), and all I know is that they don't work the way I was expecting, and I am already out of ideas as to how they might be fixed.

Also, if the addresses that need to be used are different for the JM and JS ROMs, I'll need to know that.

Instead of messing about with POKE's. You might want to look at Toolkit 2. I has a CHAR_USE command for redefining fonts for particular channels.
See section 14 of the Toolkit 2 manual.

A problem you will probably find is that two UDG's don't join up at the edges, and leaves a gap. There is a CHAR_INC command to help here.

You could also try Turbo's "Utilities_task", which includes a font editor.
ex would be the toolkit 2 EX command - a replacement for EXEC.

EmmBee

Martin_Head wrote:A problem you will probably find is that two UDG's don't join up at the edges, and leaves a gap. There is a CHAR_INC command to help here.

The next program I typed in shows that - although I was prepared for it, because the UDG definer program produced a 9x5 grid and I can see QL characters are six pixels wide. Now, see below...

EmmBee wrote:ex would be the toolkit 2 EX command - a replacement for EXEC.

That explains that, then... and also...

I've updated the QL Games and Utilites pages with a few more titles, and I've been able to correct a couple of screenshots. One of them was Santa's Dilemma - why were all the characters coming up as accented lower-case characters? Well, now I've solved the mystery, or at least I've shed some light on it. Here's the new package:

https://mega.nz/file/9Th0zLyJ#5Z9A_EWTO ... 0gek3P4obM

This contains the UDG Designer, and Lunar Lander, which uses UDGs. I was quite annoyed when I typed this one in (on Notepad++ this time), loaded it into QLAY and the standard accented lower-case letters were still there. What was going on? I tried the JM and JS ROMs, and neither made a difference. But I tried it in QemuLator, and strike me down with a feather from the world's tiniest bird, the UDGs displayed!



And it was at this point that I noticed there were two ROMs, and it was the second ROM that was different between the two emulators. QLAY used NFA.ROM and QemuLator used TK2_ROM, and I've already twigged that was Toolkit II.

So I took another look at Santa's Dilemma, and what do you know, there was a small, red figure chasing what looked like blue reindeer round a pine forest, rather than some scattered foreign characters.



Can I assume that NFA.ROM is older than Toolkit II, and will either not accept UDGs, or they have to be poked at a different address, or the pointer has to point elsewhere? (The only Spectrum equivalent I can think of is the different values read by the IN function for the keyboard, depending on whether it's Issue 2 or Issue 3.

Anyway, with Lunar Lander working, it has a UDG-poking routine that's similar enough to the Spectrum that I can just about understand it - the RESPR function is not something I'm up to speed with yet, the addresses that the characters are being poked to is still a bit of a mystery, but it does have a FOR...NEXT loop that pokes values in sequence to a series of addresses which correspond to UDGs, and carries the values in DATA statements afterwards, nine per line, all divisible by four. At this point, I can experiment a bit to see if I can get UDGs to appear on different channel numbered screens, and note how that's done. For now, maybe I'll get a few more type-ins up and running, and hope I don't crash into any more such problems.

QLAY and QL2K need the NFA.ROM for emulating file access, SER and PAR ports and the like. This ROM is usually located at $C000. Qemulator doesn't need this as the functionality is already built-in.

You can specify Toolkit II as a second ROM in QLAY/QL2K at address $C0000 (note 4 zeros rather than 3). In fact, the JS ROM allows for up to 16 extension ROMs at $C0000-$FFFFF (JM only allows one due to a bug, and Minerva allows for two extra extension ROMs at $10000 and $14000 in addition to $C000 and $C0000-$FFFFF).

Jan

QL Characters by Philip Smith, Sinclair User March 1985
"To return the characters use POKE_L 167722,41304."

I have not tried to find out what the POKE_L 167722,41304 does. But it's way past the system variables, and probably in the common heap.

I would guess that it's trying to directly alter the channel definition block for either channel #0, #1, or #2. This is not a good idea, as there is no guarantee that the address of the channel definition blocks will not move. It depends on the ROM version, if the channel been closed and re-opened, if the extended environment has been loaded, and probably other things that I have not thought of.

Each channel has it's own definition block, with pointers to the fonts that the channel will use.

I seem to remember, a very long time ago, converting a program that POKEd the channel blocks for UDG, to use CHAR_USE instead.

Link to an article on my website about QL fonts and how to use Toolkit 2 extensions to link in new fonts etc without the problems caused by those POKE_L commands in many old listings. http://www.dilwyn.me.uk/docs/articles/funfonts.zip