ghost@bucsb.UUCP (Jay Adelson) (02/12/90)
A question for all you GS experts: I know how to read the 16-bit status register (or at least I'm reading 16 bits) with the GS/OS DStatusGS call, but I don't know what any of the bits mean, except that an AND mask of $0020 checks if the receive register is full. Now, what I need to know is WHAT DO THE OTHER BITS REPRESENT?? Specifically, I need to know which bits represent ready to transmit, and carrier detect. I would like to know what all of them mean, though.... If someone could send me this info, I would be eternally grateful! thanks in advance, -J ghost@bucsf.bu.edu
mattd@Apple.COM (Matt Deatherage) (02/12/90)
In article <269@bucsb.UUCP> ghost@bucsf.UUCP (Jay Adelson) writes: > >A question for all you GS experts: > > I know how to read the 16-bit status register (or at least I'm reading >16 bits) with the GS/OS DStatusGS call, but I don't know what any of the bits >mean, except that an AND mask of $0020 checks if the receive register is full. >Now, what I need to know is WHAT DO THE OTHER BITS REPRESENT?? Specifically, >I need to know which bits represent ready to transmit, and carrier detect. >I would like to know what all of them mean, though.... > > If someone could send me this info, I would be eternally grateful! > >thanks in advance, > -J > ghost@bucsf.bu.edu Not quite. Close, in some respects, but not enough to avoid a paragraph of background. (everyone may groan now) Bit 5 ($0020) in the status word returned in the Status List by DStatus indicates, for character devices, if there is at least one character ready to be read. It does NOT indicate "receive register full" or anything other than there is at least one character to be read. This limitation is because the drivers here (serial port drivers) are generated drivers, and because of the small fact that the only firmware protocol that supports this at all is the Pascal 1.1 protocol, which says "at least one character is ready", that's all the generated drivers can do. (Caution: Sentence Mangling) The other bits indicate things like whether the device is open, generated, block or character, etc. This is all described in GS/OS Reference Volume 2, which is an ABSOLUTE MUST for anyone doing programming like this. -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
farrier@Apple.COM (Cary Farrier) (02/12/90)
In article <269@bucsb.UUCP> ghost@bucsf.UUCP (Jay Adelson) writes: > I know how to read the 16-bit status register (or at least I'm reading >16 bits) with the GS/OS DStatusGS call, but I don't know what any of the bits >mean, except that an AND mask of $0020 checks if the receive register is full. >Now, what I need to know is WHAT DO THE OTHER BITS REPRESENT?? Specifically, The DStatus call ($202D), can take a few different inputs as to the type of status request being made. It sounds as if you are using the device status code request (status_code = $0000). The definition of the 16 bit value returned by this call when made on a character device is as follows: bit 15 Reserved bit 14 1 = Linked Device bit 13 1 = Device Background Busy (executing a background task) bits 12-6 Reserved Bit 5 Buffer not empty Bit 4 1 = Online, 0 = Offline Bits 3-2 Reserved Bit 1 1 = Device currently interrupting Bit 0 1 = Device currently open >I need to know which bits represent ready to transmit, and carrier detect. >I would like to know what all of them mean, though.... For this type of information, take a look at the GetPortStat and GetDTR/SetDTR calls in the Apple IIGS Firmware Ref. Manual, on pages 104-105. > ghost@bucsf.bu.edu -- +---------------------------------------+---------------------------------+ | Cary Farrier | Internet : farrier@apple.com | | Apple II Systems Software Engineering | UUCP : apple!farrier | | Apple Computer, Inc. | Fax : (408) 974-1704 | | 20525 Mariani Ave. | AppleLink : FARRIER | | Cupertino, CA 95014 | or farrier@applelink.apple.com | +---------------------------------------+---------------------------------+ | I don't speak for Apple Computer, our products do. | +-------------------------------------------------------------------------+
lmb7421@ultb.isc.rit.edu (Les Barstow: Phoenix) (02/12/90)
On a similar note, could someone please send me mail on the inner workings of the SCC calls - specifically, I want to set up an interrupt-driven read from a modem.... I'll need info on how to do the interrupts, and how to do a read (info on writes would be good, too...) The GS Technical Reference (not Apple's references) is more than a little vague on SCC programming, and I could use some major help. Les Barstow -- Les Barstow |RIT - A citadel of gleaming brick towering over a snowy swamp SunSinger |Money - That which pays the bills. A dream never remembered. Phoenix rising...+------------------------------------------------------------- LMB7421@ritvax.bitnet | lmb7421@ultb.isc.rit.edu |...rochester!rit!ultb!lmb7421
rnf@shumv1.uucp (Rick Fincher) (02/14/90)
In article <2182@ultb.isc.rit.edu> lmb7421@ultb.isc.rit.edu (Les Barstow: Phoenix) writes: >On a similar note, could someone please send me mail on the inner >workings of the SCC calls - specifically, I want to set up an >interrupt-driven read from a modem.... >I'll need info on how to do the interrupts, and how to do a read >(info on writes would be good, too...) >The GS Technical Reference (not Apple's references) is more than a >little vague on SCC programming, and I could use some major help. The SCC chip is the Zilog 8530. Call a local parts house for a manual. Places like Arrow Electronics, Hamilton Avnet or other parts suppliers can get them for you. They sent me one from Seimans that has all sorts of Ethernet and X.25 chips in it as well as the 8530. The docs are too long to reproduce here. You have to follow a rigid setup procedure with the chip to insure that it works correctly and so that you don't ZAP the other serial port since both ports are in the same chip. By ZAP I mean software-wise not electrically. Rick Fincher rnf@shumv1.ncsu.edu
fadden@cory.Berkeley.EDU (Andy McFadden) (02/14/90)
In article <2182@ultb.isc.rit.edu> lmb7421@ultb.isc.rit.edu (Les Barstow: Phoenix) writes: >On a similar note, could someone please send me mail on the inner >workings of the SCC calls - specifically, I want to set up an >interrupt-driven read from a modem.... [ snip ] >The GS Technical Reference (not Apple's references) is more than a >little vague on SCC programming, and I could use some major help. The //gs Technical Reference by Michael Fischer is not only vague but is just plain wrong in a couple of spots. I wound up disassembling the firmware to figure out the parameter count byte and to determine what exactly was going on. Finally got it to buffer the input and to do a SendQueue, but not without a lot of hassle. Do yourself a favor and get the Apple //gs Firmware Reference. It has everything you need to know about SCC calls (both standard serial port stuff and the //gs extended calls). It can also be vague at times (there's a few spots where sample code would have helped - but then it is a reference manual, right?), but there's nothing you can't figure out. There's also a lot of good stuff about the SmartPort, interrupt vectors, the ADB, the mouse, and others (most of which I haven't read; I bought it from the campus bookstore last night...) The table of vectors and the softswitch listings are also invaluable. >Les Barstow |RIT - A citadel of gleaming brick towering over a snowy swamp -- fadden@cory.berkeley.edu (Andy McFadden) ...!ucbvax!cory!fadden