QStar1 revisited - High Colour mode

[Tinyfpga]

No "ghost" windows now. Thank you.
Not that it is of any consequence, but killing Qstar with Rjob, causes my set uo to crash but not immediately. I have to do something after Rjobing for this to happen. Killing Qstar the normal way, ie. from within the game, works fine. Could it have something to do with something that I have LRESPRed that you have not?
I will compare your setup with mine.
I have just noticed another game you wrote and will be trying that one out at some point.

[Andrew]

I have just noticed another game you wrote and will be trying that one out at some point.

There are 5 games: 2 adventure games (PI Cole 1 and 2) and 3 logic puzzle ganes (QStar1 and 2 and Pitman)
PI Cole games work only in Mode 4
QStar1 and Pitman work in (almost) all modes
I will release soon the High Colour version for QStar2

[pjw]

<>

Code: Select all

100 REMark access Console Linkage Block
110 CLS
115 PRINT'ITEM' TO 18;'SBASIC' TO 30;'FROM BLOCK'
120 sysbase=VER$(-2) : REMark system bvariables
130 sys_clnk=$C4 : REMark LONG pointer to console linkage
140 blk=PEEK_L(sysbase+sys_clnk):REMark pointer device driver definition block
150 PRINT 'SCR_BASE=' TO 18;SCR_BASE TO 30;PEEK_L(blk+$E8)
160 PRINT'BYTES PER SCREEN=' TO 18;SCR_LLEN*SCR_YLIM TO 30;PEEK_L(blk+$EC)
170 PRINT'SCR_LLEN=' TO 18;SCR_LLEN TO 30;PEEK_W(blk+$F0)
180 PRINT'SCR_XLIM=' TO 18;SCR_XLIM TO 30;PEEK_W(blk+$F2)
190 PRINT'SCR_YLIM=' TO 18;SCR_YLIM TO 30;PEEK_W(blk+$F4)

Hi Dilwyn,

No offence intended! I was just venting a bit of heat, and my ill tempered comment was a scattershot; you werent being singled out. In fact you have frequently complained along the same lines..

I agree with your analysis above. This, sans the inline hex numbers, is how one could do it in Qdos. For SMSQ/E I prefer to use the native PEEK(\\) format.

I just checked your hypothesis that if no PE is present then 'blk' will be zero. In Qdos JS, at least this seems to be correct. However, since there doesnt appear to be a regular way of knowing how big the systems variables table is across the various systems (sysvars + $C4 might point into the void) it cant be a reliable way to test for the presence of PE, only the iop.pinf trap is.

[dilwyn]

Hi Dilwyn,
No offence intended! I was just venting a bit of heat, and my ill tempered comment was a scattershot; you werent being singled out. In fact you have frequently complained along the same lines..
I agree with your analysis above. This, sans the inline hex numbers, is how one could do it in Qdos. For SMSQ/E I prefer to use the native PEEK(\\) format.
I just checked your hypothesis that if no PE is present then 'blk' will be zero. In Qdos JS, at least this seems to be correct. However, since there doesnt appear to be a regular way of knowing how big the systems variables table is across the various systems (sysvars + $C4 might point into the void) it cant be a reliable way to test for the presence of PE, only the iop.pinf trap is.

Caught me at a bad time, a tiny little straw which broke the camel's back in a weak moment, that's all, after a day spent trying to help people out. In fact, I had quickly searched the Forum for anything on the subject but the Forum's search didn't turn up anything relevant from what I entered as a search. I don't always get time to read everything either, so ...

Since writing, I looked in the QDOS/SMSQ Reference Guide, here's what Wolfgang had to say about sys_clnk:

sys_clink (QDOSMSQ Ref Guide)

Much to my surprise, the value '0' should be in sys_clnk according to Wolfgang for non-SMSQ/E systems. But he implies doubt about it being used by some versions of ptr_gen/wman, presumably he means older ones.

Using iop.pinf is what extensions that test for pointer environment do, including PTR_ENV in my display extensions. It's just that as with anything else when it comes to QDOS you need extensions.

PEEK(\\...) - as with many things, a simple IF VER$='HBA' could help a program take the better option where it exists, or fall back on simple PEEKs if not.

[bwinkel67]

I have just noticed another game you wrote and will be trying that one out at some point.

There are 5 games: 2 adventure games (PI Cole 1 and 2) and 3 logic puzzle ganes (QStar1 and 2 and Pitman)
PI Cole games work only in Mode 4
QStar1 and Pitman work in (almost) all modes
I will release soon the High Colour version for QStar2

We have ourselves an active game developer in the QL world

I've been looking at source code for the various Elite implementations for BBC Micros and C64s. Unfortunately, though I have coded in assembly, game programming is a bit of a stretch for me, as I usually just write utility routines that then get integrated into BASIC (ZX81) or with a C complication (past professional life).

Is most of your game work in compiled S*BASIC with toolkit routines to help with graphics (i.e. MOVE command)?

[Andrew]

Is most of your game work in compiled S*BASIC with toolkit routines to help with graphics (i.e. MOVE command)?

Yes.
But for more complex games I should use C. The problem is I forgot C. It's been 30 years since I last wrote anything in C.