X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Date: Fri, 11 Jul 2014 14:48:41 +0200 From: Mateusz Viste User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: Using outportb() with djgpp References: <53bfa273$0$1981$426a74cc AT news DOT free DOT fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Lines: 72 Message-ID: <53bfdd29$0$3638$426a74cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 11 Jul 2014 14:48:42 CEST NNTP-Posting-Host: 82.225.72.113 X-Trace: 1405082922 news-1.free.fr 3638 82.225.72.113:64127 X-Complaints-To: abuse AT proxad DOT net Bytes: 4325 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com I have to admit I had no occasion yet to play with interrupts in DOS (other that from a user point of view). What you write sounds very convincing. And I have read in some MPU401 documentation that it is likely to emit INT 9 at some occasions. For a test, I tried to handle the INT 9 with a "do nothing" function in Turbo C, and now when my program ends, I have no keyboard anymore (ie. I can press keys, but no reaction happens at all). :) Haven't tried to catch the interrupt in protected mode yet, as it looks somewhat complex (according to the DJGPP docs) - way more convoluted than doing it in real mode at least. In any case, thanks for the hint! I will try to play with interrupts this weekend and see what happens. cheers, Mateusz On 07/11/2014 01:50 PM, Johann Klammer wrote: > 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. >