[Coco] drivewire serial port progress

[Aaron Wolfe]

I think I was using the wrong terms searching Google for Windows PTY
support. I found this this:  http://com0com.sourceforge.net/
which might solve the lack of PTYs in Windows nicely.


On Wed, Nov 11, 2009 at 8:35 PM, Aaron Wolfe <aawolfe at gmail.com> wrote:
> On Wed, Nov 11, 2009 at 10:00 AM, Jim Hathaway <kg4knb at hat3.net> wrote:
>> On Wed, Nov 11, 2009 at 8:16 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>>
>>> On Wed, Nov 11, 2009 at 9:00 AM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
>>> > On Nov 11, 2009, at 6:10 AM, Aaron Wolfe wrote:
>>> >
>>> >> After a long night of hacking I now have an interrupt based driver
>>> >> working, and it's working really well.  Took a lot of debugging but I
>>> >> learned much in the process.
>>> >
>>> > Super!
>>> >
>>> >> I used a buffer in the style of sc6551's, I think I can get dw to
>>> >> write straight into it in the future.  I somehow solved the issues
>>> >> with non VDG consoles, it now works fine with level 1 or 2, any
>>> >> console mode.  I also got rid of an occasional mysterious input bug.
>>> >> All in all, it's coming together fast.
>>> >>
>>> >> Performance with the interrupt driver is very good, I didn't realize
>>> >> how bad my first attempt was until I got this working.
>>> >> Thanks for all the help from everyone on the list.  Now I need to
>>> >> implement a better set of calls between the driver and server, but
>>> >> Darren sent me an awesome example of how to do this, so that won't
>>> >> take too long.
>>> >>
>>> >> It seems like some of the keyboard inputs have to be implemented in
>>> >> the scf driver, for instance break/escape has to be turned into a
>>> >> signal to SCF, unless I'm getting this wrong?  So it will take more
>>> >> than a good terminal program to have a full featured console, I'll
>>> >> have to do more work in the driver.
>>> >> For data/modem applications, there is another set of controls.  Can
>>> >> both be implemented at once, or will there need to be two
>>> >> modes/descriptors/something?
>>> >
>>> > Typically this is all done in one driver with one descriptor.
>>>  Applications like terminal programs that expect to get all bytes and not
>>> have the driver interfere with interpreting things like BREAK, etc., will
>>> use the I$GetStat call and set the path options for that path to "raw mode"
>>> (setting values to 0 for interrupt & break keys, etc).  Again, sc6551 shows
>>> how to handle V.INTR and V.QUIT characters... implement that code in your
>>> driver, and those applications that want to use the device for
>>> non-interactive data will set the path's values to 0 for INTR and QUIT.
>>> >
>>>
>>> Ah yes.. haven't really implemented get/setstat beyond the minimum to
>>> make things run yet :)  that makes sense though, and 6551 does have
>>> good examples so shouldn't be to hard to put in place.
>>>
>>> > When you get your protocol settled, please send me the specifications.
>>>  Both the Windows and Mac Servers will need to be updated to accommodate the
>>> new opcodes and features.
>>> >
>>>
>>> Will do..  I can (probably) make the changes needed to make the Mac
>>> server work, but not sure if Windows can do ptys.. in any case can try
>>> to find some work around or just ignore the ops at least.  I'd guess
>>> most folks that would be that interested in something like this would
>>> be more *nix inclined than pointy clicky types, but who knows.
>>>
>>>
>> I think this is a great new DriveWire addition.  I would love to see this
>> work in all versions of DriveWire.  When I use DriveWire I typically use the
>> windows version.
>>
>
> I will do what I can.   After spending some time with Google, Windows
> does not appear to support PTYs, while linux and mac (and many other
> os) do.  The PTY functionality makes the emulated serial port show up
> on the server as a basically regular device able to be used with
> practically any application running on the server machine, such as a
> standard terminal program.  Without PTY support, I'm not sure there is
> a way to do such a thing in Windows.  This means you would not be able
> to use a regular Windows terminal program or other software to access
> the Coco's DW serial port like you could in the *nix environments.
>
> The other part of my project, a modem emulator that uses hayes
> commands to set up tcpip connections, should be portable to all three
> operating systems without too much trouble.   In a way this might
> provide some amount of a workaround to the lack of PTY support in
> Windows.  You could telnet to localhost on the server and connect to
> the virtual serial port that way.  Not ideal but in truth probably
> good enough.
>
> I had planned on writing this modem/ip part of the project as a
> separate utility that just talked to the PTY provided by drivewire, to
> keep the dw server code as clean and focused as possible.  In the
> Windows version, I suppose it would have to be grafted into the server
> code and work directly with the buffers there.  Probably not a big
> deal, but would make the Windows server architecturally quite
> different from the others.
>
> Maybe smarter people have a better way to work that out :)
>
>
>
>> Jim
>>
>>
>>
>>> -Aaron
>>>
>>> > Boisy
>>> >
>>> > --
>>> > 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
>>
>