[Coco] data modules

[Gene Heskett]

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>