[Coco] drivewire serial port progress

[Aaron Wolfe]

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
>