C68 and IOP.PINF

Anything QL Software or Programming Related.
Post Reply
User avatar
Peter
QL Wafer Drive
Posts: 1987
Joined: Sat Jan 22, 2011 8:47 am

C68 and IOP.PINF

Post by Peter »

Hi,

to check if the pointer environment is loaded, I try to use Trap #3, D0 key $70 (IOP.PINF) with C68. In priciple, this should be doable with either qdos3() as a general Trap #3 function with D0=$70, D3=0 and A0=0 preset, or directly with iop_pinf() from the C68 library.

But in both cases I get a return (D0) value of -1 (ERR_NC) if the PE is loaded, and -15 (ERR_BP) if not. And D1 which is supposed to hold a four byte ASCII string with the version, contains crap. Not even the same crap for qdos3() and iop_pinf(). Surely not what the PE wants to tell. Also I tried some timeout values (D3) other than 0 to maybe get rid of the ERR_NC, but that didn't help.

I have tried native C68 in the latest and an older version, also the original Jonathan Hudson XTC68. Targets were Minerva on Q68 and Qemulator.

I vaguely remember that qdos3() was buggy at some time, but then at least iop_pinf() should work.

It's likely my own fault as I get older, but I have checked my parameters several times and all seems right. Any idea?

Peter


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

Re: C68 and IOP.PINF

Post by tofro »

If I recall correctly, d3 is a timeout and should be -1 - if you hand it a 0, "not complete" doesn't look like an error to me.

C68 iop_pinf implementation is a bit of a trap because it returns a void*, which can never be negative, see here.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1987
Joined: Sat Jan 22, 2011 8:47 am

Re: C68 and IOP.PINF

Post by Peter »

tofro wrote:If I recall correctly, d3 is a timeout and should be -1 - if you hand it a 0, "not complete" doesn't look like an error to me.
Some docs say so and that's what I tried first, but then both qdos3() and iop_pinf() block for ages. UQLX for example uses D3=0 when it checks for PE and that's probably for a reason.
tofro wrote:C68 iop_pinf implementation is a bit of a trap because it returns a void*, which can never be negative, see here.
I was aware and had a typecast already. The code posted in your link just hangs for me.


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

Re: C68 and IOP.PINF

Post by tofro »

Peter,

the code (with the type cast) in the linked thread works fine for me on Q68, QPC and the original QL - It is a direct excerpt from the Magnetic Scrolls interpreter.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1987
Joined: Sat Jan 22, 2011 8:47 am

Re: C68 and IOP.PINF

Post by Peter »

Hi Tobias,

which version does EX C68;"-v" tell? Version 4.5 here.

Peter


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

Re: C68 and IOP.PINF

Post by tofro »

Peter wrote:Hi Tobias,

which version does EX C68;"-v" tell? Version 4.5 here.

Peter
Same here. I can't recall, however, whether I did upgrade to some newer libraries in the past.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
QL Wafer Drive
Posts: 1987
Joined: Sat Jan 22, 2011 8:47 am

Re: C68 and IOP.PINF

Post by Peter »

Still can't figure it out. As so often in QL development, even simple things tend to recurse from problem to next problem. Could you imagine that the difference is elsewhere, not in C68 and it's libs?


Post Reply