[Coco] drivewire serial port progress
aawolfe at gmail.com
Wed Nov 11 20:54:28 EST 2009
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 :)
>>> > Boisy
>>> > --
>>> > Coco mailing list
>>> > Coco at maltedmedia.com
>>> > http://five.pairlist.net/mailman/listinfo/coco
>>> Coco mailing list
>>> Coco at maltedmedia.com
>> Coco mailing list
>> Coco at maltedmedia.com
More information about the Coco