[Coco] Basic09 <==> 6809 interface.

William Carlin whcarlinjr at gmail.com
Mon Aug 28 13:21:12 EDT 2023


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.

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
>


More information about the Coco mailing list