[Coco] GFX2("DEFBUFF"

coco at jechar.ca coco at jechar.ca
Tue Mar 2 07:47:38 EST 2021


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.


More information about the Coco mailing list