[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

>