The Sinclair QL Forum

Years ago, I coded a version of Atari's popular Lunar Lander arcade came for use on Ohio Scientific (OSI) C1P/UK101 and OSI C4P, in BASIC running on a 2Mhz 6502. I'd like to port the program to the QL for the fun and challenge of it. Having never written a program in SuperBASIC (I used my QL back in the day for writing research papers, keeping budget spreadsheets, and playing Tankbusters), I have some question about the allocation of display memory:

1) For mode 4, is the allocation of addressable screen memory (each pixel) set in absolute terms, meaning always allocated to start (0,0) and end (512,256) at fixed/unchanging values whatever the maximum installed memory of the system
1a) If so, where can I find that information?
1b) If not, are there hi/lo memory locations that can be Peeked to find the boundaries assigned to screen (pixel) memory and pixel-color memory?
My existing code uses look-ahead peeks to determine if the lunar module is about to hit an object

2) What's the best resource for figuring out how to integrate and move sprites (lunar module representations built at the pixel level) in a SuperBASIC program?

Thanks, Tom

Under QDOS the first screen starts at $20000 always.

Seeing as Sinclair used part of the second screen memory for system variables it's highly unlikely to be used.

In mode 4 you effectively have contiguous "raster" lines with pairs of bytes containing a bitmap of 8 pixels, the first byte is "red" and the second "green". "red" + "green" = "white'. i.e. you have 64 pairs bytes of "red" and "green", each containing 8 pixels, per line.

The information is in the original QL User Guide.

You can get everything from: http://www.dilwyn.me.uk/docs/index.html

Hi,

The QL Technical Guide on the QL Homepage gives more detailed information.

There is some sprite systems for QDOS, wlhich freely available.

Well, at least with a Minerva ROM the start address of the screen can vary between $20000 and $28000 (with standard ROMs, this is fixed to $20000), so programs playing nice tend to retrieve the screen start from a screen channel definition block - This also makes it a bit more probable your program will run on extended machines or Emulators.

Standard SuperBASIC makes it a bit difficult to PEEK this information, as "everything is floating" in the QL's memory. There's a number of toolkits that allows simple retrieval of this information using a bit of machine code, notably Dilwyn's "display_cde"

Once you're looking into SuperBASIC extensions (Toolkits), you could simply decide you'll save yourself from the hassle of finding the proper addresses and use DIY toolkit volume "G", that comes with a PIXEL% command to allow you to directly read the pixel color on a specific screen coordinate.

Tobias

Many thanks.

If you want to use the screen memory directly, you MUST NOT POKE directly into the screen memory!

If you do it, QDOS (SMSQ/E) doesn't get any notice of it. Those programs are not multitasking capable. If you want to use the screen memory directly, you have to use SD.EXTOP. This Trap allows to write to screen directly in a way, so that QDOS "gets" it, and the program can multitask in QDOS. (May be difficult in high resolution modes of QPC2 -I DUNNO if the high resolution mode supports this trap - ask Marcel.)

What Peter writes is true, well behaved programs use SD.EXTOP (or IOW.XTOP in SMSQ/E parlance). But then most games have never been well behaved and in any case, the call is not usable from Basic, it could be employed by a sprite library for example. Unfortunately I'm not aware of a comprehensive sprite engine for games (and even if there was one, it'd probably be equally unbehaved), so if this is just a for-fun project, poke away. If you want it a bit cleaner, use a library that tells you screen base and screen pitch at least.