[Coco] data modules

[Wayne Campbell]

When I had my real CoCo3 and was developing DCom, I used a RAM disk. DCom
was so slow that it took a RAM drive to speed it up enough to make it
useful. It worked, but I never really like using a drive. I wanted
something more specific to the program. A data module sounded good, but at
that time I knew absolutely nothing about them, or memory modules in
general. I was learning to understand I-Code modules and, for me, that was
complicated enough. Now I feel I am ready to tackle data modules, but I
needed an example of one and couldn't find the example I found years ago.

With the help of everyone who responded in this thread, I am now ready to
begin experimenting with data modules. Thanks to all of you, and I will
post when I have something to show for my efforts.

On Sat, Jun 10, 2017 at 8:38 AM, Gene Heskett <gheskett at shentel.net> wrote:

> On Saturday 10 June 2017 04:14:01 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.
>
> To get this back on the topic Wayne asked about, perhaps looking at
> another of my coding efforts might be useful.  Thats my automatic myram
> ramdisk.  Put it in your bootfile.
>
> Its in the nitros9 repo at level2/modules, was originally named myram,
> and it comes into its full glory as a ram disk if you've the 2 meg disto
> kit in your machine.
>
> Much more limited on a 512k machine but still useable as the cache
> between stages of the c compiler. That, IIRC, has the first 8192 block
> with a full os9 file system format, and switches that, an 8k block at a
> time, fully emulating the os9 file system structure as it does so. Find
> it as mr0.asm and myram.asm in level2/modules of the nitros9 repo.  It
> automatically formats an empty ramdisk, in 100to perhaps 250
> milliseconds, just by asking for a dir from /R0, and deiniz's itself
> with a deiniz /r0 when you are done with it, returning every byte it
> used to the system.  I've used it for as much as a 1.7 meg ramdisk on my
> coco3 with the 2 meg disto kit in it..
>
> I see that its too big for a 512k coco3 as the RAMSize is set to 128, or
> a 1048576 byte ramdisk in 8k blocks. For a 512k coco3, perhaps try 24,
> which will give a 196608 byte ramdisk. The C compiler should be happy
> with that since it can use a 160k floppy for its scratchpad.  There is a
> comment at the top of the driver that it required Chris Burkes xsm to
> build but I believe that Mr. Astles lwasm is building it correctly
> today. At the time I wrote it, xsm was the only assembler extant that
> handled the 6309 stuff properly. Since Chris wrote xsm in C, its bigger,
> and very noticeably slower. The key was that it did the job on my coco3
> at the time, perhaps 25 years ago?  Now we have lwasm, which is on this
> machine, about 5000 times faster.
>
> It can be size adjusted with dmode, but 20 some years later I've
> forgotten which variable to adjust. Doing a dmode /r0 should show which
> it is in a sea of 00's. IIRC.  And it shows how I allocated that memory.
> And its accessed as a std os9 file system, 1 byte, or 1.7 megabytes if
> you've that much ram to spare. The only "record" is the format of the
> os9 filesystem.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
> --
> 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/