[Coco] Basic09 <==> 6809 interface.
gene heskett
gheskett at shentel.net
Tue Aug 29 11:59:03 EDT 2023
On 8/28/23 13:21, William Carlin via Coco wrote:
> The only concrete example of data modules being used in OS9/6809 is the CC
> compiler executive, version 2.5.2. The name of the original author escapes
> me. However, it has been hacked on by many of the OS9/6809 luminaries like
> Vaughn Cato, Gene Heskett, and Boisy Pitre. A portion of the source is
> included in the EOU, located in the /DD/SOURCECODE/C/CC directory.
>
The use of my name got my attention, William, but I'm afraid my memory
is not up to any great help. I'm now 88 and my coco died of bad caps
nearly 20 years ago. And I've replacement hdwe in my chest running me.
What I was looking for at the time I used it was more like a ramdisk,
which I wound up writing, it should be in the repo as myram. I used it
extensively for a decade or more. You could put the drivers/descriptors
in your os9boot as it was self initializing, all you had to do was ask
/r0 for a directory listing and you were looking at an empty directory
about 200 milliseconds or less later. Size was adjustable up to however
much memory you could steal from os9 which since I had one of tony's 2
meg kits in mine meant I could make it look like a 1.5 meg floppy but
way faster for scratchpad use with the C compiler. You could deiniz it
when done and get every byte back into the os9 pool.
I'm now long retired (21 years ago) from the tv station I kept on the
air for nearly 20 years, skipped windoze and built my first linux box in
98, got into cnc machining and woodworking, and now 3d printing. And
alone again, the music teacher I put a ring on in dec '89 passed in dec
20 of copd.
Thanks for the honorable mention.
> Here's the relevant source code snippets and the information about the
> ccdevice data module that is not included in the EOU.
>
> [module.h as included with CC2.5.2 in EOU]
>
> /* OS-9 module header definitions */
> /* Executable memory module */
> /* typedef */ struct mod_exec {
> unsigned m_sync, /* sync bytes ($87cd) */
> m_size, /* module size */
> m_name; /* offset to module name */
> char m_tylan, /* type & language */
> m_attrev, /* attributes & revision */
> m_parity; /* header parity */
> unsigned m_exec, /* offset to execution start */
> m_store; /* initial storage size */
> } /* mod_exec */ ;
> /* Device descriptor module */
> /* typedef */ struct mod_dev {
> unsigned m_sync, /* sync bytes ($87cd) */
> m_size, /* module size */
> m_name; /* offset to module name */
> char m_tylan, /* type & language */
> m_attrev, /* attributes & revision */
> m_parity; /* header parity */
> unsigned m_fmname, /* offset to file manager name */
> m_ddname; /* offset to device driver name */
> char m_mode; /* mode byte */
> char m_control[3]; /* device controller address (24
> bit)*/
> char m_tabsize; /* option table size */
> } /* mod_dev */ ;
> /* Configuration module */
> /* typedef */ struct mod_config {
> unsigned m_sync, /* sync bytes ($87cd) */
> m_size, /* module size */
> m_name; /* offset to module name */
> char m_tylan, /* type & language */
> m_attrev, /* attributes & revision */
> m_parity; /* header parity */
> char m_ramtop[3]; /* top limit of free ram */
> char m_irqno, /* IRQ polling entries */
> m_devno; /* device entries */
> unsigned m_startup, /* offset to startup mod. name */
> m_sysdrive, /* offset to default drive name */
> m_boot; /* offset to bootstrap module name
> */
> } /* mod_config */ ;
> /* C data module */
> /* typedef */ struct mod_data {
> unsigned m_sync, /* sync bytes ($87cd) */
> m_size, /* module size */
> m_name; /* offset to module name */
> char m_tylan, /* type & language */
> m_attrev, /* attributes & revision */
> m_parity; /* header parity */
> unsigned m_data, /* offset to data */
> m_dsize; /* size of data */
> } /* mod_data */ ;
>
>
> [Snippet of code where cc252.c (included in EOU) gets the default device
> from the data module]
>
> char * chkccdev()
> {
> char *s, c;
> register char *p;
> struct mod_data *q; /* was mod_exec, m_data not member if it! */
> struct mod_config *r;
> if((q=(struct mod_data *)modlink("ccdevice",4,0))!=(struct mod_data
> *)-1)
> {
> strcpy(devnam1, (char *) q + q->m_data);
> munlink(q);
> return (devnam1);
> }
> else
> {
> if ( (r=(struct mod_config *)modlink("Init",0x0c,0))!=(struct
> mod_con
> {
> s = (char *)(r + r->m_sysdrive);
> p = devnam1;
> while ((c = *s++) > 0)
> *p++ = c;
>
> *p++ = (c & 0x7f);
> *p = 0;
> munlink(r);
> return (devnam1);
> }
> }
> return (NULL);
> }
>
> [dump of ccdevice data module]
>
> {Term|02}/H1/USR/SRC/CC252/SRC:dump ../datamod/ccdevice
> Address 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
> -------- ---- ---- ---- ---- ---- ---- ---- ---- ----------------
> 00000000 87CD 002E 000D 4081 5700 1600 0063 6364 .M.... .W....ccd
> 00000010 6576 6963 E501 2F44 4400 0000 0000 0000 evice./DD.......
> 00000020 0000 6363 6465 7669 6365 000D 1F4D ..ccdevice...M
>
> [disassembly of ccdevice data module]
> [I'm not sure how accurate this disassembly, is as assemble language is not
> my strong suit. It looks pretty janky at the start label where the dump
> shows the /DD stored data. I'm sure LCB or someone else could clarify any
> inaccuracies]
>
> nam ccdevice
> ttl data module
> * Disassembled 2014/04/13 21:59:14 by Disasm v1.6 (C) 1988 by RML
> ifp1
> use /dd/defs/defsfile
> endc
> tylg set Data+$00
> atrv set ReEnt+rev
> rev set $01
> mod eom,name,tylg,atrv,start,size
> u0000 rmb 0
> size equ .
> name equ *
> fcs /ccdevice/
> fcb $01
> start equ *
> ble L005C
> lsra
> neg <u0000
> neg <u0000
> neg <u0000
> neg <u0000
> neg <u0063
> com $04,s
> eim #$76,$09,s
> com $05,s
> fcb $00
> emod
> eom equ *
> end
>
> END
>
> On Sat, Aug 26, 2023 at 8:25 PM L. Curtis Boyle via Coco <
> coco at maltedmedia.com> wrote:
>
>> The problem with data modules for OS9/6809 (I don’t know if this applies
>> to OSK) is that you have to re-verify the CRC each write to it, which can
>> slow things down (or you shut CRC checking off completely). From
>> appearances, the 6809 version is more meant as a read only file of data.
>>
>> Sent from my iPhone
>>
>>> On Aug 26, 2023, at 6:14 PM, Allen Huffman via Coco <
>> coco at maltedmedia.com> wrote:
>>>
>>>
>>>>
>>>> On Aug 26, 2023, at 4:43 PM, coco--- via Coco <coco at maltedmedia.com>
>> wrote:
>>>>
>>>> All
>>>>
>>>> Has anyone written a program that allows some shared memory buffer
>> between a
>>>> Basic09 program and an OS9 assembler program, so that some variables
>> can be shared
>>>> without having to save them to files in one language and read/write
>> reply in the
>>>> Other ?
>>>
>>>
>>> OS-9 “data modules” are designed for this purpose. I have used them on
>> later versions of OS-9 for the 68000/PPC/etc. but do not have experience
>> with them under OS-9/6809.
>>>
>>> The basic idea is that OS-9 components are modules with a header, body
>> and CRC. For a program the body is the code. For a data module, the body is
>> whatever you want. For example, it could be a compiled list of data for a
>> program to access — useful on a machine without a file system.
>>>
>>> You can “link” to a data module and it is mapped in to your 64K user
>> space (on the CoCo 3, or just there on a 64K machine). You get a pointer to
>> the data area and can read/write bytes to it. Other programs can do the
>> same.
>>>
>>> I am unaware of any built-in OS-9/6809 resource locking, so that would
>> be needed.
>>>
>>> --
>>> Allen Huffman - PO Box 7634 - Urbandale IA 50323 - 515-999-0227
>> (vmail/TXT only)
>>> http://www.subethasoftware.com -
>> https://www.facebook.com/subethasoftware
>>>
>>>
>>>
>>> --
>>> 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
>>
>
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, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
More information about the Coco
mailing list