Mail Archives: djgpp/2014/07/11/15:16:09
Thank you, Matt. Definitely an interesting read ahead, although I'm not
sure it applies to my situation, since I am trying to /not/ use any
SB-specific stuff. After all, the MPU on the SB64 card is supposed to
act as a 100% standard MPU401 controller (once initialized with the
Creative Labs AWEUTIL tool), and therefore I believe that all the DSP
stuff is handled by this SoundBlaster driver. Besides, my program do
work fine in real mode, and the DSP interaction is (I think?) the same
(ie. there is none).
But anyway - I do like to read ancient documentation about prehistoric
hardware, and the one you handed me was unknown to me, and I might find
there some interesting bits. Thanks!
Mateusz
On 07/11/2014 08:18 PM, Matt D. wrote:
> Mateusz,
>
> Here is a link to the Sound Blaster Development Kit. Some of this
> information may be useful:
>
> http://files.mpoli.fi/unpacked/software/misc/players/tbmplay.zip/sbdevkit.doc
>
>
> See section 8-3 on "Resetting DSP".
>
>
> Matt D.
>
> On 7/11/2014 4: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
>>
>>
>>
>>
>> On 07/10/2014 10:20 PM, Mateusz Viste wrote:
>>> Hi,
>>>
>>> I am trying to write to a hardware port from within djgpp, using
>>> outportb(). It does work from time to time, but often outportb() will
>>> make the whole PC reboot. Specifically I am writing to port 0x330 (to a
>>> MPU401 adapter). If using the same code with turbo C, it works
>>> perfectly. Hence I am wondering: are there any special "rules" I should
>>> be aware of when trying to outportb() from within protected mode?
>>>
>>> regards,
>>> Mateusz
>>
>>
>>
- Raw text -