[Coco] questions about sharing memory amongst device drivers in os-9

[Boisy G. Pitre]

Aaron,

Although I didn't comment on your earlier RFC, I think everything looked fine.

As for the current issue: the behavior you are getting is expected in that since the V.PORT is different, IOMan is assigning separate static storage areas for each device.

If you want to share memory between devices, you have several options:

1. Use a data module.  A data module is simply an OS-9 module with empty space allocated.  It would need to be included in the bootfile and linked by the driver using it at init time, and a reference to the data module's entry point could be stored in the driver's static storage. Since the data module would reside in system RAM, the driver would have direct access to it and could use that space to share information between other instances of the driver.

2. Use the System Direct Page Vars.  If you look in os9defs, you'll see that low memory from $00 to $20 is reserved for Direct Page vars that the user can define.  There are some there already, and if you only need one or two bytes, it might be easier just to reserve some space from there for your driver to use.

How much space are you needing to share between each device?

Boisy

On Nov 15, 2009, at 12:55 PM, Aaron Wolfe wrote:

> Hi,
> 
> I've updated the server code and drivewire nitros-9 drivers to allow
> up to seven "virtual" serial ports over the bitbanger.  Each virtual
> port is terminated on the host in its own PTY.
> 
> In order to do this, I created additional device descriptors with
> different V.PORT values but pointing to the same scwdt driver. I use
> the port in calls to the driver to distinguish between them.
> 
> Everything works fine for writes, since these do not require any
> coordination between devices.  I can simultaneously list out multiple
> files on the coco to separate windows/session on my PC, no problem.
> Drivewire really is fast!
> 
> However, for incoming data I have an issue that I could use some
> guidance with.  Each device creates its own memory area.  The first
> device to use the scwdt driver shares it's area with the driver, so
> they can see the same memory, where the input buffers, status flags
> etc are.  I can run a shell on the first port I iniz, whichever port
> that might be, and everything's great.
> 
> The second third etc ports are getting their own separate device
> memory area, I guess this makes sense in a real world device where
> they would have separate interrupt handlers.  But in this project, I
> need to use a single interrupt handler to feed multiple "devices".
> 
> Here's an example of what I mean, T1 and T2 have different static mem
> areas, but both use scdwt.  Since T1 has the same addr (6000) as the
> IRQ handler, it can do writes.  T2 can only do reads:
> 
> {T1|03}/DD:devs
> 
> Device Table at: 6D00
> 
> Device Desc  Driver Static  File    Usr
> Name   Port  Name      Mem  Manager Cnt
> -----------  -------------  ------- ---
> DD   070000  rbdw3    6B00  RBF      05
> Term 07FFA0  VTIO     6A00  SCF      04
> T1   07FF01  scdwt    6000  SCF      03
> T2   07EE02  scdwt    5E00  SCF      01
> 
> {T1|03}/DD:irqs
> 
> Polling Table at: 6EFB
> Device Table at: 6D00
> 
> Device    Driver  IRQ   Flip
> Port Mem   Name  Vector  &Mask Pty
> ---- ----  ------------  ----- ---
> 60B4 6000  scdwt   E5C6  00 01  0A
> 
> 
> All I really need is some shared memory or other means to get bytes
> into each device's buffer from the central interrupt handler, or let
> the devices come get the data from a central set of buffers,
> whichever.. and then the ISR needs to know the process IDs (V.BUSYs
> basically) of each device so it can send the wake signal.   Actually I
> have the signal handler written already but no way to get the PIDs
> into it's table.
> 
> Is there a standard os-9 way to do such a thing?  Am I missing
> something that would make this simpler? I've studied the os9 terch ref
> and everything else I can find but nothing has become obvious to me
> yet.  Any advice is much appreciated.
> -Aaron
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco

--
Boisy G. Pitre
http://www.tee-boy.com/