home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,882 of 4,255   
   wolfgang kern to Robert Pengelly   
   Re: COM1 interrupt for 16-bit OS   
   11 Nov 23 10:49:50   
   
   From: nowhere@never.at   
      
   On 11/11/2023 09:21, Robert Pengelly wrote:   
   > On Saturday, 11 November 2023 at 08:15:49 UTC, wolfgang kern wrote:   
   >> On 11/11/2023 08:57, Robert Pengelly wrote:   
   >> ...   
   >>> so that part is sorted I just don't know what interrupt get fired.   
   >> have you enabled and covered it by a routine where its address need to   
   >> be stored into the Interrupt Table ?   
   >> __   
   >> wolfgang   
   >> oh, and I forgot to mention that old hardware need delays between I/O   
   >> writes (2..5 mSec)   
   >>   
   >> more info from RBIL about IRQ->INT and ENABLE:   
   >>   
   >> port A0 work equal for IRQ 8..15   
   >>   
   >> PORT 0020-003F - PIC 1 - PROGRAMMABLE INTERRUPT CONTROLLER (8259A)   
   >> SeeAlso: PORT 00A0h-00AFh"PIC 2",INT 08"IRQ0",INT 0F"IRQ7"   
   >>   
   >> 0020 -W PIC initialization command word ICW1 (see #P0010)   
   >> 0020 -W PIC output control word OCW2 (see #P0015)   
   >> 0020 -W PIC output control word OCW3 (see #P0016)   
   >> 0020 R- PIC interrupt request/in-service registers after OCW3   
   >> request register:   
   >> bit 7-0 = 0 no active request for the corresponding int. line   
   >> = 1 active request for corresponding interrupt line   
   >> in-service register:   
   >> bit 7-0 = 0 corresponding line not currently being serviced   
   >> = 1 corresponding int. line currently being serviced   
   >>   
   >> 0021 -W PIC ICW2,ICW3,ICW4 immed after ICW1 to 0020 (see   
   >> #P0011,#P0012,#P0013)   
   >> 0021 RW PIC master interrupt mask register OCW1 (see #P0014)   
   >>   
   >> Bitfields for PIC initialization command word ICW1:   
   >> Bit(s) Description (Table P0010)   
   >> 7-5 0 (only used in 8080/8085 mode)   
   >> 4 ICW1 is being issued   
   >> 3 (LTIM)   
   >> =0 edge triggered mode   
   >> =1 level triggered mode   
   >> 2 interrupt vector size   
   >> =0 successive interrupt vectors use 8 bytes (8080/8085)   
   >> =1 successive interrupt vectors use 4 bytes (80x86)   
   >> 1 (SNGL)   
   >> =0 cascade mode   
   >> =1 single mode, no ICW3 needed   
   >> 0 ICW4 needed   
   >> SeeAlso: #P0011,#P0012,#P0013   
   >>   
   >> Bitfields for PIC initialization command word ICW2:   
   >> Bit(s) Description (Table P0011)   
   >> 7-3 address lines A0-A3 of base vector address for PIC   
   >> 2-0 reserved   
   >> SeeAlso: #P0010,#P0012,#P0013   
   >>   
   >> Bitfields for PIC initialization command word ICW3:   
   >> Bit(s) Description (Table P0012)   
   >> 7-0 =0 slave controller not attached to corresponding interrupt pin   
   >> =1 slave controller attached to corresponding interrupt pin   
   >> SeeAlso: #P0010,#P0011,#P0013   
   >>   
   >> Bitfields for PIC initialization command word ICW4:   
   > What do you mean by:   
   >   
   > "have you enabled and covered it by a routine where its address need to   
   > be stored into the Interrupt Table ?"   
   >   
   > I thought interrupts were "intno * 4 (+ 2)" so for INT 0Ch it would be:   
   >   
   > mov [12 * 4], offset handler   
   > mov [12 * 4 + 2], segment   
   >   
   > but that doesn't work or am I missing something?   
      
   perhaps the way IRQs and INTs were treated/handled.   
   have you enabled IRQ4 in the PIC port 0x20 (see above)   
      
   IRQ4 may not be at INT12, but let's assume it is there.   
   perhaps you already posted it, what is the code at Seg:Offset   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca