[Coco] data modules

Sat Jun 10 02:18:14 EDT 2017

Hmmmm....I could be wrong but I don't see how the type or length of the data has anything to do with it.  I can put 3 beers, 2 bags of chips and a package of hot dogs in a grocery bag or I can put six dozen eggs in it.  The data module is merely a 'grocery bag' and so is the get/put buffer.

I don't think the structure of the data module itself will facilitate the management of who gets to write, how simultaneous writes are arbitrated, etc. You'll have to figure that out yourself.  The data module is simply a location where you can store and retrieve the data.

Like I said, I could be wrong but I haven't found anything that would indicate otherwise. However, your wanting to learn how to use data modules is a noble cause and I wish you well with it.  I worked with a company many years ago on a project involving OS9000 running on a PC.  We had a similar situation where we had multiple processes running concurrently and needing to share common data.  I cannot remember whether we ended up using a data module, colored memory, inter-process communications, or a combination of all of those.  I do know that later versions of OS9 did have some specific provisions for this that we do not have in Level 2 (named pipes comes to mind).  I do remember using semaphores and some other tricks to manage the fact that multiple processes were accessing and changing the data.

Dave Philipsen

> On Jun 10, 2017, at 12:36 AM, Wayne Campbell <asa.rand at gmail.com> wrote:
> 
> I'm sure the GP buffer version will work, but I want to use a data module
> for two reasons.
> 
> 1. I want to learn how to use data modules to pass data in both directions
> to multiple processes. To elabotate, I want process a to be able to write
> to the data module, then have process b read that data, act upon that data,
> and pass the modified data back to the data module to either be read by
> process a, or by process c, and so on.
> 
> 2. GP buffers seem to be limited when it comes to containing multiple types
> and varying lengths of data, requiring multiple GP buffers to handle all of
> the different data requirements. From what I have seen, a data nodule does
> not have this limitation. It can be partitioned so that each partition
> handles the data it needs to handle without regard for the other
> partitions. I like this better, as everything is in one place instead of
> being distributed throughout memory.
> 
> I may be misunderstanding in some of what I have said above, so if anyone
> wants to correct me, please do.
> 
> 
> On Fri, Jun 9, 2017 at 9:56 PM, Bill Pierce via Coco <coco at maltedmedia.com>
> wrote:
> 
>> Dave, MShell has full keyboard support. No need for joysticks, that's just
>> icing on the cake :-)
>> 
>> The thing about MShell's file manager is the ability to move multiple
>> files (as in as many as you select) to/from OS9, RSDOS, and the PC (DW4
>> only). When I copied the 20 some BMP files to the Coco3FPGA, I just clicked
>> each file to select, then hit copy and walked away. After many minutes..
>> (DW4 is slow), the files were all copied :-)
>> 
>> As soon as we can implement the 640x450 screen on the Coco3FPGA in
>> NitrOS9, I'll be expanding MShell greatly.
>> 
>> 
>> 
>> 
>> 
>> 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: Sat, Jun 10, 2017 12:45 am
>> Subject: Re: [Coco] data modules
>> 
>> One of these days when I get my joysticks hooked up to my CoCo3FPGA I'll
>> have to give MShell a spin.  I'm generally not a GUI user.  For some reason
>> I just feel more comfortable with a command line.  But, I definitely would
>> like to move forward with the GrfDrv idea for the 640x450 256-color mode
>> and I think it would be really cool to see your MShell running in that
>> environment!DaveOn 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>-- Coco mailing listCoco at maltedmedia.comhttps://
>> pairlist5.pair.net/mailman/listinfo/coco
>> 
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> https://pairlist5.pair.net/mailman/listinfo/coco
>> 
> 
> 
> 
> -- 
> Wayne
> 
> The Structure of I-Code
> http://www.cocopedia.com/wiki/index.php/The_Structure_of_I-Code
> 
> decode
> http://cococoding.com/wayne/
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco