Mail Archives: djgpp/2014/07/11/15:31:30
Mateusz,
I love old programming documentation as well. In the case of the Sound
Blaster Development Kit, I actually own the original hard copy. :)
Matt D.
On 7/11/2014 2:52 PM, Mateusz Viste wrote:
> 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 -