karl@ddsw1.MCS.COM (Karl Denninger) (03/31/89)
Hello net.oracle! :-) We've got a small problem. There's this serial driver that we have for Xenix & 386/ix. The problem is that we need to handle VP/IX sessions on it, and currently it won't work - - complains about not being able to set the mode it wants, and then it's boom-boom time. Obviously since we're coming from a terminal we can't generate scan codes (they don't exist!). How do we kludge things in such that it will work, even if only in "stupid" mode. Any help, code fragments, etc. much appreciated. --- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc.
fmcgee@cuuxb.ATT.COM (~XT6510300~Frank McGee~C23~M24~6326~) (03/31/89)
In article <3200@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >Hello net.oracle! :-) >We've got a small problem. There's this serial driver that we have for >Xenix & 386/ix. The problem is that we need to handle VP/IX sessions on it, >and currently it won't work - - complains about not being able to set the >mode it wants, and then it's boom-boom time. >Obviously since we're coming from a terminal we can't generate scan codes >(they don't exist!). How do we kludge things in such that it will work, >even if only in "stupid" mode. Please note that these comments refer to the AT&T Simultask product which is based upon VP/ix; your mileage may vary on other vendors products. There are two issues here; the tty driver, and support of ascii terminals. I haven't done any tty driver work myself, but as I understand it you need to have a fairly "complete" tty driver to get it to work with Simultask. It needs to support a lot of the ioctl's that some ports card manufacturers leave out since they are seldom used. I don't know exactly which ones you need to have to get VP/ix to work. I'll look and re-post if I find something. As for ascii terminal support, there are special terminal translation files in /usr/vpix/term/* to support non-scancode terminals. It is well documented in the AT&T docs how to get the translations you want. A few things : o You'll want to re-map keys like ALT, PgUp, Ins, Del, etc. since many ascii terminals don't have these, yet many MSDOS applications require these (and don't forget those all-important function keys too). o Your terminal will probably have to be 80 columns by 25 lines, EXACTLY. I tried running ST 386 in a layers window that was too wide and it munged things up. If your terminal is only 24 lines, count on one line being mysteriously eaten. Note that there are PC scancode terminals out there (the AT&T 605 and some Wyse terminals can do this). The stuff in /usr/vpix/term/* supports an init string and a closing string that you can use to take it in and out of scancode mode. The big advantage to those terminals though is that they have all the right keys in all the right places (atleast for a pc anyway), and have 25 lines. You can run ST 386 in a layers window, but you need 3.2 Release 2.1 for it to work (they must have changed the layers tty driver in the update). It DIDN'T work on vanilla AT&T 3.2. Once I set my default window size to 25x80, programmed f1-f8, and installed a terminfo to know what f1-f8 were sending it worked fine. 7 windows, all running ST 386 concurrently. My guess is your tty driver isn't complete enough. The error you mentioned was the same error I got when I tried to run it in a layers window with vanilla 3.2. Hope this helps, I'll try to find the specific ioctl's you need to support. -- Frank McGee, AT&T Tier 3 Indirect Channel Sales Support attmail!fmcgee
clewis@ecicrl.UUCP (04/01/89)
In article <3200@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >We've got a small problem. There's this serial driver that we have for >Xenix & 386/ix. The problem is that we need to handle VP/IX sessions on it, >and currently it won't work - - complains about not being able to set the >mode it wants, and then it's boom-boom time. > >Obviously since we're coming from a terminal we can't generate scan codes >(they don't exist!). How do we kludge things in such that it will work, >even if only in "stupid" mode. DOSMODE has nothing to do whatsoever with scan-code-mode on the terminal. Support of scancode and nonscancode mode terminals is *entirely* within VP/IX (eg: /usr/vpix/term/wyse60, /usr/vpix/term/vt100 etc.) and has nothing to do with the serial driver. The VP/IX administrator's guide describes how to support non-scancode terminals on serial lines. VP/IX support requires that the device driver supports quite a number of extra ioctl's over and above the normal termio.h stuff. Eg: stuff in asy.h and v86.h and a few other headers. In brief, VP/IX needs to set DOSMODE on or off - which is an driver flag which enables/disables various driver functionality, including: - allow device driver activity to appear as virtual interrupts to the emulated DOS environment. - implementation of a pseudo "raw" input mechanism. - whenever a DOS program attempts to read/write a virtual COMM port register, VP/IX catches it and turns it into a ioctl, which it hands to the driver. The driver then must attempt to simulate what is actually an 8251 register peek or poke on whatever hardware you may have (eg: dual-ported intelligent serial I/O card which uses entirely different chips). Eg: it must be able to convert a write to the *virtual* 8251 baud register into the appropriate commands on the *real* hardware. - change start/stop characters and understand their behaviour. Read the manual pages on asy, v86, VP/IX references and whatever else you can find. Except for the 8251 emulation (which many DOS programs don't need), it's only about 15 lines. But as far as I can tell, nobody's ever published examples. And the code *is* tricky. I implemented VP/IX functionality into a smart card driver (about the time Computone first got theirs working), but I needed help. We did get it working. Even though our board never went into production, I couldn't publish the source even if I still had it. The ISC VP/IX documentation is reasonably complete regarding the routines and parameters required for doing this, but sadly lacking in any description of why or how they should be used. [Sort of like telling you how to turn a steering wheel, without telling you why you'd ever want to] -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)