X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Johann Klammer Newsgroups: comp.os.msdos.djgpp Subject: Re: Using outportb() with djgpp Date: Fri, 11 Jul 2014 13:50:08 +0200 Organization: Aioe.org NNTP Server Lines: 49 Message-ID: References: <53bfa273$0$1981$426a74cc AT news DOT free DOT fr> NNTP-Posting-Host: ww99etTn6EZqOow44R7wJw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse AT aioe DOT org User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131103 Icedove/17.0.10 X-Notice: Filtered by postfilter v. 0.8.2 Bytes: 3232 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On 07/11/2014 10:38 AM, Mateusz Viste wrote: > Hi, > > Thank you all for your kind replies. > > The "weird interrupt happening during I/O" sounded sexy enough that I > had to test it out immediately - I replaced all my inportb() and > outportb() calls with a function that first call disable(), then do the > in/out operation, and then call enable() if interrupts were enabled > before. Unfortunately this doesn't changed my problem - my PC still > reboots wildly on random i/o operations on the 0x330 port. > > Some context: I am trying to play a few notes on my Sound Blaster 64 > (ISA) card using its embedded MPU401 synth controller. It works pretty > well when compiled in realmode with Turbo C 2.0.1, but then I am having > a bit of hard time with memory management (64K limit et all), so I > thought I'd recompile it under DJGPP. And then I experienced those wild > reboots I was writing before. Interestingly enough, the protected mode > version works fine on DOSBox. > > Of course I am aware that such 'bug report' is good for nothing - I was > just wondering whether there is some top secret information about doing > I/O calls from protected mode that I ignored, but I understand now that > there is nothing specific to do in protected mode (or at least nothing > much else than in real mode), so I will try to put together some > minimalistic test program to reproduce the problem on the smallest > possible example, and then I'll see where it leads me (might get back to > you then). > > Again, thanks for all your prompt replies! > > cheers, > Mateusz > > If the interrupt flag gets set, it stays set until after the interrupts get re-enabled, at which point the interrupt will run and crash your system, unless there's a handler there and not just garbage, or a default, probably installed by the dos extender/C run-time, which probably restarts your system. So, just disable/enable will not solve your problem. With dos extenders the interrupt is typically forwarded to a PM handler (if installed), You should try that (install a handler) and write a byte to the text segment, to see if anything is happening.. There's probably a dos_setvect() or something... There is probably a control bit somewhere on your MPU port range to disable interrupt generation from that specific source. You can try that, too.