From JT@zfja-gate.fuw.edu.pl Monday May 25, 1992 4:37:44 p.m. Date: Mon, 25 May 92 15:15:13 PST From: "Jerzy Tarasiuk" To: "Thomas Lenon" <70150.510@CompuServe.COM> Subject: Re: PA0GRI, NOS, 3com503 Ethernet adapter cards ============================================================================== I unpacked archive containing packet drivers (version 9), deleted what was apperently for cards other than 3C503 and packed remaining files into few .ZIPs. They all are available by sending mail to containing line(s) GET filename. Here is list what is available there. Note listserv will send it UUENCODEd and for example SRC3C503 will be 50kB. packet\3c503\SRC3C503.ZIP 36307 packet\3c503\PKT-TXT.ZIP 6445 packet\3c503\NO-NEED.ZIP 13376 packet\3c503\PKTSPECS.ZIP 19832 packet\3c503\README.ZIP 10994 packet\3c503\PKT-MISC.ZIP 13278 packet\3c503\PKT-PROG.ZIP 30563 packet\3c503\PKTNOTES.ZIP 13414 Length Date Name SRC3C503.ZIP (full source for 3C503 packet driver) PKTSPECS.ZIP: (description of parameters, specifications) 21250 08-16-90 DRIVERS.DOC 39003 01-30-90 PACKET_D.109 README.ZIP: (list of files, who wrote it, last changes) 26124 08-29-90 READ.ME 824 08-15-90 README.1ST PKT-TXT.ZIP: (common Q&A, who wrote...) 4684 02-20-89 PACKETQA.TXT 7960 08-22-90 SUPPORT.TXT PKTNOTES.ZIP: (discussion on some problems) 6116 07-29-89 3C503.NOT 8445 07-26-90 8259.NOT 4697 06-11-90 PROMBOOT.NOT 3319 05-09-90 DESQVIEW.NOT 4143 03-13-90 NOVELL.NOT PKT-MISC.ZIP: 12735 03-02-89 COPYING (license) 8884 03-27-90 PACKET.DOC 5760 08-10-89 ROMREL.DOC+.COM (if you use boot ROM) 1288 08-29-90 HOWTOGET.IT (obsolete I suppose) PKT-PROG.ZIP: (some programs used for debugging) 5198 06-25-90 DUMP.C 3816 07-24-90 PKTADDR.ASM 4655 07-24-90 PKTALL.ASM 4089 07-24-90 PKTCHK.ASM 1883 03-13-90 PKTERR.ASM 4920 07-24-90 PKTMODE.ASM 5811 07-24-90 PKTMULTI.ASM 8785 07-24-90 PKTSEND.ASM 5221 07-24-90 PKTSTAT.ASM 3557 08-16-90 TERMIN.ASM 19735 07-24-90 TRACE.ASM 495 01-12-90 GETEA.ASM 4464 07-27-90 GENERIC.ASM NO-NEED.ZIP: (programs and subroutines not needed for 3C503) 756 02-13-90 GETENV.ASM 1186 03-13-90 MULTICRC.ASM 654 03-06-90 MULTIFIL.ASM 2630 06-23-90 OCCUPIED.ASM 992 03-07-90 TIMEOUT.ASM 4904 08-09-90 MAKEFILE 12150 03-08-88 EXE2COM.C 8774 03-08-88 EXE2COM.DOC Let me know if you need anything more. And be aware if you need pay money for mail received via CompuServe, sending large programs on diskette is less expensive. Also I suppose it is nonsense to send empty diskette, probably postage costs much more than diskette. 73's, JT From JT@zfja-gate.fuw.edu.pl Thursday June 11, 1992 3:23:33 p.m. Date: Thu, 11 Jun 92 14:55:03 PST From: "Jerzy Tarasiuk" To: "Alan Cox" Cc: tcp-group@ucsd.edu Subject: Re: Shared Interrupt NOS In-Reply-To: your msg <17528.9206101751@pyr.swan.ac.uk> ============================================================================== Your code may work incorrectly if async port board (or one of its ports internally) signals interrupt by level rather then pulse. IBM solved problem of interrupt sharing in the following way: 8259 interrupt controller is positive-edge-triggered and when there is no interrupt, it has high level on its input; interrupt is requested by changing the level for short time (microsecond) to low and then back to high, the interrupt line is open-collector-driven and has pull-up resistor. But many boards doesn't use the idea and I dont' remember to see any async port board implementing it. I just checked COM ports in my AT - both hold IRQ signal high when there is interrupt to be served and low when no interrupt! What result is possible ? If two ports share same IRQ line and then: 1. port 2 raises IRQ; 2. program looks IIR of port 1; 3. port 1 raises IRQ; 4. program looks IIR of port 2 services interrupt, then looks IIRs of remaining ports and returns; the result is: IRQ line remains high, 8259 already interrupted CPU once and has no reason to interrupt CPU again (remember it is edge-triggered) - so no more interrupts serviced. Of course, I don't know what board you use, possibly a "good" one. But, as I wrote, I don't remember to see any "good" board till now. Simple way to check if board can be "good": out base+4(ModemCtrl),8; out base+1(InterruptEnable),2(TxHE); out 0x20,0xA; delay 1us; in 0x20 - result will have bit set (bit number is same as IRQ level); then out base+1,0 may clear it, if it does, board is not "good". "Good" board causes no problem: the low level pulse causes 8259 to know it should interrupt CPU again when interrupt is acknowledged. 73's, JT From JT@zfja-gate.fuw.edu.pl Friday June 12, 1992 1:36:00 p.m. Date: Fri, 12 Jun 92 13:02:49 PST From: "Jerzy Tarasiuk" To: "Roy Engehausen" Cc: "Alan Cox" , Subject: Re: Shared Interrupt NOS In-Reply-To: your msg of Thu, 11 Jun 92 11:11:06 PDT Alan's msg <328.9206112017@pyr.swan.ac.uk> ============================================================================== > The MBBIOS async handler that I wrote and distribute solved this > problem. As long as the shared cards OR their interrupt lines > together then MBBIOS will work. All ports on a given IRQ line are > polled when an interrupt occurs and polling continues until one pass > is made with no port requesting service. Yes, this is correct way. And this only. I thought about checking IRQ by command to 8259, but it doesn't work: even if IRQ is still high, 8259 has 0 in corresponding bit of IRR (interrupt request register). It's a pity - reading 8259 status would be more efficient... As I understand your algorithm is: do { anyserved=0; for(portindex=0;portindex To: tcp-group@ucsd.edu Subject: Re: COM port IRQs ============================================================================== Ron Murray (vk6zjm) suggests use IRQs of second 8259. OK if software is dedicated for AT. On XT it is useless and must have software capable to share IRQs or limit number of COMs. I use AT, but suppose there are still many XT-s running NOS. Of course, XT cannot service many serial ports, it is too slow... 73's for all hams using XT-s (>4.77MHz, I hope), JT From JT@zfja-gate.fuw.edu.pl Thursday October 1, 1992 10:14:31 p.m. Date: Thu, 1 Oct 92 21:43:00 PST From: "Jerzy Tarasiuk" To: "Tyler Barnett N4TY" Subject: Re: your 16550A FIFO question In-Reply-To: <199210011727.AA04247@interlock.lexmark.com> (your msg of Thu, 1 Oct 1992 13:27:59 -0400) ============================================================================== > I am posting this in hope that Phil Karn KA9Q will see it and respond. > Phil, am looking for some async support C routines that take advantage > of the 16550A FIFO. I have ftp'd several files such as 8250.c > and others, but i don't apparently have them all. Most important are i8250.c and i8250.h, look for FIFO_SETUP, procedures which are there are called from asy.c. Some code for interrupt servicing is in asyvec.asm and pcgen.asm. The code purpose is to reduce stack use, it does the following: push ds, load data segment value to ds, save ss/sp, in the segment, load ss/sp - this all to switch to local stack for a case no enough space on original, push all other registers (to new stack), send EOI to 8259(s), call asyint(device_index) (using C calling convention), if asyint returned 0 (long zero in dxax if @DataSize, otherwise short in ax) { pop all saved registers, restore ss/sp, pop ds, iret } else { almost same but first save dxax as addr and jump to it instead iret (this is to handle chained interrupts) }. There is a bug: value returned by asyint must be always far pointer regardless of @DataSize. Names of interrupt routines in asyvec are asyXvec, X=device_index. (I looked into GRINOS code but suppose Karn's is same). 73's, JT From JT@zfja-gate.fuw.edu.pl Saturday October 10, 1992 1:48:28 p.m. Date: Sat, 10 Oct 92 12:48:24 PST From: "Jerzy Tarasiuk" To: "James Bennett" Subject: Re: Hardware information In-Reply-To: <9210092029.AA11091@iris.Ariel.YorkU.CA> 9 Oct 92 16:29:01 -0400 ============================================================================== > Being a poor humble student lacking the means to purchase the vast > array of documentation and manuals required for every piece of IBM > pc related hardware...could you please send ME a copy of this I put all what I found on my ftp/mail server. 4 files: FDC-MISC.ZIP A 42391 DMA-NOT.ZIP A 3260 BIOS.ZIP A 87149 BIOS-CMT.ZIP A 12251 There is probably nothing about 8259 programming. I tried it without success. The only what is easy: base ports for interrupts controllers are 0x20 and 0xA0 (AT only). Ports base+1 are mask registers. Setting a bit disables interrupt (bit 0 (lowest) is for IRQ0). Corresponding interrupt vectors: 08..0F and 70-77. The second controller is cascaded through IRQ2 of first, so don't mask it unless need mask all of IRQs 8..16. 8259 doesn't accept next interrupt of same level until gets End-Of-Interrupt command or is programmed for auto-EOI mode, to send EOI need write to base port 0x20 or 0x60+IRQ_number (e.g. for IRQ 14 can write 0x64 to port 0xA0 and 0x62 to port 0x20 - note it is cascaded, an exception is IRQ9 because it is used instead IRQ2 and BIOS sends EOI to 2nd 8259, since you need send EOI (0x20 or 0x62) to port 0x20 only). Few commands other than EOI are simple to use: 0x0A - read IRQ_Request 0x0B - read IRQ_In_Service (they select what can be read from base port unless other info was requested by other command, the second is useful to check if IRQ7 or IRQ15 is real interrupt or a default interrupt in case CPU didn't accepted INT signal and the interrupting device cleared IRQ or to check what IRQs are serviced if more than one is serviced by same routine), 0x0C - poll, it causes next read from base port will read 80h+IRQ and the controller will assume cpu accepted interrupt (the read can be done with interrupts disabled instead normal interrupt, NOTE MUST EXECUTE INTERRUPT SERVICE AFTER THE READ) or will read 0 (probably, the only what is known is highest bit is 0), seems 0x0C has side effect of 0x0A. The POLL command can be combined with 0x0A or 0x0B (by ORing bits), will read poll value first, then IRR/ISR (I didn't tried it). > Have a nice day. Thanks From JT@zfja-gate.fuw.edu.pl Tuesday October 20, 1992 1:06:54 p.m. Date: Tue, 20 Oct 92 12:51:38 PST From: "Jerzy Tarasiuk" To: Eyal Peleg Subject: Re: Hardware information ============================================================================== (I'm not sure but probably I didn't sent you reply to this message) > Date: Fri, 16 Oct 1992 00:22:56 +0200 > Message-Id: <199210152222.AA09440@techst02.technion.ac.il> > thanks for the info, > did you ever use the 8253 to do an action that you need to do in background > but faster then 18.2 hz ? > if you did - how did you managed the time probelms ? I didn't. I wrote a program playing music (using 8253 as "6 bit DAC") which needed to service interrupts at 19kHz and I didn't invoke BIOS from it because the program was time-critical. After it finish play, it computes how many timer interrupts should be during the time and invokes INT 8 by CPU instruction in loop. For background program should add the count sent to timer to word variable and invoke old INT 8 handler every time a carry results from the addition (if no carry, should send EOI to 8259 without invoking BIOS handler; of course, if timer is programmed for 0 should invoke BIOS handler on every interrupt although adding 0 never gives carry...). Note a background program cannot use BIOS/DOS services unless it checks BIOS service or DOS is not busy because BIOS services and DOS are not reentrant. From JT@zfja-gate.fuw.edu.pl Friday October 30, 1992 8:28:47 a.m. Date: Fri, 30 Oct 92 07:38:32 PST From: "Jerzy Tarasiuk" To: SL8NL@CC.USU.EDU Subject: Re: Port 20h ============================================================================== > Would you mind then sending me a copy of the exact bit layout of this register > and a few minor descriptions of the bits. I'm only asking because some > communication routines I DLed have those outports in it. Taking them out > crashes the system. Ports 20h and 21h are assigned to interrupt controller, Intel 8259. port 20h, bit4=1 ->ICW1 (start initialization sequence, described at end) OCW1: written to port 21h, masks IRQs by setting corresponding bit to 1 port 20h, bit4=0,bit3=0 ->OCW2 7 - R: rotate priority 6 - SL: level specified 5 - EOI: end-of-interrupt 43 = 0 210 - IRQ level without SL or EOI - set/clear rotate in automatic EOI mode R & SL - set priority, EOI & SL - EOI for specified level SL only - no operation, R & EOI - EOI with automatic rotate port 20h, bit4=0,bit3=1 ->OCW3 7 - 0 6 - ESMM: enables SMM 5 - SMM: (with ESMM=1) value for special mask mode 43 = 0,1 2 - P(poll) 1 - RR: enables RIS 0 - RIS: with RR=1 selects reading 0:IRR, 1:ISR ICW1 format: 765 - interrupt vector address bits 7-5 (8080/85 mode only) bit 5 ignored if ADI=0 4 - must be 1 for ICW1 3 - LTIM: 1 for level, 0 for edge triggered mode 2 - ADI: 1 - by 4, 0 - by 8 (8080 call instruction address increment) 1 - SNGL: 1 - single, 0 - cascade 0 - IC4: 1 - ICW4 used, 0 - no (equivalent to ICW4=0) After writing the ICW1 need write next ICW-s to port 21h: ICW2 - interrupt vector address bits 15-8 (8080/85 mode) - interrupt vector for IRQ0 (8088 mode, bits 0-2 and ADI ignored) ICW3 (used only if SNGL=0) for master: ones on bits corresponding to IRQs where slave are for slave: master IRQ to which the slave is connected ICW4 (used only if IC4=1) 765 - all zero 4 - SFNM: 1 for special fully nested mode 3 - BUF: 1 for buffered mode (use SP pin, since it cannot be used to distinguish master/slave and it must be set) 2 - M/S: 1-master, 0-slave (meaningless if BUF=0) 1 - AEOI: 1 for automatic EOI 0 - uPM: 1 for 8088, 0 for 8080/85 Special Mask Mode: means masking interrupt causes interrupts of lower priority are serviced even when EOI was not send. IRR: Interrupt Request Register shows which interrupts were requested (if non-zero is read on a bit, it is either masked, or blocked by servicing higher priority interrupt, or CPU is getting INT signal) ISR: Interrupt Service Register shows which interrupts being serviced (only interrupt servers can see non-zero in it, EOI clears one bit) Poll: treat next read from port 20h as interrupt accept signal from CPU data read will be: bit 7-1 if int, bits 0-2 IRQ level, other 0, the interrupt request read by poll in *NOT* passed to CPU as int From JT@zfja-gate.fuw.edu.pl Friday October 30, 1992 12:47:52 p.m. Date: Fri, 30 Oct 92 12:29:03 PST From: "Jerzy Tarasiuk" To: joseph anthony madia Subject: Re: Protected Mode 386/486 Questions... In-Reply-To: your msg of Fri, 30 Oct 92 4:08:32 EST <9210300908.AA12219@gecko.cis.ohio-state.edu> ============================================================================== > Thanks for the help. I really appreciate it. I now have a pretty good > idea of what I need to do. If you have ANY source code (or if you know of where > any good examples are) I would really appreciate it if you would send me a > copy. There are two other things that I need to work out right now: > First, moving the IRQs to different INT locations so that the hardware > IRQs do not interfere with the exception INTs. It seems that INTs 0 - 31 are > used for exceptions, so the IRQs must be moved to somewhere else (like INT > 40 - 48). To accomplish this, the 8259 must be programmed to move IRQs. Do > you know exact commands to do this? I have examples for a 286, but I am using > a 386 and I dont know if the 8259 talks to both chips in the same way. BIOS can change these vectors for you, need use Int 15h function 89h (it is used in some of my programs). Args: BH=1st 8259 vector, BL=2nd 8259 vector (both must be multiply of 8), ES:SI should point to GDT containing: +0 - all zeros, +8 - GDT as R/W data segment, +10h - IDT, +18h - DS, +20h - ES, +28h - SS (must be DPL=0), +30h - CS, +38h - reserved for BIOS. I used +40h as data at 000400h. But frequent changing these vectors can result in loosing interrupts. Can distinguish 8259 interrupt from exception: ask 8259 what interrupts it services (write 0Bh to port 20h, nop, nop, read - will get ones for interrupt being serviced; hope Int 0F is not used by 486 because 8259 can use vector +7 and say "no interrupt" after interrupting CPU). > Second, do I need to set the A20 for 386 systems? Or is it only needed > on 286 systems? I suppose every system needs it. For compatibility with XT. > Oh, one more thing. The ABIOS is the protected mode version of BIOS. > It was designed to support multi-tasking. (OS/2 uses ABIOS, and even lets > users call ABIOS routines directly.) I was looking for info about using ABIOS. > I have a reference book for it, but it makes the Intel data books look like > Shakespeare. If you have any idea of where I could find a knowledgeable soul > regarding ABIOS, please let me know. Thanks again for all your help. It has > really cleared some stuff up. Like I said, any of your PM source code would > be a huge help. Thanks... I don't know if it is much help. I wrote it some years ago, some of them when assemblers didn't support 286 opcodes. They are on zfja-gate.fuw.edu.pl in directory PM. Can use FTP or send mail to listserv (@zfja-gate) containing line: GET PM\*.* From JT@zfja-gate.fuw.edu.pl Tuesday February 23, 1993 11:07:43 p.m. Date: Tue, 23 Feb 93 21:11:37 PST From: "Jerzy Tarasiuk" To: David_Shalita.ES_AE@xerox.com Subject: Re: Need Help with your procedure ============================================================================== > Date: Tue, 23 Feb 1993 11:19:00 PST > Message-ID: <"23-Feb-93 11:19:00 PST".*.D.R._Shalita.ES_AE@Xerox.com> > > Hi JT: Hello, Dave, sorry for delay (I tried to do some test before answering and accidentally typed "o 20 A0" instead "o 21 A0" and needed to press RESET button - the mail I started to write was lost and I realized I need more think before writing answer) Seems there is a mistake in my method - I didn't checked NS UART data sheet and it says one important thing: when loopback mode is set for NS16450 or INS8250A or NS16550, the modem control output pins are in inactive state (high); in my computer I have INS8250B which outputs modem control signals in loopback mode. Since, to check if data receive interrupts works, need: - set loopback mode: out 3FC,13h (loopback, DTR, RTS) - send any data: out 3F8,any - wait until data received: in al,3FDh; test al,1; until NZ (in test program should use some timeout to avoid hangup) - make sure UART don't request interrupt: out 3F9,0; in al,3FA; test al,1; NZ means no interrupt - enable interrupt from UART: out 3FC,0Bh (OUT2, DTR, RTS) - wait microsecond or two (may be important on 50MHz CPU :-) - enable UART's data_received interrupt: out 3F9,1 (can verify UART requests interrupt: in al,3FA should read 4) - now, if IRQ is not masked and interrupts are enabled, an interrupt should occur; otherwise can read interrupt request in 8259's IRR or poll 8259 for the interrupt. If a software is to detect which interrupt is used by COM port, should do the out 3F9,1 with interrupts disables and after few us read the IRR and verify a bit was set after the out 3F9,1 and is cleared again by out 3F9,0. If more than one bit matches the criteria (the UART is not the only interrupt source), can repeat the test (out 3F9,1 and read IRR again ...). Other possible reasons of trouble: Your code uses "out dx,ax"; avoid it unless having 16-bit I/O port. In first msg you wrote: Also, Interrupt Enable Reg, reading 3F9 returns 00 after I go thru this sequence, was written to be 01. Have you checked where INT 0Ch vector points to ? On every computer I tried, it points (via some code in DOS which changes stack; it is some nonsense since IRQ4 should not occur unless a program enables it and in this case the program sets interrupt vector and the DOS code isn't used...) to BIOS unassigned interrupt service which: checks which is highest-priority interrupt-under-service, acknowledges the interrupt (otherwise all lower priority interrupts would be disabled unless using Special Mask Mode) and masks it, and stores to 40:6B value which was added to interrupt mask (unless it is cascaded interrupt, in this case it can be more complicated and I'm afraid some BIOS-es may have bug in the code; however, this was working). To be more software-independent, can use another method: write 0Ah to port 20h, and after at least 0.4us read port 20h, if interrupt is requested the corresponding bit will be set to 1. But this method may be source of trouble if a computer has other interrupt controller which is almost compatible with 8259 with exception it saves interrupt request even if it vanished. In this case can try to use interrupt poll: write 0Ch to port 20h and after short delay read port 20h, if bit 7 is set other bits contain IRQ number (0..7). Problem: what to do on IRQ2 ? Or: after finding which interrupt is requested, set vector for the interrupt (it can point to IRET; again trouble for IRQ2 which is cascaded) and unmask it, the 8259 should clear the bit from IRR and set it in ISR (to read ISR need write 0Bh to port 20h), then the bit from ISR can be cleared by out 20h,60h+IRQ_number (in some cases Auto-EOI may be programmed, suppose ISR will not be set in this case). Of course, all 8259 accesses require interrupts to be disabled, otherwise another program activated by interrupt can send command to the 8259. Yet another note: can read/write ports <=0FFh by "in al,port" or "out port,al"; no need for "mov dx,21h" and "out dx,al". 73's, JT