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