Peeking/Poking pixels directly

Helpful tips and guides, also new users can ask for help here.
Post Reply
lowrybt
Chuggy Microdrive
Posts: 70
Joined: Wed Apr 16, 2014 4:56 pm

Peeking/Poking pixels directly

Post by lowrybt »

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


stephen_usher
Gold Card
Posts: 429
Joined: Tue Mar 11, 2014 8:00 pm
Location: Oxford, UK.
Contact:

Re: Peeking/Poking pixels directly

Post by stephen_usher »

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


Derek_Stewart
Font of All Knowledge
Posts: 3928
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Peeking/Poking pixels directly

Post by Derek_Stewart »

Hi,

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

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


Regards,

Derek
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Peeking/Poking pixels directly

Post by tofro »

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
lowrybt
Chuggy Microdrive
Posts: 70
Joined: Wed Apr 16, 2014 4:56 pm

Re: Peeking/Poking pixels directly

Post by lowrybt »

Many thanks.


User avatar
ql_freak
Gold Card
Posts: 353
Joined: Sun Jan 18, 2015 1:29 am

Re: Peeking/Poking pixels directly

Post by ql_freak »

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.)


http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX :-)
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Peeking/Poking pixels directly

Post by mk79 »

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.


Post Reply