ddave@pnet02.gryphon.com (David Donley) (09/04/89)
Hello there, I have discovered that hot keys in BBS programs do not work right
with the supra internal modem device driver (It's supposed to be a
serial.device clone)
Anyhow, I talked to the writer and he says that it says in the new 1.3
auto-docs that the CMD_WRITE command is supposed to queue up output and return
immediatly. He is aware that this is not the way the serial.device does it,
but he says he is doing it "by the book". I don't think this is the way it
should be, for several reasons:
1. It breaks existing programs.
2. There is no way to fix the break
3. There is an RBufSize field in the Serial device structures, but no
WBufSize.
4. There are no commands for enlarging, shrinking, clearing, or
otherwise changing this phantom buffer.
5. I would think that on a ZModem send through the device, the buffer
would grow infinatly until it consumed all availible RAM! (I haven't tried
it)
Could somebody tell me who's right?
----------------------------------------------------------------------------
Mail responses to ddave@pnet02.gryphon.com (Please?)
Thanks!perry@madnix.UUCP (Perry Kivolowitz) (09/06/89)
In article <19435@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes: > >Hello there, I have discovered that hot keys in BBS programs do not work right >with the supra internal modem device driver (It's supposed to be a >serial.device clone) > >Anyhow, I talked to the writer and he says that it says in the new 1.3 >auto-docs that the CMD_WRITE command is supposed to queue up output and return >immediatly. He is aware that this is not the way the serial.device does it, >but he says he is doing it "by the book". I don't think this is the way it >should be, for several reasons: I suggest that there is some other problem lurking in the Supra driver. The author is correct in stating that the serial device should support multiple queued writes. However, I think you have a misunderstanding (from the text I deleted) about who declares and maintains the buffer. Queued writes are not pooled in a common buffer. Rather, each chunk of memory you supply in the iorequest block is held onto by the driver and used to hold the bytes to be written until they are written or the iorequest is aborted. Bottom line: If it works with the serial.device and doesn't work with the supra driver, there's a bug in the supra driver. Interesting Corallary: If a function *doesn't* work with serial.device, it may mean simply that there's a bug in the serial.device. Our ASDG test suite contains a number of function combinations which *should* work but don't on the serial.device due to its deficiencies. They *do* work as you would expect from the Rom Kernel Manual on the ASDG Dual Serial Board, however. pk -- Perry Kivolowitz, ASDG Inc. ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 (what was that about ``giggling teenagers''?)
cmcmanis@sun.Eng.Sun.COM (Chuck McManis) (09/12/89)
In article <832@madnix.UUCP> perry@madnix.UUCP (Perry Kivolowitz) writes: >Interesting Corallary: If a function *doesn't* work with serial.device, >it may mean simply that there's a bug in the serial.device. Our ASDG test >suite contains a number of function combinations which *should* work but >don't on the serial.device due to its deficiencies. They *do* work as you >would expect from the Rom Kernel Manual on the ASDG Dual Serial Board, however. And as good developers you (ASDG) have scrupulously documented every single inconsistency you have found in the serial.device and reported them to Commodore with small test cases that demonstrate the problem. Right ? Possibly even given them a copy of the test suite you developed? If the 1.4 serial.device isn't bug free, and you didn't do this Perry, I'll hold your company personally responsible. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses. But you knew that, didn't you.