[Coco] os9/drivewire driver: success!

[Aaron Wolfe]

Thanks for the advice.  I kind of suspected i was doing things wrong with the way i was trying to sleep.  Between your walk through and the examples in other modules, I might be able to pull this off.  I will give it a shot and see how far I get :)


-----Original Message-----
From: Boisy G. Pitre <boisy at tee-boy.com>
Sent: Tuesday, November 10, 2009 7:05 AM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Subject: Re: [Coco] os9/drivewire driver: success!

Aaron,

Again, fantastic work.  It is great to see someone taking the bull by the horns, learning the tools and expanding on the existing work in the NitrOS-9 project.

I downloaded the source to the scdwt driver and looked over it.  I have a few suggestions that I think you may want to look at.

Typically in an OS-9 SCF driver, the read routine uses the V.BUSY/V.WAKE SCF variables to handhshake with an interrupt service routine (ISR) to coordinate obtaining data from an input buffer that is filled by the ISR itself.  There is no real interrupt in this particular case, but OS-9 provide something called a Virtual Interrupt (VIRQ) that you can use for situations just like this.  Here's how it works:

You can set up the VIRQ through the F$VIRQ system call to call an ISR that you provide for some interval.  The period of the OS-9 tick is 1/60 second.  You supply a multiplier to the F$VIRQ call to extend the period that the VIRQ calls your ISR, so you could have your ISR get called every 6 ticks, which means your ISR gets called 10 times per second.  You can adjust this number as you wish for optimality.

Your ISR, when called, would send a OP_SERREAD call to the server.  I would combine the OP_SERCHECK and OP_SERREAD into one call.  When you send the OP_SERREAD, the server would send back two bytes.  The first byte would flag whether there is a valid byte to send, and the second byte would be that byte. So for example:

ISR sends OP_SERREAD
Server returns:  0x00 0x00  (first byte indicates that there is no data to send, second byte is just a fill byte)
  OR
Server returns: 0xFF 0x41 (first byte indicates that there is data from the server, and the second byte is the valid character)

In your ISR, you have to take into account that a response may not come in because the server isn't running, the cable is unplugged, etc, and take action accordingly, but assuming everything is ok, you get back a response immediately.  IF the first byte is 0, you just return.  However IF the first byte is non-zero, you t

[The entire original message is not included]