[Coco] multiplexed serial into ip

[Boisy Pitre]

Aaron,

All of the source for the server, drivers, etc. are online, it just  
takes a little understanding of the NitrOS-9 driver structure and  
system calls, and a design that can encompass different setups.

Feel free to ask any specific questions here, and I'm sure we will be  
able to field them.

Boisy

On Jul 6, 2009, at 6:16 PM, Aaron Wolfe wrote:

> Wow, this really has me interested.
>
> Using drivewire to provide one or more serial ports -> ip sockets
> would open the door to:
>
> running a coco bbs available on the net
> using coco term programs over the net to connect to those boards in
> all their native coco splendor :)
> even running a web server,etc on the coco
>
> a simple simulated AT modem implementation could "dial" ip addresses
> using the hosts ip connection, and respond to incoming tcp connections
> with a ring, etc.  standard coco term programs could probably become
> internet enabled without modification.  just enter an IP address
> instead of a phone number into your favorite term program, and away
> you go.
>
> I am very willing to put time into this, and I have quite a bit of
> programming experience but I'm new to os9 and very rusty with
> assembler.  I could definitely implement the windows/mac/host ip side
> of things, not so sure about the os9 side.
>
> is the source to the drivewire server available, or the protocol
> documented anywhere?  i didn't find much on the web site or in the
> docs included with mine.
>
> anyone want to tackle some or all of the os9 side of things?  is there
> anything similar to this already existing? dont want to reinvent the
> wheel.  any pointers are much appreciated.
>
> -Aaron
>
>
> On Mon, Jul 6, 2009 at 4:11 PM, Boisy Pitre<boisy at tee-boy.com> wrote:
>> Gentlemen,
>>
>> DriveWire 3 opens up the bit banger routines under NitrOS-9 for  
>> just what
>> you want to do.  The DW3 subroutine module has 6 entry points much  
>> like a
>> driver, and can be called from any other module.  In fact, the  
>> rbdw3 RBF
>> driver calls into the DW3 subroutine module this way, and so does  
>> the clock
>> module.  The DriveWire 3 has been totally modularized to facilitate
>> extensions like the one you're contemplating.
>>
>> The difficulty, as you noted, is polling over the bitbanger.   
>> Here's what
>> I've done as an experiment: I have a protocol extension to  
>> DriveWire 3 and
>> rudimentary driver written that uses F$VIRQ to install a virtual  
>> interrupt
>> service routine that hooks to the clock.  For some number of times  
>> per
>> second, the clock driver will call the interrupt routine in my  
>> driver, which
>> sends out a packet to the server to see if there is data available.  
>> The
>> server responds back with one of two possible indications: (a) no  
>> data or
>> (b) data available, and the data itself.  The driver then gets the  
>> data and
>> processes this.
>>
>> Note that this is not nearly as ideal as an interrupt drive  
>> mechanism (which
>> is not possible at the speed the bitbanger is being pushed), but it  
>> does
>> work, and a similar model can be used to do what you want done.   
>> All you
>> need to do is design your own driver and protocol, and extend the  
>> DriveWire
>> server to honor that protocol.
>>
>> Boisy
>>
>> On Jul 6, 2009, at 1:15 PM, Aaron Wolfe wrote:
>>
>>> On Mon, Jul 6, 2009 at 1:50 PM, William Schaub<wschaub at steubentech.com 
>>> >
>>> wrote:
>>>>
>>>> Aaron Wolfe wrote:
>>>>
>>>> I once had a similar Idea. this may be possible if an API to the
>>>> drivewire
>>>> routines could be exposed to developers on OS/9 you would have to  
>>>> extend
>>>> the
>>>> drivewire server software to handle some new custom opcodes and  
>>>> pass
>>>> traffic
>>>> back and forth. and you would have to do lots of polling but I  
>>>> think it
>>>> could be done. but as far as I know I don't know if boisy ever  
>>>> added any
>>>> way
>>>> for a programmer to access the drivewire bit banger routines to  
>>>> extend
>>>> the
>>>> system. (I'm still using drivewire V2.0)
>>>>
>>>>
>>>
>>> that's interesting, I had not considered using the drivewire  
>>> interface
>>> to do this.  my current setup is completly incompatible with it,  
>>> which
>>> is why I was planning on getting a 'real' drive interface of some  
>>> kind
>>> to move forward.  the drivewire does provide both a disk system  
>>> and a
>>> realtime clock to os9... providing a usable serial port would be a
>>> natural and very useful extension.
>>>
>>> currently, I terminate tcpip connections on a linux box running  
>>> server
>>> code that handles all the sockets and communicates with the coco by
>>> way of a single ip connection to a terminal server.   the serial  
>>> data
>>> is given a header that indicates which session it belongs to on the
>>> way in by my server code, and on the way out by the coco.  this  
>>> allows
>>> multiple simultaneous sessions to the coco.  my poc code is  
>>> running in
>>> basic (due to the limitations of my current setup) so the coco  
>>> side is
>>> not multitasking, it is handling the events sequentially, limiting  
>>> its
>>> usefulness to small things that can be done quickly, like chat rooms
>>> or very simple bbs type systems.  however if the sessions could
>>> terminate in devices under os9, this would become very nice for true
>>> multiuser scenarios running any kind of software.
>>>
>>> crude ascii:
>>>
>>> (internet)  === lots of ip connections ===> (linux server) --- one  
>>> ip
>>> connection ---> (term server) --- one serial connection ---> (coco)
>>>
>>> (and it all actually works :)
>>>
>>> -Aaron
>>>
>>>
>>>
>>>>
>>>> --
>>>> Coco mailing list
>>>> Coco at maltedmedia.com
>>>> http://five.pairlist.net/mailman/listinfo/coco
>>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco