rfrye@netxcom.UUCP (Rob Frye) (01/26/89)
In article <8417@dasys1.UUCP> eddjp@dasys1.UUCP (Dewey Paciaffi) writes: >We are considering upgrading our 386 XENIX box from an ARNET 4 port 9600 baud >board, to a Bell Technologies ACE 8 port 38,400 baud board. I, too am interested in that card. Please post responses; I think others may wish to know. Also, if anyone is using any other 8-port serial board on SCO Xenix 386 that you like (particularly that will handle 38.4kbps) please clue us in! :-> -- Rob Frye NetExpress Communications, Inc. Phone: (703)749-2234 1953 Gallows Road, Suite 300 uucp: uunet!netxcom!rfrye Vienna, VA 22180
jbayer@ispi.UUCP (Jonathan Bayer) (01/27/89)
In article <1135@netxcom.UUCP> rfrye@netxcom.UUCP (Rob Frye) writes: >may wish to know. Also, if anyone is using any other 8-port serial board >on SCO Xenix 386 that you like (particularly that will handle 38.4kbps) >please clue us in! :-> We use the Digiboard series of cards. We have used the digiboard 8, the digiboard 8s, and the digiboard 8i. The 8 and the 8s are essentially the same with difference that the 8s uses 16450s, and the 8 uses 8250s. The 8 will not work in systems which have clock speeds greater than about 8 Mhz (even if the bus speed is 8, if the cpu is at 16 the card will not work). The 8s works fine. The 8 can be upgraded to the 8s by replacing the 8250s with 16450s. The 8i is an intelligent buffering board. It works on all systems. We run all these cards at 9600 baud with no problem (8 users or more). We use the 8i for applications such as several serial printers connected to the system where the io load is heavy. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi
frank@rsoft.UUCP (Frank I. Reiter) (01/28/89)
I have an AST 8-port XN Turbo (quite a name!) that works just great with
terminals, but does not properly support modem control. As I am tired of
waiting for the "New drivers which will fix everything" I am offering this
card for sale at below dealer cost to anyone who wants it.
Email if interested.
--
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Frank I. Reiter \ / UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank
Langley, British Columbia / \ BBS: Mind Link @ (604)533-2312
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*jim@tiamat.FSC.COM (Jim O'Connor) (01/28/89)
In article <1135@netxcom.UUCP>, rfrye@netxcom.UUCP (Rob Frye) writes: > In article <8417@dasys1.UUCP> eddjp@dasys1.UUCP (Dewey Paciaffi) writes: > >We are considering upgrading our 386 XENIX box from an ARNET 4 port 9600 baud > >board, to a Bell Technologies ACE 8 port 38,400 baud board. > > I, too am interested in that card. Please post responses; I think others > may wish to know. Also, if anyone is using any other 8-port serial board > on SCO Xenix 386 that you like (particularly that will handle 38.4kbps) > please clue us in! :-> We use the Arnet Multiport board in two separate 386 systems and have very good results using it at 38400 baud. We never have all 8 ports running that fast (perhaps three at a time at most), so your mileage may vary if you plan on using all 8 at one time at 38400. --jim ------------- James B. O'Connor jim@FSC.COM Filtration Sciences Corporation 615/821-4022 x. 651
howardl@wb3ffv.ampr.org ( WB3FFV) (01/29/89)
In article <1135@netxcom.UUCP>, rfrye@netxcom.UUCP (Rob Frye) writes: > In article <8417@dasys1.UUCP> eddjp@dasys1.UUCP (Dewey Paciaffi) writes: > >We are considering upgrading our 386 XENIX box from an ARNET 4 port 9600 baud > >board, to a Bell Technologies ACE 8 port 38,400 baud board. > > I, too am interested in that card. Please post responses; I think others > may wish to know. Also, if anyone is using any other 8-port serial board > on SCO Xenix 386 that you like (particularly that will handle 38.4kbps) > please clue us in! :-> Well just as a suggestion, I would take a look at the Ultra-186 or the Smart Hostess from Comtrol corperation. I personally own the Smart Hostess and have been using it for sometime without any problems. I have two TB+ modems that I talk to at 19.2K, and run several terminals at 38.4K and it just zooms right along. The card works well and supports full modem control (which I could never get to work right on the Bell ICC cards I used to own), and so far none of my news feeds that use TB+ modems have ever had to wait because of slow throughput from my end. I have heard a lot of horrow stories about many manufactures, and even experienced a few of my own, and am very happy with my choice of the Comtrol board. I do not work for Comtrol, but am a satisfied customer, and would for that reason recomend there product... ------------------------------------------------------------------------------- Internet : howardl@wb3ffv.ampr.org | Howard D. Leadmon UUCP : wb3ffv!howardl | Fast Computer Service, Inc. TELEX : 152252474 | P. O. Box 171 Telephone : (301)-335-2206 | Chase, MD 21027-0171
bill@bilver.UUCP (bill vermillion) (02/04/89)
In article <823@wb3ffv.ampr.org> howardl@wb3ffv.ampr.org ( WB3FFV) writes: >In article <1135@netxcom.UUCP>, rfrye@netxcom.UUCP (Rob Frye) writes: >> In article <8417@dasys1.UUCP> eddjp@dasys1.UUCP (Dewey Paciaffi) writes: >>>We are considering upgrading our 386 XENIX box from an ARNET 4 port 9600 baud >>>board, to a Bell Technologies ACE 8 port 38,400 baud board. >> >> I, too am interested in that card. Please post responses; I think others >> may wish to know. Also, if anyone is using any other 8-port serial board >> on SCO Xenix 386 that you like (particularly that will handle 38.4kbps) >> please clue us in! :-> You might want to look at the Anvil Stallion. Board is 8 or 16 in an AT configuration or up to 12 in an AT system. It does most of the kernel functions on the board and is fast. The ONLY drawback I have with it is that sometimes a user would get a print process started and under the old system I could kill the process. Under the Anvil the process is dumped to the board and within about 2 seconds the system thinks the job is done with - and then I can't kill it. I haven't timed it - but Anvil says throughput to the board is in excess of 160kbs - it can sustain 9600 to 16 ports at a time. It also goes up to 38k. The only thing it doesn't have - and is due out shortly - is a driver for transparent print like the Computone board. If you are not familiar with the Computone variant the keyboard does not lock up while you are printing to an attached terminal. -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
karl@ddsw1.MCS.COM (Karl Denninger) (02/06/89)
In article <390@bilver.UUCP> bill@bilver.UUCP (bill vermillion) writes: >In article <823@wb3ffv.ampr.org> howardl@wb3ffv.ampr.org ( WB3FFV) writes: >>In article <1135@netxcom.UUCP>, rfrye@netxcom.UUCP (Rob Frye) writes: >>> In article <8417@dasys1.UUCP> eddjp@dasys1.UUCP (Dewey Paciaffi) writes: >>>>We are considering upgrading our 386 XENIX box from an ARNET 4 port 9600 baud >>>>board, to a Bell Technologies ACE 8 port 38,400 baud board. >>> >>> I, too am interested in that card. Please post responses; I think others >>> may wish to know. Also, if anyone is using any other 8-port serial board >>> on SCO Xenix 386 that you like (particularly that will handle 38.4kbps) >>> please clue us in! :-> > >You might want to look at the Anvil Stallion. Board is 8 or 16 in an AT >configuration or up to 12 in an AT system. > >It does most of the kernel functions on the board and is fast. The ONLY >drawback I have with it is that sometimes a user would get a print process >started and under the old system I could kill the process. Under the Anvil >the process is dumped to the board and within about 2 seconds the system >thinks the job is done with - and then I can't kill it. > >I haven't timed it - but Anvil says throughput to the board is in excess of >160kbs - it can sustain 9600 to 16 ports at a time. It also goes up to 38k. >The only thing it doesn't have - and is due out shortly - is a driver for >transparent print like the Computone board. If you are not familiar with the >Computone variant the keyboard does not lock up while you are printing to an >attached terminal. ARGH! The Anvil board may be fine for 16 terminals, but I wouldn't think of using it with even TWO 19200 baud modems. Why? Because they haven't done the work required to get the board to handle input at that speed. Yes, this is only about 20kbs -- TERRIBLE performance on input. Admittedly, output is much better -- as long as there's no input going on! I don't know if I buy 160kbs though.... When our Telebit comes online, my "19200" baud serial terminals' display rate goes down to under 9600 bps -- because the board is overloaded and giving priority to the input (thank god they did get this right). We've been in contact with Anvil both here in the States and Australia (the place of manufacture) and they were _unaware_ of this being a problem. In fact, their people told us that their boards "aren't normally used in that manner" (!) Anvil advised us that they would be looking into the problem and attempt to fix it, but that they weren't confident of being able to do so (this I don't understand -- we're talking RAW input -- which should be more efficient than "cooked" output, no -- besides there's an 8MHZ 80186 on that board!). This conversation took place about 6 weeks ago -- and we have not heard anything from Anvil yet regarding a possible fix. One more thing -- their latest drivers don't work right (with the transparent print and all). If you must use this card, get the older drivers (2.1.7); the "new improved drivers" not only lost characters on input, but had port and system lockup problems as well! The older drivers don't work with VP/ix or attached printers.... so if you need that, you're out of luck. They also occasionally "forget" to output the last character in the output buffers for anywhere from 5-10 seconds after streaming output stops..... If you're intending to do high speed modem work, choose something else. -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
debra@alice.UUCP (Paul De Bra) (02/06/89)
In article <2870@ddsw1.MCS.COM> karl@ddsw1.UUCP (Karl Denninger) writes: }>... }>I haven't timed it - but Anvil says throughput to the board is in excess of }>160kbs - it can sustain 9600 to 16 ports at a time. It also goes up to 38k. }>... }ARGH! } }The Anvil board may be fine for 16 terminals, but I wouldn't think of using }it with even TWO 19200 baud modems. } }Why? Because they haven't done the work required to get the board to handle }input at that speed. } }Yes, this is only about 20kbs -- TERRIBLE performance on input. } }Admittedly, output is much better -- as long as there's no input going on! }I don't know if I buy 160kbs though.... } }When our Telebit comes online, my "19200" baud serial terminals' display }rate goes down to under 9600 bps -- because the board is overloaded and }giving priority to the input (thank god they did get this right). You realize you are being very demanding (even for a board with an 8Mz 80186). We used to have an old Altos, with controllers for 8 terminals. We used 1 port for 4800 baud uucp-input, and the others for 9600 baud terminals. Any uucp traffic (input) on the one port would visibly slow down output on the other terminals (even when using only one) to 1200 baud. Those boards used a 4Mhz Z80 I believe. So I doubt whether there is much they can do to inprove the Anvil board by much. If we rate the processor at about 0.5 MIPS, and we assume 19200 baud input and output on all 16 lines, that is over 60000 chars/sec together, that leaves less than 10 instructions to handle a single char. No way this can be done. What they claim (160kbs) corresponds to 16 lines at 9600 baud in only one direction, but even then you have only about 40 instructions to handle a character. This could be hairy already. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
bill@bilver.UUCP (bill vermillion) (02/07/89)
In article <2870@ddsw1.MCS.COM> karl@ddsw1.UUCP (Karl Denninger) writes: >In article <390@bilver.UUCP> bill@bilver.UUCP (bill vermillion) writes: >>In article <823@wb3ffv.ampr.org> howardl@wb3ffv.ampr.org ( WB3FFV) writes: >>>In article <1135@netxcom.UUCP>, rfrye@netxcom.UUCP (Rob Frye) writes: >>>> In article <8417@dasys1.UUCP> eddjp@dasys1.UUCP (Dewey Paciaffi) writes: >>>>>We are considering upgrading our 386 XENIX box from an ARNET 4 port 9600 baud >>>>>board, to a Bell Technologies ACE 8 port 38,400 baud board. >>>> >>>> I, too am interested in that card. Please post responses; I think others >>>> may wish to know. Also, if anyone is using any other 8-port serial board >>>> on SCO Xenix 386 that you like (particularly that will handle 38.4kbps) >>>> please clue us in! :-> At this point I said: >>You might want to look at the Anvil Stallion. Board is 8 or 16 in an AT >>configuration or up to 12 in an AT system. ...... And you said ..... >ARGH! > And then a lot of point I hadn't heard about. Thanks for the info. (much deleted!) >One more thing -- their latest drivers don't work right (with the >transparent print and all). ........ > >The older drivers don't work with VP/ix or attached printers.... I don't have the transparent print drivers, but do have the older drivers and haven't had a problem with local printing. Have not used local print with terminals, but with PCs that have dual ports, one for async the other for block transmission from a Burroughs. All I had to do was define the port to be the terminal port, and in the interface description just put the code to turn off the keyboard and turn on the port. At the end of the script I reversed it. For the word processor, Lex, there is a terminal description screen that permits me to tell the system what byte seqeunce turns on the port. Works fine. All this is on 386 SCO with a Model 80 IBM, and the anvil board. I did have one strange problem however. Sometimes a print job would not finish. It would just stop halfway through. This was on an Epson 320i, driven through an Anvil serial port. Turns out that when the print job thought it was through it appeared the port got turned off, or changed. At then ed of the rc file I added this line (stty </dev/tty007 9600 ixon ixoff -ixany; cat >/dev/null </dev/tty007 &) This kept the stty setting locked in and no more problems. Lee Penn gave me that one. > >If you're intending to do high speed modem work, choose something else. > Argh! NOW you tell me. Mine is in shipment now. But it's my own machine and I am the primary user. My current machine gets real doggy as it is when a netnews feed comes in on the TB - it can only get better. >-- >Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) >Data: [+1 312 566-8912], Voice: [+1 312 566-8910] >Macro Computer Solutions, Inc. "Quality solutions at a fair price" -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
frk@frksyv.UUCP (Frank Korzeniewski) (02/07/89)
In article <8878@alice.UUCP> debra@alice.UUCP () writes: >You realize you are being very demanding (even for a board with an >8Mz 80186). We used to have an old Altos, with controllers for 8 terminals. >We used 1 port for 4800 baud uucp-input, and the others for 9600 baud >terminals. Any uucp traffic (input) on the one port would visibly slow >down output on the other terminals (even when using only one) to 1200 baud. >Those boards used a 4Mhz Z80 I believe. Several years back I ported CCPM to a multi-processor. The configuration was a main processor 4MHz Z80 (yes that is 4). The passive satellites were 5Mhz 8088s. The console thruput with 8 satellites generating continuous console output (1 direction - out) was about 75,000 baud. An 8Mhz 80186 should be able to match this. All it takes is a lot of care in coding the routines in assembler. Frank -- ______________________________________________________________________________ || Frank Korzeniewski, Consulting Suite 137 || || Phone: (415) 799-1819 1564-A Fitzgerald Drive || || UUCP: uunet!frksyv!frk Pinole, CA 94564 ||
karl@ddsw1.MCS.COM (Karl Denninger) (02/08/89)
In article <8878@alice.UUCP> debra@alice.UUCP () writes: >In article <2870@ddsw1.MCS.COM> karl@ddsw1.UUCP (Karl Denninger) writes: >}>... >}>I haven't timed it - but Anvil says throughput to the board is in excess of >}>160kbs - it can sustain 9600 to 16 ports at a time. It also goes up to 38k. >}>... >}ARGH! >} >}The Anvil board may be fine for 16 terminals, but I wouldn't think of using >}it with even TWO 19200 baud modems. ..... >}Yes, this is only about 20kbs -- TERRIBLE performance on input. >} >}Admittedly, output is much better -- as long as there's no input going on! >}I don't know if I buy 160kbs though.... >} >}When our Telebit comes online, my "19200" baud serial terminals' display >}rate goes down to under 9600 bps -- because the board is overloaded and >}giving priority to the input (thank god they did get this right). > >You realize you are being very demanding (even for a board with an >8Mz 80186). We used to have an old Altos, with controllers for 8 terminals. >We used 1 port for 4800 baud uucp-input, and the others for 9600 baud >terminals. Any uucp traffic (input) on the one port would visibly slow >down output on the other terminals (even when using only one) to 1200 baud. >Those boards used a 4Mhz Z80 I believe. And you had a gawd-awfully stupid (1) driver for that "smart" board, or (2) I/O microcontroller code. I used to program controllers for the satellite earth-station market, using a synch protocol (no screwing around here or you LOSE frames; lost frames mean lost commands, and that was considered "not allowed" in the specs). The microcontrollers could EASILY handle 4 9600-baud lines using a 6Mhz Z-80, in mode 2, going in both directions, and STILL have enough left to provide ~20ms response to digital input changes as well as a console display. This with no hardware assist, and with with the overhead of a multitasking operating system as well (PROM-based with NVRAM config!) Yeah, it's really tough to do. The code took a LOT of work; I wrote and debugged the darn stuff, I ought to know. But goddarn it, it did work, with hardware flow control (and soft if you wanted), and it ran like gangbusters. The Z-80 _is_ reasonably talented in handling interrupts, but then again, it's also got about 1/4 the processing power (if that) of an 80186! DEC does 9600 baud, 8 lines up, BOTH directions on the DHV-11M with two 8051's (I believe these are 2 or 4Mhz parts; it's been a while). Also an 8-bit slug of a processor; only one processor actually gets/puts characters from what I understand, the other is essentially a bus/dma interface. This kind of performance is _easily_ achievable, and it's all I ask for. Meet the darn spec, don't fudge the spec (ie: "it's only good for output-only") or at least SAY the 160kbs is only for output.....and that input capacity is 20 kbs! Then I won't go out and buy a nice expensive boat anchor, or something that will have our users wanting me strung up by the short hairs. If you can't at least do this, then make the darn source code to your drivers available (Anvil has refused) so I can fix (or rewrite) them. As for our (or anyone else) stealing them, do you really think it does any good to have that code without the boards?! (In any event, we offered to sign a non-disclosure on it, but that wasn't good enough). Look, my '386 CPU can handle more SIOs at high speed, AND handle the disk controllers, and user processes, and tape drives, etc..... and not lose characters. >So I doubt whether there is much they can do to inprove the Anvil board >by much. If we rate the processor at about 0.5 MIPS, and we assume >19200 baud input and output on all 16 lines, that is over 60000 chars/sec >together, that leaves less than 10 instructions to handle a single char. >No way this can be done. What they claim (160kbs) corresponds to 16 lines >at 9600 baud in only one direction, but even then you have only about >40 instructions to handle a character. This could be hairy already. Sure it is. It was hairy when I was doing controllers, too. Every line of the driver was scrutinized; that code was _hand_ optimized and every last clock cycle squeezed out. But it worked, with hardware flow control, on a processor that was awfully darn busy doing other things as well! Remember what this was carefully -- a 6Mhz Z-80, with a CTC (timer chip) as well as four SIO's (2 channels each), programmable speed/parameter selection, the works. It normally ran 8 units of some hardware via a proprietary serial protocol (packet monster); asynchronous messages were the norm. It's tough to do -- that's why there's dual-ported memory on the board, and arbitration circuitry. That's why there's a bunch of local memory, and 32K of PROM there too. And that's why the 8Mhz '186 to do the processing. So you have the resources to blast and accept characters at that speed. Actually, all I really want is the ability to run 9600 baud input/output on 8 lines. That's fine. The board should be up to this level of performance; it's what they claim for it! 9600 bps * 8 ports * 2 directions = 153,600 bps, or just about what Anvil claims the stallion will do. There's no way I could actually DO this. Heck, I can't get 1/5th of that performance on input channels! I'd bet I could eat a character and set it up for transfer to the Unix/Xenix host (in raw mode) in under 20 instructions. In "cooked" mode I expect higher overhead; ok, so it's 30 or even 40 instructions per character (on input). I'm willing to accept (and know there will be) a higher overhead for "special" characters (Xon/Xoff), or modem control signals (hardware flow control, for example). My current problems are in raw mode, by the way.... Wow, that was hard. If I sound frustrated, it's because I AM frustrated. That board was #$@%^& expensive! And it's not met my expectations. Gimme commented source code to the existing driver, OR a technical description (with port assignments and meanings) and schematics for it's construction. Alternately, give me a hardware techie who can design a board (with access to the parts needed), thinks progressively (which doesn't always mean the "biggest" hardware; the craftyist is what I want to see...), who wants to make a nice chunk of change but will wait for his/her (substantial) chunk until the board PROVES itself on the market, can prototype the thing, and works well with prog-types. I'll blow the net's socks off, and there will finally be a smart board that does all the "nice" things and gives REAL performance. Like 8 Trailblazers up screaming, no problem and NO slowdown (if your CPU can feed it fast enough!). Yeah, I'm gonna sell the things if we do this. So what. (you think I'd do this much work for nothing? What, you nuts?! :-) Who wants one? :-) Note that the ISA bus (AT) is good for 8 MB/second or so.... this ought to be relatively easy to do up to 500kbytes/sec or so; for better than that you're going to have to go for a bus master setup (which doesn't work on all systems) or use the new EISA bus (32-bit, 30MB/sec!). Either of these approaches will require a monster (or some clever trickery) for the onboard processor. Then again 500kb/sec is more than enough for almost anyone! -- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
uhclem@trsvax.UUCP (02/09/89)
R5>Anvil advised us that they would be looking into the problem and attempt to R5>fix it, but that they weren't confident of being able to do so (this I don't R5>understand -- we're talking RAW input -- which should be more efficient than R5>"cooked" output, no -- besides there's an 8MHZ 80186 on that board!). This R5>conversation took place about 6 weeks ago -- and we have not heard anything R5>from Anvil yet regarding a possible fix. The problem on some of these boards IS the choice of the 186. Face it, the intel 80186 is rather limited on IN/OUT opcodes. Boards that use 8530 serial chips with a 186 further complicate the problem by performing all communication to a port via two ports. One is the data path, the other is a control pointer that selects what register the other port will access, very muck like the 6845 CRTC. Hardly any of these boards bother to add the glue necessary to use these as memory mapped devices, so you find code like this: mov dx, ctlportA mov al,RR2 ;Want to read Rx status out dx,al jmp $+2 ;Because they pick the 8530's ;with slow recovery time as much ;as 4 8530 clocks + 200 usec mov dx,datportA in al,dx ;Read status test al,CHARAVA ;Is a Char available jnz xxx mov dx,ctlportA ;Point at data reg mov al,RR8 out dx,al jmp $+2 mov dx,datportA in al,dx ;Read byte Any questions? You haven't even checked for framing or parity errors yet, much less cleared them or resolved the interrupt on the embedded 8259. Although 8250's require less juggling, they require more intervention than the 8530. And if you find a board with an 8251 on it, keep walking very fast. The 8530 also provides vectored interupt support with 8 vectors per chip (four per port, Rx, Tx, Special, Error), but the 186 interrupt system doesn't understand Z80 IM2 vectoring, so it usually isn't used, and each chip must be polled to find out which one (or more) of the eight items generated the interrupt. So with an 8259 interrupt controller, the best it can do is narrow the source of the interrupt down to a chip. Then you must read the interrupt register on the chip and call all the routines necessary to handle the eight possible pending interrupt sources. An 80186 with an 8030 (a version of the 8530 that lends itself to being memory-mapped, all 16 registers directly accessible) would be far more efficient. For example, an memory-mapped 8030 doing the same task as above: mov ax, Seg8030A mov es,ax mov bx, Off8030A test es:[bx+RR2],CHARAVA ;Is a Char available jnz xxx ; jmp $+2 ;Not normally needed on ; ;the 8030 but you can add it mov al,es:[bx+RR8] ;Read char I forgot to mention wait states. Although they may have an 8MHZ 80186 and 150nsec memory (slowest possible with 0 wait states), some designers made too lengthy or used to slow address decoding schemes and were forced to add a wait state. Sometimes these are added to help handle arbitration when the onboard memory can be accessed by the host CPU (286/386). So the 186 may actually be running at an effective 6MHZ or less. My ideal board would use a Z280 and an 8030. The Z280 reads IM 2 interrupts so the exact routine necessary could handle each interrupt without any other checking. (A Z180/HD64180Z could also be used but you would need at least 10MHZ to handle 38,4000 on 8 lines.) The Z280 has onboard CTC's and DMA, so this would reduce the external part count. The plain old 6MHZ Z80 can handle eight ports, but max would be 8 9,600 baud conversations, or 4 19,200. <My opinion, and not that of my golden retreiver who is busily applying for a federal grant so he can develop HDTV compression algorithms...> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...sys1!hal6000!trsvax!uhclem If it made sense, they wouldn't buy a new one.