[Coco] MShell

[Dave Philipsen]

Ok, got it!


On 6/10/2017 10:34 PM, Bill Pierce via Coco wrote:
> Dave, for some reason my files were missing on the server. I just moved them to the new server a couple of months ago and may have missed that folder. It will work now :-)
>
>   
>
>   
>
> 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 9:58 pm
> Subject: Re: [Coco] MShell
>
> Ok, so tonight I said, "hey, why don't I just d/l mshell and give it a whirl" (since I now know it doesn't require joysticks).  So I went to your webpage and clicked on the link but it ain't there!  Where's the best place to d/l the latest version?DaveOn 6/9/2017 11:56 PM, Bill Pierce via Coco 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 f
> ull 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 b> e 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 lo> cation 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 gmai
> l.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/list> info/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
>