[Coco] GFX2("DEFBUFF"

[coco at jechar.ca]

Is RUN GFX2(“ID”,idnum) also supported in the most recient versions of
Nitros9 ?

On 2021-03-02 10:25, L. Curtis Boyle wrote:
> Since I know that you are using EOU, you have the extended GFX2, you
> can use RUN GFX2(“ID”,idnum) (idnum is whatever INTEGER variable you
> want your process ID number stored in).
> 
> And yes, you error trap the KillBuff if there are no get/put buffers
> in your group already defined (I put this in all of my graphics
> programs, as I have no idea if 1) any previous programs used buffers
> and didn’t clean up after themselves on exit or 2) a program that used
> buffers was aborted and didn’t have a chance to clean up after itself
> (like via KILL <Id> from the SHELL).  So I always do it at the
> beginning, just to be sure. If you don’t, then you can’t make a buffer
> larger than the previous program defined it as).
> 
> Sent from my iPhone
> 
>> On Mar 2, 2021, at 6:47 AM, coco at jechar.ca wrote:
>> 
>> 
>> Thanks very helpful.
>> 
>> The code you provided did not initially work however by removing line 
>> 7.
>> RUN gfx2("killbuff",4,1)
>> from the code the result worked great.
>> 
>> I see what you were getting at and Line 7 could be reinserted if the
>> proper error trapping is added.
>> 
>> Also, I was wondering what call I could do to get "buffy's" process ID 
>> so
>> that I could use that as the buffer number rather then the arbitrary
>> buffer #4.
>> 
>> Charlie.
>> 
>>> On 2021-02-28 16:30, L. Curtis Boyle wrote:
>>> I had some bugs in my off-the-cuff code - the biggest being is that I
>>> had you using the syscall with I$GetStt ($8D) instead of I$SetStt
>>> ($8E), so the program was actually getting an illegal service request
>>> error (and I was also not trapping errors from Syscall, which didn’t
>>> help at all either).
>>> Here is a revised program that should work (it worked here). I did 
>>> put
>>> some remarks in the program for you reference - the start address
>>> shown in GPMAP includes the 32 byte ($20) Get/Put buffer header; the
>>> SS.MpGPB call we are using returns the pointer to the actual buffer
>>> contents (it skips that first 32 bytes). So if you want to manipulate
>>> the header (like screen type, X/Y sizes, etc.), you will have to go 
>>> 32
>>> bytes earlier then the address it gives you back. Same goes with 
>>> size;
>>> it returns the size of the data itself (128 bytes in this case), NOT
>>> including the header (GPMAP will show the buffer size as 128 bytes,
>>> but if you look at the address range, that calculates to being 160
>>> bytes, since it includes the header in the address range).
>>> Let me know if this works for you, or if you have any questions.
>>> Sorry for the delay.
>>> PROCEDURE buffy
>>> TYPE registers=cc,a,b,dp:BYTE;x,y,u:INTEGER
>>> DIM regs:registers
>>> DIM curptr,gpptr,gpsize:INTEGER
>>> DIM response:STRING
>>> (* Kill any existing group 4,buffer 1 first
>>> RUN gfx2("killbuff",4,1)
>>> (* allocate new buffer
>>> RUN gfx2("defbuff",4,1,128)
>>> gpptr=0
>>> gpsize=0
>>> RUN GetGPAddress(gpptr,gpsize)
>>> ? USING "'The ADDRESS of group 4, buffer 1 is:',H4",gpptr
>>> ? USING "'The SIZE of group 4, buffer 1 is:',H4",gpsize
>>> (* Code that deals with the buffer goes here. Please note that the 
>>> address
>>> (* returned above is to the Data in buffer, and does not include the 
>>> 32 byte
>>> (* header (which GPMAP includes)
>>> (* Sample code:
>>> FOR curptr=gpptr TO gpptr+gpsize-1
>>>  ? USING "H2,X1",PEEK(curptr);
>>> NEXT curptr
>>> INPUT "Press <ENTER> to unmap buffer:";response
>>> (* map the buffer back out
>>> (* Std Out
>>> regs.a=1
>>> regs.b=$84
>>> (* group & buffer numbers
>>> regs.x=$0401
>>> (* Map it out of our userspace
>>> regs.y=0
>>> RUN syscall($8e,regs)
>>> END
>>> PROCEDURE GetGPAddress
>>> PARAM gpptr,gpsize:INTEGER
>>> TYPE registers=cc,a,b,dp:BYTE;x,y,u:INTEGER
>>> DIM regs:registers
>>> (* Std Out
>>> regs.a=1
>>> (* SS.MpGPB SetStat call #
>>> regs.b=$84
>>> (* group & buffer numbers
>>> regs.x=$0401
>>> (* Map it in (regs.y=0 to map it back out again)
>>> regs.y=1
>>> RUN syscall($8e,regs)
>>> IF LAND(regs.cc,1)<>0 THEN
>>>  ? "Error #";regs.b;" trying map buffer in"
>>> ENDIF
>>> gpptr=regs.x
>>> gpsize=regs.y
>>> END
>>>>> On Feb 28, 2021, at 9:46 AM, coco at jechar.ca wrote:
>>>> Yes runing EOU
>>>> I get
>>>> Bk Offsets    GP BN Use     STY    Size
>>>> -- ---------  -- -- -------------------
>>>> 18.0600-069F  04 01 program 4   0 x 0
>>>> 18.06A0-073F  CD 10 stdpt16 5  32 x 8
>>>> 18.0740-07DF  CD 0F stdpt16 5  32 x 8
>>>> .... Plus many more entrys from
>>>> GPMAP
>>>> I am trying to reserve 128 bytes in GROUP 4 Buffer 1 it
>>>> looks like I have 0 x 0 bytes.
>>>> I am afraid to trust the returned address as this other seems
>>>> wrong and I have no idea what address to expect.
>>>> Do you know if Basic09 programs put all of there code in the lowest 
>>>> addresses
>>>> and then the variables ?
>>>> Charlie.
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>>