frank@cavebbs.gen.nz (Frank van der Hulst) (01/17/91)
>just sits there refusing to fire on the character-ready signal the 8259 is >alleged to send. So, what I've got, basically, looks like this (RH column >Turbo C++): I think you're getting confused between the 8250 (UART) and 8259 (PIC), which are both involved in what you're trying to do.. > > init port bioscom(0, initval, 0); > vector the COM1 interrupt setvect(0xc, handler); > to the handler > wake up the 8259's 'int on outportb(0x3f9, 1) > data ready' /* or even ',0x1f' to be sure ;) */ > enable the 8259 ints outportb(0x21, inportb(0x21) | 0x08); I think this is your problem -- you need to clear a bit on the 8259 to enable interrupts, so you want outportb(0x21, inportb(0x21) & 0xf7); > > ... > > handle interrupts void interrupt handler(etc...) > receive char, process... inword = bioscom(2, 0, 0); > /* will probably fetch directly RSN, > only can't be bothered 'cos it > doesn't get this far... */ I don't think I'd trust BIOS to get the character -- your ISR should fetch the character from the 8250, and put it in a ring buffer. Secondly, your ISR needs to re-enable the 8259 via outportb(0x20, 0x20); > >BTBTW, has anyone ever had problems with TC++ & DR-DOS on ATs? I've noticed >that ^Breaks out of programs running within TC *seem* to get trapped by the DOS >(tho the TC screen reappears), which goes down the gurgler with something like >interrupt process? Y/N (I *think*), and kills everything except the Big Red >Switch (well, grey button). I've had this sort of thing happen with TC 2.0 -- I think its because our programs are killing interrupts or something like that. Particularly, it seems to have something to do with calls to malloc or calloc or farmalloc, as far as I can tell. -- Take a walk on the wild side, and I don't mean the Milford Track.