[Coco] data modules

Sat Jun 10 04:14:01 EDT 2017

I am actually thinking of the idea of records. In every instance of using
GP buffers, it seems the description is
 about accessing records. I don't know that OS-9 supports variable length
records, and the data I am looking at passing back and forth could be of
varying length, plus some of it may not be more than a single entry, where
other parts may be multiple entries of differing data, requiring differing
lengths. I think I can accommodate that better using a partitioned data
module (I create the partitions in the procedures that use them), control
read/write access using a locking mechanism that I have to figure out how
to write, also controlled through the procedures that pass or retrieve data
through the data module, etc. It will be a fun exercise, and maybe I can
learn other ways to do these things while I'm at it.

On Fri, Jun 9, 2017 at 11:18 PM, Dave Philipsen <dave at davebiz.com> wrote:

> 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
>
>
> --
> 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/