[Coco] drivewire serial port progress
kg4knb at hat3.net
Wed Nov 11 10:00:21 EST 2009
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
> > Boisy
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > http://five.pairlist.net/mailman/listinfo/coco
> Coco mailing list
> Coco at maltedmedia.com
More information about the Coco