[Coco] Absolute Memory Location

Bill Pierce ooogalapasooo at aol.com
Sun Aug 16 05:40:24 EDT 2020


Actually, there is a way to share a memory space between modules in OS-9 L2, and it doesn't matter if the modules were linked, chained, forked or run individually. BUT... there is a cost.
You can use the get/put buffers. The cost is you MUST reserve 8k of space within your workspace on each module using the feature.
You don't use the buffers as graphics buffers, but link them in manually with a VERY small amount of code consisting mostly of SetStat calls. Using the proper calls, you allocate the memory, then map it into your workspace and you have up to 8k of data space to preserve ANYTHING you want. Then this buffer can be accessed by any program on the machine as long as it hasn't been "killed".
How to do this?
First, when allocating a buffer, you must provide a group# and buffer# which are unique to any other "used" buffers. There are several ways to do this, but the best way I've found is to use a higher number (up to 255 I think) for the group# as most programs use their process ID as the group#, but you want a constant that will be known by any program using the buffer so a random # wouldn't work in this case. For multiple 8k blocks, you use one common group# and increment the buffer# with each call.
Once the buffer is allocated, OS-9 will preserve this buffer space until Something "kills" it. You can exit the program completely and do things all day, and come back 12 hours later, map the buffer back in and it's contents will be intact. Of course you can't exit OS-9 or cut off the Coco.
The trick is to use the same constant group#/buffer# with any module accessing the buffer.
The buffer is only allocated once. After that, to access it from another program, just call it by it's group#/buffer# and you can access it's contents. You can even chain multiple buffers together (each is 8k). Load one in, fill it up, map it out, map in another, fill it up, etc. The trick is knowing the group#/buffer# for each block allocated. These will remain intact until one of the programs "kills" (deallocates) it/them.
Again, this requires 8k of memory to be reserved INSIDE your 64k workspace and the address of this space must remain constant at all times.
I know reserving 8k is not ideal in Basic09's limited memory constraints (the very reason I do not use Basic09), but it can be done.
This is the very method my MShell project uses to pass massive amounts of data (sometimes as large as 1.5 meg on a 2 meg machine) between it's many program modules.
There are a lot of little quirks and tidbits to this method, but it does work and it's FAST. It's kind of like creating a ramdisk on the fly, then killing it when you don't need it... but easier.


-----Original Message-----
From: coco at jechar.ca
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sat, Aug 15, 2020 9:45 pm
Subject: Re: [Coco] Absolute Memory Location

Trying to implement some inter-process communication was hoping
to not have to settle for having to write to a temporary disk
file and then read it. It seems there should be some memory only
way to pass info.

NOW THIS IS FANTASY but it is the sort of thing that would be
useful.

For example if there was a function like this:

DIM block:BYTE
DIM rokey$,rwkey$:STRING[200]

RUN BUFFS("CREATE",block,rokey$,rwkey$)

Where block,rokey$ and rwkey$ cannot be set but only read
except that if rwkey$="NO" means that no other process can
write to the memory.

Then if you say

returnval$="UNPROCESSED"
key$=rwkey$
SHELL "someProgram "+returnval$+key$

in "someProgram" say your code assigns returnval$="NEW VALUE"

looping through
BPOKE key$,address,bytevalue

Where BPOKE lets you poke into the buffer with the given rwkey

There would also be a x = BPEEK(key$,byteval) where key$ may be
either rwkey or rokey

Of course the OS would have to manage the keys to make sure that
there were no duplication although duplication would be unlikely
in a 200 character key.

Also If the key is to be so long there should be some way that the
first time the key is checked by BPEEK or BPOKE and checks out as
ok then additional calls from the same process do not need to recheck.

Also note valid values for address would be 0 to 8191 since these
buffers are 8K blocks.

Finally RUN BUFFS("CLOSE",block)
where you can only close the block if you opened it in the
first palace.

But of course RUN BUFFS() , BPEEK and BPOKE are a FANTASY.

I think  I heard of something called "NAMED PIPES" that might
work if OS9 has them.

On 2020-08-15 19:40, Rick Ulland wrote:
> Not really.
> 
> Really.
> 
> In EDECB you have LPOKE, but there you own the machine and are free to
> crash it. Basic09 runs underneath the OS9 system - you do not know
> what is going on outside your process space and are not free to change
> anything out there. You can hack some things. Your users will hate
> you.
> 
> This might be the X=Y problem. What are you wanting to do that
> requires smashing an absolute memory location to a fixed value from
> inside Basic?
> 
> -rick
> 
> 
> 
> On 8/15/20 4:27 PM, coco at jechar.ca wrote:
>> 
>>  Is there any assembly program or syscall that can let you
>>  put values in an ABSOLUTE location ( Specified MMU bank and
>>  ADDRESS ). This program would need to be callable from Basic09.
>> 
>>  Charlie.
>> 

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco


More information about the Coco mailing list