[Coco] data modules
Dave Philipsen
dave at davebiz.com
Sat Jun 24 03:31:53 EDT 2017
About two weeks ago there was a thread about data modules and how to use
them under OS9. I had recalled that I had used something similar when
working on an OS9000 project a number of years ago. Well, today I dug up
some archived source files from my pile of old hard drives. The project
was finished in 1995, so 20+ years ago. But I did find that we had used
a data module to share data between up to 16 different processes that
ran concurrently. Everything was written in C (Ultra C) and the C
libraries that came with the OS9000 package had support for data modules
although I'm sure you could roll your own in 6809/OS9. There was a
system call available called "_os_datmod" which was used to create the
module and then any of the processes would link to the module and get a
pointer to the data there.
The formatting of the data in the data module was entirely up to the
programmer. We used a number of structs to define the different areas
within the module. There were 8 different processes that linked to the
module and used their own respective data areas within the module. A
supervisory program had access to all 8 of the processes' data areas in
the module. And there were a few other programs that accessed the data
module.
The system ended up being used as a control system for a show in Vegas
which had a number of different sub-controllers scattered around the
building. An RS485 multi-drop communication line tied them all together
and communicated with the main OS9000 computer.
-Dave
On 6/10/2017 3:14 AM, Wayne Campbell wrote:
> 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
>>
>
>
More information about the Coco
mailing list