home bbs files messages ]

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

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

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

   Message 4,575 of 4,675   
   Terje Mathisen to Paul Edwards   
   Re: serial port   
   11 Apr 23 21:09:45   
   
   From: terje.mathisen@nospicedham.tmsw.no   
      
   I last looked at my RS232 drivers at least 30+ years ago, but from   
   memory what I had to do was to get the data from the serial port chip,   
   at this point I re-enable all other interrupts except the one I am   
   servicing.   
      
   After saving the received byte I optionally loop back until the input   
   buffer is empty (more modern PCs had a 16-byte buffer you could enable).   
      
   Before returning from the interrupt with IRET, I would reenable the   
   serial port IRQ channel (stil with interrupts disabled), then IRET back   
   to the interrupted process.   
      
   If you are interested I can see if I can locate my source code...   
      
   Terje   
      
   Paul Edwards wrote:   
   > Hi.   
   >   
   > As far as I can tell from testing, the BIOS INT 14H doesn't   
   > work on most real hardware I have tried (computers made   
   > maybe 10 years ago that still have a serial port).   
   >   
   > So I am gearing up to replace that with 80386 PM32 code.   
   >   
   > I have some comms routines for MSDOS (pdcomm) that I   
   > wrote decades ago, but I want to do it a different way this time.   
   >   
   > Less sophisticated, but more straightforward.   
   >   
   > And designed for a single-tasking system with only one   
   > CPU enabled (PDOS/386).   
   >   
   > Most of the code can be done in C, but the last bit I want   
   > to do in assembler.   
   >   
   > Prior to hitting the assembler, I will have installed the   
   > new interrupt address (which is assembler code, gotint,   
   > below).   
   >   
   > I'm just trying to confirm the sequence in the final assembler.   
   >   
   > outb port1, transmit_byte   
   > outb port2, tbemask ; enable transmit buffer empty (only)   
   > xxx:   
   > hlt ; this could get interrupted by timer interrupts and   
   > ; then processing continues so we need a jmp   
   > jmp xxx   
   > gotint: ; this is the interrupt address installed by C caller   
   > outb port2, oldmask ; restore previous interrupt mask (everything disabled)   
   > add esp, 12 ; we don't return to the previous instruction, which was hlt   
   > ; instead we skip over the return address, segment and flags   
   >   
   > ret ; return to C caller which will do the EOI or whatever   
   > ; via separate calls to individual simple assembler functions   
   > ; like outportb()   
   >   
   > Note that this was inspired by something similar I wrote   
   > for S/370.   
   >   
   > It's basically quite minimal assembler and straightforward.   
   >   
   > There is a loop in the assembler, which I didn't have in my   
   > old routines, but it's not really processing logic.   
   >   
   > After transmit is working I'll try a variation of the above for receive.   
   >   
   > I especially don't know if these two need to be swapped:   
   >   
   > outb port1, transmit_byte   
   > outb port2, tbemask ; enable transmit buffer empty (only)   
   >   
   > I don't want to miss an interrupt. I want the order to   
   > guarantee that I will get the interrupt. ie if I have already   
   > attempted to write the transmit byte, will the interrupt   
   > pend until I enable it, or will it be skipped?   
   >   
   > Or is the other way around? If I haven't enabled interrupts   
   > will it just transmit the byte and not bother interrupting?   
   >   
   > Assume that the transmit is very fast, or the CPU is very   
   > slow, so that there is a gap between the two outb   
   > instructions where a decision is made on whether to   
   > interrupt or not.   
   >   
   > Thanks. Paul.   
   >   
      
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- 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