[Coco] drivewire serial port progress

[Jim Hathaway]

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.

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
>