[Coco] data modules

[Dave Philipsen]

What is the system call that is being used to allocate the memory?

Dave


On 6/9/2017 8:11 PM, Bill Pierce via Coco wrote:
> Dave, once you allocate a get/put buffer, it remains in memory until it is killed. As long as the group# & buffer# is publically known, any module can access it.
> I'm talking about full 8k buffers, not partial buffers used for graphics. The cool thing is can expand and contract as needed, up to the amount of free memory.
> I pass data back & forth from different modules in MShell as well as keep LARGE directory structures in memory. All it takes to access a record in the buffers is the index# to the record. The parser does the rest and returns the pointer to the data.
> You would really have to see all this in operation to understand it.
>
>   
>
>   
>
> Bill Pierce
> "Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
>
> E-Mail: ooogalapasooo at aol.com
>
>   
>
>   
>
> -----Original Message-----
> From: Dave Philipsen <dave at davebiz.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Fri, Jun 9, 2017 9:04 pm
> Subject: Re: [Coco] data modules
>
> Well, I guess it just depends on exactly why you need a data module.  If you load the data module in at boot time or include it in the OS9Boot file then there wouldn't be any delay in loading it and it would be accessible just as quickly as you could access user memory in any process.How would you propose using get/put buffers?  Pretty much the only reason for using a data module would be for that data to be accessible to multiple processes.DaveOn 6/9/2017 7:46 PM, Bill Pierce via Coco wrote:> Using get/put buffers is much easier and requires no drive access, as well as being faster.>>   >>   >> Bill Pierce> "Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull>> My Music from the Tandy/Radio Shack Color Computer 2 & 3> https://sites.google.com/site/dabarnstudio/> Co-Contributor, Co-Editor for CocoPedia> http://www.cocopedia.com/wiki/index.php/Main_Page>> E-Mail: ooogalapasooo at aol.com>>   >>   >> -----Original Message-----> From: Dave Philipsen <dave at davebiz.com>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>> Sent: Fri, Jun 9, 2017 8:44 pm> Subject: Re: [Coco] data modules>> I don't think there's really much to a data module other than setting the attributes correctly.  It's purpose would be to share common data among multiple processes.  The format of the data module would be entirely up to the creator of it.  As long as all processes that will use the data module understand the format then the data is organized in any way you want and each process would know how to access it.In Peter Dibble's notes he states that a rather annoying problem with data modules is that they must always be loaded from disk as there is no method for a process to create a memory module. However, by the time version 2.3 rolled around (OS9/68k) there was a system call where a process could actually create a data module without actually loading it from disk.One other note of interest is that for a data module to be used by multiple processes it would have to
> have to be made  're-entrant'. Usually, that term would imply re-entrant executable code but in the case of a data module it would allow the system to map that module into the address space of multiple processes that may link to it. In Level 1 this wouldn't be necessary as everything is done within the confines of 64k and there's no MMU; a link to a data module would just retrieve the location of that module in the 64k address space.  However in Level 2 the system must manipulate the MMU for every process that links to the data module so that it is mapped into that process' memory space.DaveOn 6/9/2017 6:54 PM, Stephen H. Fischer wrote:> While searching for Datamod I found it where I should have looked first, the one place stuff from Delphi / CI$ might be.>> 1998> ftp://www.rtsi.com/OS9/OS9_6X09/APPS/datamod.lzh>>> 1994> ftp://www.rtsi.com/OS9/OS9_6X09/APPS/DataMod.lzh>> IZArc will open the lzh files on Windows 7.>> SHF>>> ----- Original Message -----> From: "Wayne Campbell" <asa.rand at gmail.com>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>> Sent: Friday, June 09, 2017 12:33 AM> Subject: Re: [Coco] data modules>>>> Tell me where to>   look, Stephen, and I will search for it.>>>> On Thu, Jun 8, 2017 at 8:33 PM, Stephen H. Fischer <SFischer1 at mindspring.com>>> wrote:>>> Here is one example I used a lot.>>>>>> Problem, Shellplus will not pass parameters like you can with a normal>>> text script.>>>>>> ------------------------------------------------------>>> DataMod v1.1 (c)1988 by Ron Lammardo>>> Shellscript/Data Module Conversion Utility>>>>>> Syntax:>>>     datamod {modname} <{pathin} >{pathout}>>>      Takes a shellscript from the standard input path and converts>>>      it to a Data Module written to the standard output path.>>>      The {modname} will be used as the module name.>>>>>>     datamod -<{pathin} >{pathout}>>>      Takes a Data Module from the standard input path and writes>>>      it to the standard output path as a shellscript.>>>>>>     datamod -m {modname} >{pathout}>>>
>   Takes a Data Module in memory and writes it to the standard>>>      output path as a shellscript.>>>>>> ------------------------------------------------------>>>>>> I have the Delphi posted version likely from 1988-1989.>-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco>-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco
>