OK, so translated to roughly plain english for us lesser mortals, would I be on the right track using code like this to write a pair of extension functions for SuperBASIC like this:
pointer_environment = PTR_ENV(#channel) gd2_drivers = GD2(#channel) PTR_ENV being a function to return 1 if PE present, 0 if not. move.w #-1,d3 ;timeout ;find channel ID for window number passed and put in a0 move.w #$70,d0 trap #3 ;iop.pinf ;d0=0 means ptr env installed - return value of 1 ;d0=err.bp (bad parameter) no pointer environment - return value of 0 GD2 being a function to return 1 if GD2 installed, 0 if no GD2, so after a call to PTR_ENV IF PTR_ENV(#0) = 1 THEN gd2_drivers = GD2(#0) END IF clr.w d0 ;position in linkage to set clr.w d2 ;no bytes to be set (read only) moveq.w #-1,d3 ;infinite timeout ;find channel ID for window number passed and put in a0 clr.l a1 ;pointer to data to set, in this case none as it's read only move.w #$6f,d0 ;iop.slnk ($6f=dec.111) trap #3 tst.w d0 ;any error such as channel not open bne.s oops ;oh dear, an error move.w #$128,d7 ;offset $128 in PE linkage block move.l 0(a1,d7.w),d6 cmpi.l #"PTR2",d6 bne.s no_gd2 yes_gd2 ;return value of 1 to S*BASIC no_gd2 ;return value of 0 to S*BASIC oops rts ;return to S*BASIC with error message This is completely off the top of my head with no testing, no real knowledge of what i'm doing, but filled with hope someone will read this and either complete it into something workable or at least tell me what i'm doing wrong! Norman...instead of being out in the snow, here's your next QLT assembler project! (Having written the original display_code extensions for QL Today giving S*BASIC programmers a means of testing for extended resolutions etc, I hope this can be turned into an extension of that project perhaps, as that contains the necessary assembler routines for finding channel IDs and returning function values...hopefully wouldn't be too difficult!) -- Dilwyn Jones ----- Original Message ----- From: Marcel Kilgus <[EMAIL PROTECTED]> To: ql-users <[EMAIL PROTECTED]> Sent: Saturday, February 01, 2003 2:33 AM Subject: Re: [ql-users] Detecting GD2 Drivers > > [EMAIL PROTECTED] wrote: > > OK, looking at the smsq/e sources (must remember to update mine), > > this is a longword at offset $128 within the pointer device driver > > definition block (if set to # 'PTR2' then GD2 colour modes are > > present. > > Exactly. > > > 1) I have looked at the QPtr documentation and cannot see how to find the > > start address of the pointer device definition block - I thought IOP.PINF may > > help, but does not seem so. Maybe I am just barking up the wrong tree > > altogether here. > > The easy way under SMSQ/E: read sys_clnk. > The generic way: use iop.slnk with d2 = 0. A1 is then the address of > the block. > > > 2) Does this indicate that GD2 is available (and you can therefore use > > commands such as DISP_COLOUR 3 to invoke it, or does it signify that the > > current program is using GD2 colour definitions already). > > It only says that there is a GD2 driver available. To check whether > you're currently within a high colour mode DISP_TYPE can be used. In > high colour modes it simply returns the mode number (i.e. 16, 32 or > 33). > > > Sorry for being such a pain, but the SMSQ/E documentation is harder to > > understand than I would have liked!! > > I know, you're not the only one who has sometimes problems with that > :-) In some cases it's even plain wrong or at least misleading (QPtr > especially). Therefore the best documentation is the source itself. I > for example don't know stuff like your VER$ question either, but in > this case I just had a look at the actual VER$ code (SBasic commands > are usually in sbsext_ext). I also did a complete FiFI run (looking > for 'HBA') over the whole sources, just to be sure, which returns > smsq_sbas_version_asm. After having a look at that, one subsequently > searches for sb.vers and sb_vers etc. > > Marcel > >
