[Coco] data modules

[Bill Pierce]

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