davel@hpvcla.UUCP (03/17/86)
I have been looking at some os9 drivers, one has some features I would like to fix. In the process of trying to understand them, I have run across some questions that my System Programers Manual doesn't seem to answer. Maybe someone can help me out. I should state up front that my system is considered "homebrew" and does not have support from anyone but me. My questions: What happens to os9 if it gets handed a character with the most significant bit set? My input driver carefully strips the bit before passing the character on. The keyboard I have has several special function keys and I have thought I could flag these keys with the most significant bit. My documentation gives precious little information about the register setup on the entry into a driver's interrupt routine. Could someone enlighten me? What is the purpose of the BITA #1 instruction that always seems to be at the beginning of the routine? The documentation of getsta/setsta is somewhat confusing. If I remember correctly the section on the getsta/setsta driver entry points claims that RBF and SCF handle all current status requests. Implying that the driver need not worry. Of course this is not true. The device ready status request is at least one that the driver needs to handle. By looking at the system calls for getsta and setsta I have concluded that the most of the setup and expected return values are passed directly/returned from the driver, at least in the device ready case. Is there some better documentation on these entry points? New documentation would likely explain when and how the getsta entry should return the number of bytes available to be read. Thanks to anyone who may be willing to venture an explanation. Dave Lowe hp-pcd!hpvcla!davel
kottke@puff.UUCP (Richard J. Kottke) (03/22/86)
Attempted answers to Dave Lowe's very good questions: > What happens to os9 if it gets handed a character with the most significant > bit set? My input driver carefully strips the bit before passing the > character on. The keyboard I have has several special function keys and I > have thought I could flag these keys with the most significant bit. This is probably due to your input driver, as you have said; however os9 seems to be willing to send 8-bit characters wherever they need to go (as is the case with the disk drivers). A little bit of work with your terminal device driver should get the 8th. bit going. An alternate method would be to mess around with tmodes's "type" parameter, which is a little mysterious; my manual says that it is for setting parity, wordlength etc. but gives no further info. > My documentation gives precious little information about the register setup > on the entry into a driver's interrupt routine. Could someone enlighten me? > What is the purpose of the BITA #1 instructiS.Size SS.Pos SS.EOF SS.DStat SS.Joy SS.Reset SS.WTrk SS.Feed SS.Frz SS.SQD SS.DCmd I have added SS.DSiz because on the Color Computer, the display isn't always 80 columns by 24 lines; I encourage others to utilize this status call. About where to get at the passed parameters: they are pointed to by the PD.RGS area of the path descriptor. Upon entry to a GetStat or SetStat server, U points to the device static memory area, Y points to the PD and A holds the status code. To get X pointing to the register stack do this: LDX PD.RGS,Y X points to the old registers To change the stack or look at it, do this: LDA R$A,X A gets the old A EORA #$F1 Do something bizaare to A STA R$A,X Put it back If you were to write a SCFMan - type driver, you could include these status calls: SS.Opt SS.Ready SS.Reset SS.Feed SS.DevNm SS.DSiz If you need more info on these, just drop me an e-mail letter. -Richard Kottke kottke@puff.wisc.edu uwvax!puff!kottke
gremlin@well.UUCP (Gremlin) (03/24/86)
>>Attempted answers to Dave Lowe's very good questions: >> What happens to os9 if it gets handed a character with the most significant >> bit set? My input driver carefully strips the bit before passing the >> character on. The keyboard I have has several special function keys and I >> have thought I could flag these keys with the most significant bit. >This is probably due to your input driver, as you have said; however os9 seems >to be willing to send 8-bit characters wherever they need to go (as is the case >with the disk drivers). A little bit of work with your terminal device driver >should get the 8th. bit going. An alternate method would be to mess around >with tmodes's "type" parameter, which is a little mysterious; my manual says >that it is for setting parity, wordlength etc. but gives no further info. This is just a little note ... Use of the 'type' parameter in the device driver on a GIMIX system running OS9 allows the setting of # of data bits , # of stop bits, parity and to a certain extent baud rate (division of baud rate generator) when using a 6850 acia 2-port serial card. I'm not sure as to what extent this can be used on a RS CC. gremlin
emjej@uokvax.UUCP (03/28/86)
/* Written 10:39 am Mar 17, 1986 by davel@hpvcla in net.micro.6809 */ >What happens to os9 if it gets handed a character with the most significant >bit set? My input driver carefully strips the bit before passing the >character on. The keyboard I have has several special function keys and I >have thought I could flag these keys with the most significant bit. OS-9 is perfectly willing to pass 8-bit data along. (I found this out the hard way on a VT-200 compatible terminal talking to Unix, which seems to insist on sending stuff out with even parity! :-) Your driver could, however, check the PD option section to decide whether to strip the parity bit. >The documentation of getsta/setsta is somewhat confusing. If I remember >correctly the section on the getsta/setsta driver entry points claims >that RBF and SCF handle all current status requests. Implying that the >driver need not worry. Of course this is not true. The device ready status >request is at least one that the driver needs to handle. If the docs say that, then something's hosed. The idea behind get/setstat is that at each level in the Great Chain of Being (IOMAN -> file manager -> device driver), those get/setstat requests that should be handled are handled, and any others are passed on down. For example, IOMAN can handle the "copy the PD option section" request; RBFMAN handles record locking; as you point out, device drivers have to support things like device ready. >New documentation would likely explain when and how >the getsta entry should return the number of bytes available to be read. Let me strongly urge that you get a copy of *The Complete *Rainbow* Guide to OS-9* by Dale L. Puckett and Peter Dibble, available at your local Radio Shack or from *Rainbow* magazine. It contains listings of sample device drivers. Basically, the ACIA driver they show keeps a queue of characters waiting to be read which is added to (or a 244, device overrun, error is signalled) if the interrupt service routine snarfs a character from the device. James Jones /* End of text from uokvax.UUCP:net.micro.6809 */
emjej@uokvax.UUCP (04/02/86)
The following is posted on behalf of a friend who can't post notes... ---------------------------------------- From: chinet!draco@ihnp4.UUCP > From: davel@hpvcla.UUCP (Dave Lowe) > Subject: Request for os9 info > What happens to os9 if it gets handed a character with the most significant > bit set? My input driver carefully strips the bit before passing the > character on. The keyboard I have has several special function keys and I > have thought I could flag these keys with the most significant bit. The device driver does have the major responsibility for allowing eight bit input. However, some older versions of SCF strip the eighth bit during the editing functions of the ReadLn and WritLn calls. This was changed in edition eight (8) of SCF, but I don't know whether the offending code was present in ALL of the previous versions. In any event, using Read and Write will avoid the problem. One other point to consider is setting the ACIA for eight data bits and NO parity. > My documentation gives precious little information about the register setup > on the entry into a driver's interrupt routine. Could someone enlighten me? Only TWO registers have any meaning on entry to the interrupt handler. The A register, which contains the status register contents after processing by the mask and flip bytes. And the U register, which points to the device's static memory area. The DP is set to zero (00) as always on entry to a device driver. > What is the purpose of the BITA #1 instruction that always seems to be at > the beginning of the routine? If the driver you are a referring to is for the 6850 ACIA, the BITA #1 is to determine whether the interrupt is an input (bit 0=RDRF= Receive Data Register Full) or an output (bit 1=TDRE= Transmit Data Register Empty). > The documentation of getsta/setsta is somewhat confusing. If I remember > correctly the section on the getsta/setsta driver entry points claims > that RBF and SCF handle all current status requests. Implying that the > driver need not worry. Of course this is not true. The device ready status > request is at least one that the driver needs to handle. By looking at > the system calls for getsta and setsta I have concluded that the most of > the setup and expected return values are passed directly/returned from the > driver, at least in the device ready case. Is there some better documentation > on these entry points? New documentation would likely explain when and how > the getsta entry should return the number of bytes available to be read. The following is a list of those getstat/setstat calls which are handled directly by IOMan or the file managers: Get Status calls handled by IOMan: SS.OPT SS.DEVNM Set Status calls handled by SCF: SS.OPT Get Status calls handled by RBF: SS.EOF SS.READY SS.SIZE SS.POS SS.FD Set Status calls handled by RBF: SS.OPT SS.SIZE SS.FD SS.RSBIT ALL other get/setstat calls are handled directly by the associated driver. The SCF device SS.READY Get Status call functions as follows: Entry Conditions> A=path number B=$01 Exit Conditions> If ready: CC=Carry Clear B=#of bytes available Exit Conditions> Not ready: CC=Carry Set B=$F6 (E$NOTRDY) To add this to an existing driver will require adding a character counter to the input and output routines. Kent D. Meyers ihnp4!chinet!draco