[Coco] GFX2("DEFBUFF"

[L. Curtis Boyle]

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
>