Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!killer!texbell!merch!cpe!hal6000!trsvax!uhclem From: uhclem@trsvax.UUCP Newsgroups: comp.unix.xenix Subject: Re: 8-port serial async cards?? Message-ID: <196500026@trsvax> Date: 8 Feb 89 20:00:00 GMT References: <427@ispi.UUCP> Lines: 86 Nf-ID: #R:ispi.UUCP:427:trsvax:196500026:000:3891 Nf-From: trsvax.UUCP!uhclem Feb 8 14:00:00 1989 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. "Thank you, Uh Clem." Frank Durda IV @ ...decvax!microsoft!trsvax!uhclem ...sys1!hal6000!trsvax!uhclem If it made sense, they wouldn't buy a new one.