[Coco] multiplexed serial into ip

Aaron Wolfe aawolfe at gmail.com
Mon Jul 6 19:16:28 EDT 2009


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
>



More information about the Coco mailing list