DOS ain't dead

Hi,
as I wrote before, the problem why SBEMU don't work on new mobos is due to (hardware or software) routing SERR# to NMI is broken. Today I had some time to check hardware routing on my mobo and read ICH7 datasheet for proper config registers.
1) I looked on mobo and checked if PCI pin SERR# is routed on PCB. Yes it was but due to BGA package of ICH7 I couldn't trace it if really connected.
2) I checked if my BIOS have some NMI ISR. Yes it have. I called INT02h (mapped to NMI) and "PCI Parity Error !" message appeared. Then I can choose continue or reboot by pressing a Fx keys.
3) I soldered a wire on SB Live PCI edge connector to SERR# pin to be able to trigger SERR# manually. Of course when I grounded the wire NMI was not triggered because of it was disabled in chipset. Fortunatelly this can be changed be software way.
4) I studied ICH7 datasheet and found the SERR#/NMI releated PCI registers. They are located in PCI2PCI bridge (8086:244E), bus 0, device 30, func 0.
5) I set PCICMD.SEE16 (D30:F0:Offset 04h:bit 8) = 1 (SERR# enable) and
BCTRL.SEE16 (D30:F0:Offset 3Eh:bit 1) = 1 (SERR# forwarding)
Then I checked if bit PSTS.SSE16 (D30:F0:Offset 06h:bit 14)
is set when I ground SERR# wire, yeah it did!
This flag is cleared by writting one to this bit
6) I set NMI_SC?NMI8 (I/O space 61h:bit 2) = 0 (NMI SERR# source enable)
and NMI_EN?NMI8 (IO space 70h:bit 7) = 0 (NMI enable). Now when I ground
the wire the "PCI Parity Error !" message apper so finally SERR# to NMI
route is working.
I wrote a simple utility to enable it and put in autoexec before loading the SBEMU driver. Now when I run SBEGO.EXE it passed all IO, IRQ and DMA tests. SBEMU parameters was properly synchronized with PCI resources by windows98 drivers. So go on and run Doom. I can now hear MIDI music but still don't hear SFX . I tried some other games, e.g. Blood reports high DMA error - I use common SB values SET BLASTER=A220 I5 D1 H5 P330 T6, both DMAs are not conflicting with other HW (in windows CPL i can see DMA2 is used by FDC and DMA4 by 2nd DMA others are free). Oher games hang during sound init.

So the conclusion is that properly working SERR# to NMI rounting is only a partial condition for working SBEMU. I have no any idea what the Hell is in DMA :(

BTW Japheth, what about SB Live/AC97 JLM?

---
DOS gives me freedom to unlimited HW access.

> So the conclusion is that properly working SERR# to NMI rounting is only a
> partial condition for working SBEMU. I have no any idea what the Hell is in
> DMA :(

I didn't really understand what you did, but since SB digital sound has no relations to NMI, I wonder what you'd expected.

The problem with the DOS SBEMU driver is that it has to "cooperate" with all sorts of "OS" in protected-mode. Trapping DMA port access is no possible strategy, since it is not guaranteed that an IO permission bitmap exists at all. IIRC this software installs Debug breakpoints for in/out access to port 20h and then - inside the exception handler - tries to figure out what the program might want to do. I guess this approach requires a fully compatible legacy DMA controller to be installed.

> BTW Japheth, what about SB Live/AC97 JLM?

It's still on my todo list. But this won't change the DOS sound problem for protected-mode applications. A proper SB emulation for SB Live/AC 97 requires a HDPMI JLM as well - or, at the very least, that HDPMI installs an IO permission bitmap.

---
MS-DOS forever!

> I didn't really understand what you did, but since SB digital sound has no
> relations to NMI, I wonder what you'd expected.

But it (SBEMU) have a lot to do with NMI. Please read
this message from Creative support forum. And I proved that it is a minimum requrement. When I have normally disabled SERR#->NMI I cannot hear ANY sound from SFX/MIDI/Adlib. When I enable SERR#->NMI route it can play MIDI and Adlib. So you see that it does matter.

> The problem with the DOS SBEMU driver is that it has to "cooperate" with
> all sorts of "OS" in protected-mode. Trapping DMA port access is no
> possible strategy, since it is not guaranteed that an IO permission bitmap
> exists at all. IIRC this software installs Debug breakpoints for in/out
> access to port 20h and then - inside the exception handler - tries to
> figure out what the program might want to do. I guess this approach
> requires a fully compatible legacy DMA controller to be installed.

What means "fully compatible legacy DMA controller to be installed"?
You mean compatible hardware or some BIOS routines? I don't know how
can DMA on new chipsets differ to DMA in older chipsets. E.g. FDC uses DMA too
but I don't know if it is really used and working. And if the differences are permanent or it can be configured in chipset registers.

> It's still on my todo list. But this won't change the DOS sound problem
> for protected-mode applications.

I would expect that if MPXPlay, running in protected mode, can play on SB live in my system well then it wouldn't be problem. But I don't know what all is required to catch all communication to legacy SB from RM/PM apps.

---
DOS gives me freedom to unlimited HW access.

> But it (SBEMU) have a lot to do with NMI. Please read
> this
> message from Creative support forum. And I proved that it is a
> minimum requrement. When I have normally disabled SERR#->NMI I cannot hear
> ANY sound from SFX/MIDI/Adlib. When I enable SERR#->NMI route it can play
> MIDI and Adlib. So you see that it does matter.

There might be different models for which they implemented different approaches. The NMI approach has severe limitations, so they might have changed their strategy. Anyways, IIRC I once verified that the DOS drivers for my SB Live don't touch the NMI vector in the IDT, which is a pretty good evidence that NMI is not used.

> What means "fully compatible legacy DMA controller to be installed"?
> You mean compatible hardware or some BIOS routines?

I mean hardware, since the legacy DMA controller is known and documented.

> I don't know how can DMA on new chipsets differ to DMA in older chipsets.
> E.g. FDC uses DMA too but I don't know if it is really used and working.
> And if the differences are permanent or it can be configured in chipset
> registers.

But if the FDC and/or DMA is "non-standard" in your MB, wouldn't that mean that you'll need a driver to run - say - Win98 on it? I'm not sure, but I bet the FDC in Win98 is accessed by protected-mode drivers supplied with the OS, and not by BIOS interrupts.

---
MS-DOS forever!

> There might be different models for which they implemented different
> approaches. The NMI approach has severe limitations, so they might have
> changed their strategy. Anyways, IIRC I once verified that the DOS drivers
> for my SB Live don't touch the NMI vector in the IDT, which is a pretty
> good evidence that NMI is not used.

This experimets was done on the first version of SB Live 1024 with 4-channel output. I have 2 version of drivers. One that came on original CD made just for Live and latest drivers which are compatible with up to Audigy2. I don't know version numbers now (I can look later). Both drivers don't work without SERR#->NMI enabled. I also have Audigy2 in other PC. I tried it some months ago but behave same as Live.

> I mean hardware, since the legacy DMA controller is known and documented.

ICH7 DMA is also documented in intel datasheet. I hoped they would keep this peripherals compatible as possible. So I would need compare it. There's a lot of internal config registers. And one badly set (unset) bit may corrupt it all because of BIOS writers was lazy to mess with this things. Or maybe there's something missing in HW I don't know...

> But if the FDC and/or DMA is "non-standard" in your MB, wouldn't that mean
> that you'll need a driver to run - say - Win98 on it? I'm not sure, but I
> bet the FDC in Win98 is accessed by protected-mode drivers supplied with
> the OS, and not by BIOS interrupts.

Just note that under W98 it behaves same as under DOS (only MIDI, Adlib).
I don't need any drivers for floppy it works normal under all OSes. But I don't know if it use DMA in all cases or if there's something like PIO mode for HDDs which will then run without DMA but with higher CPU load. I only can say that when using FD under W98 system respose become slow but under WXP it doesn't.
Is there some program that can probe if DMA is working under DOS? I just tried SBEGO and PCDR diagnostic and it didn't reported problems but i don't know how did it test it.

Maybe this problem is releated to that ICH6 and later doesn't support some signals for PCI2ISA bridge needed for working ISA DMA. This signals are not needed here but maybe something else was ommited...

---
DOS gives me freedom to unlimited HW access.

> Is there some program that can probe if DMA is working under DOS?

Maybe DMACHK from UMBPCI package?

---
Forum admin

> Is there some program that can probe if DMA is working under DOS? I just
> tried SBEGO and PCDR diagnostic and it didn't reported problems but i
> don't know how did it test it.

You're telling that some test programs don't display errors, but to be sure: did those test programs successfully play digital sound which you were able to hear? If no, it might be a good idea to run the old SB16 diagnose programs. If this doesn't work, use one of the simple SB sample programs written in ASM. With such a thing the reason for the problem won't be able to hide itself anymore.

---
MS-DOS forever!

> > BTW Japheth, what about SB Live/AC97 JLM?
>
> It's still on my todo list. But this won't change the DOS sound problem
> for protected-mode applications. A proper SB emulation for SB Live/AC 97
> requires a HDPMI JLM as well - or, at the very least, that HDPMI installs
> an IO permission bitmap.

It might be easier to just make an AC97 .LIB/.A for use in new projects than trying to get old, closed src, complicated pmode apps running via some fancy-pants TSR, JLM, etc. (But hey, if you know how, be my guest!) But the Mpxplay guy (Atila Padar) doesn't have much (if any) regular 'net access.

> Maybe DMACHK from UMBPCI package?

Well, it may be good start point. I tried DMACHK with various memory managers and OSes DOS 6.22, 7.1. Results can be divided to 2 groups.

1) DOS safe mode or himem.sys / himemx.exe only, regardless DOS version always reported:

ISA-DMA-Checker for UMBPCI V1.13, (c)1999-2004 by Heiko Nocon, Uwe Sieber
http://www.uwe-sieber.de

 North-Bridge:  Vendor: 8086  Device: 29C0
 South-Bridge:  Vendor: 8086  Device: 27B8

C000-C3FF : write protected
C400-C7FF : write protected
C800-CBFF : write protected
CC00-CFFF : write protected
D000-D3FF : write protected
D400-D7FF : write protected
D800-DBFF : write protected
DC00-DFFF : write protected
E000-E3FF : write protected
E400-E7FF : write protected
E800-EBFF : write protected
EC00-EFFF : write protected

2) Use of himem.sys + emm386 or himem.sys + umbpci.sys or jemmex.exe resulted always in hang during the test.

ISA-DMA-Checker for UMBPCI V1.13, (c)1999-2004 by Heiko Nocon, Uwe Sieber
http://www.uwe-sieber.de

 North-Bridge:  Vendor: 8086  Device: 29C0
 South-Bridge:  Vendor: 8086  Device: 27B8

EMM386 is loaded

C000-C3FF : write protected
C400-C7FF : write protected
C800-CBFF : write protected
CC00-CFFF : write protected
D000-D3FF : read/write ok, ISA-DMA (hangs here)

In case EMM386 under DOS 7.1 it hanged at
E000-E3FF : read/write ok, ISA-DMA (hangs here)

in case there was only HIMEM.SYS + UMBPCI.SYS it wasn't displayed "EMM386 is loaded" message but hanged in same case. Unfortunatelly DMACHK doesn't report what happened. No CTRL+C/CTRL+ALT+DEL just hardware reset helps.


Then I tried some DOS sound test programs but I didn't heard sfx in any case. Programs hanged or played nothing. I also tested dstest.exe which is a part of HXDOS tests. Result with /v /p options, terminated normally but no sound:

Sound size=12A00
Format: channels=1, samples=44100, bits=16, bytespersec=88200
DirectSoundCreate()=0
IDirectSound:SetCooperativeLevel()=0
IDirectSound:CreateSoundBuffer()=0
IDirectSoundBuffer:SetFormat()=0
IDirectSoundBuffer:Lock(0, 5622, ...)=80070057
IDirectSoundBuffer:Release()=0
IDirectSound:Release()=0

With /v option it hanged but can be breaked by CRTL+BREAK

Sound size=12A00
Format: channels=1, samples=44100, bits=16, bytespersec=88200
DirectSoundCreate()=0
IDirectSound:SetCooperativeLevel()=0
IDirectSound:CreateSoundBuffer()=0
IDirectSoundBuffer:Play()=0
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]
..IDirectSoundBuffer:GetCurrentPosition()=0 [    0   562]

It seems that sound buffer position is not updating, no samples are clocked out and so it locks in endless loop, nevet request to load another part of buffer...

---
DOS gives me freedom to unlimited HW access.

Here's my tool for enabling SERR#->NMI routing.
It's only for intel ICHx chipsets. It also reports current status of some important registers. Maybe it will be usefull for somebody else.
http://rayer.ic.cz/programm/serren.exe

---
DOS gives me freedom to unlimited HW access.

> Here's my tool for enabling SERR#->NMI routing.
> It's only for intel ICHx chipsets. It also reports current status of some
> important registers. Maybe it will be usefull for somebody else.
> http://rayer.ic.cz/programm/serren.exe

No source code?

---
Forum admin

> > Maybe DMACHK from UMBPCI package?
>
> Well, it may be good start point. I tried DMACHK with various memory
> managers and OSes DOS 6.22, 7.1. Results can be divided to 2 groups.

From file dmachk.txt: "Start it in pure DOS." To me pure DOS means no memory managers loaded at all.

---
Forum admin

> > Maybe DMACHK from UMBPCI package?
>
> Well, it may be good start point. I tried DMACHK with various memory
> managers and OSes DOS 6.22, 7.1. Results can be divided to 2 groups.

IMO DMACHK is useless for this issue. The problem that upper memory cannot be accessed by DMA on some MBs is pretty unrelated to the SB PCI DMA problem. At best this tool tries to do some memory-to-memory DMA transfers using the legacy DMA controller, which has no relevance for the PCI problem.

> Then I tried some DOS sound test programs but I didn't heard sfx in any
> case. Programs hanged or played nothing. I also tested dstest.exe which is
> a part of HXDOS tests. Result with /v /p options, terminated normally but
> no sound:

Ok, this proves that your DOS SB emulator software has a problem. But this was pretty obvious already. You still don't even know for sure whether it is a hardware or software problem.

---
MS-DOS forever!

> From file dmachk.txt: "Start it in pure DOS." To me pure DOS means
> no memory managers loaded at all.

OK but SBEMU needs some EMS manager to run so DMA must work also with EMMx too. BTW what is reported on other systems? Also all ranges write protected?

---
DOS gives me freedom to unlimited HW access.

> IMO DMACHK is useless for this issue. The problem that upper memory cannot
> be accessed by DMA on some MBs is pretty unrelated to the SB PCI DMA
> problem. At best this tool tries to do some memory-to-memory DMA transfers
> using the legacy DMA controller, which has no relevance for the PCI
> problem.

And what DMA transfer use SBEMU? Is there any other sw that can test this kind of DMA transfer?

---
DOS gives me freedom to unlimited HW access.

> No source code?

What you need it for? I already described all registers that are modified in 1st post. I can give you main src without pci code, its just few lines :)

---
DOS gives me freedom to unlimited HW access.

> > No source code?
>
> What you need it for?

Maybe for future expansion. If it's only a few lines, why hide it?

---
Forum admin

> BTW what is reported on other systems? Also all ranges write protected?

No. Depends on motherboard chipset.

---
Forum admin

> And what DMA transfer use SBEMU? Is there any other sw that can test this
> kind of DMA transfer?

I don't know. The SB PCI sound cards can act as PCI busmasters and will use this method in their "native" mode. The DOS drivers will "somehow" have to translate the old legacy DMA transfers to the PCI transfers. To be more specific is almost impossible without having the source code available. The SBEMU drivers run in privileged mode, it's impossible to install a monitor to trap their I/O activity.

---
MS-DOS forever!

RayeR wrote:

> the problem why SBEMU don't work on new mobos is due to



> I would expect that if MPXPlay, running in protected mode, can
> play on SB live in my system well then it wouldn't be problem.

IIRC MPXPLAY suports SB Live ( Laaca ? ) so you don't need the "SBEMU" crap

> But I don't know what all is required to catch all
> communication to legacy SB from RM/PM apps.

Will this "catch" never end ?

Japheth wrote:

> The problem with the DOS SBEMU driver is that it has to "cooperate"
> with all sorts of "OS" in protected-mode. Trapping DMA port access
> is no possible strategy, since it is not guaranteed that an IO
> permission bitmap exists at all. IIRC this software installs Debug
> breakpoints for in/out access to port 20h and then - inside the
> exception handler - tries to figure out what the program might want to do.
> I guess this approach requires a fully compatible legacy DMA
> controller to be installed.

> The SB PCI sound cards can act as PCI busmasters and will use this
> method in their "native" mode. The DOS drivers will "somehow" have
> to translate the old legacy DMA transfers to the PCI transfers.
> To be more specific is almost impossible without having the source
> code available. The SBEMU drivers run in privileged mode, it's
> impossible to install a monitor to trap their I/O activity.

Thanks for the info ... very crappy hacks

Rugxulo wrote:

> > > BTW Japheth, what about SB Live/AC97 JLM?
> > It's still on my todo list. But this won't change the DOS sound
> > problem for protected-mode applications.
> It might be easier to just make an AC97 .LIB/.A for use
> in new projects

Agree. Easier (no silly "catch"es, I/O deBUG's), and more useful

But a compiler independent driver, no DGJPP-only .A please

The solution for old stuff talking directly to an ISA SB already exists, it's BOCHS or QEMU + HX ... what lacks is SBPCI.DLL + ICH.DLL + AC97.DLL for HX sound API ... then the old crappy "SBEMU" stuff can be finally banned

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> The solution for old stuff talking directly to an ISA SB already exists,
> it's BOCHS or QEMU + HX ... what lacks is SBPCI.DLL + ICH.DLL + AC97.DLL
> for HX sound API ... then the old crappy "SBEMU" stuff can be finally
> banned

Ways better than HX+Bochs/Qemu is HX+DosBox. Their sound emulation actually WORKS!

---
MS-DOS forever!

> The solution for old stuff talking directly to an ISA SB already exists,
> it's BOCHS or QEMU + HX ...

I know many emulators but for some games and demos the emulation is still too slow on newest CPUs. And sometimes emulation don't work properly.

---
DOS gives me freedom to unlimited HW access.

> I know many emulators but for some games and demos the emulation is still
> too slow on newest CPUs.

IIRC DOS game development stopped at cca 100 MHz ... and having QEMU with 10x slowdown and 1 GHz CPU's nowadays considered "obsolete and slow" ... is there really space for a problem ?

Doesn't MPXPLAY work with your SB Live card natively ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> IIRC DOS game development stopped at cca 100 MHz ... and having QEMU with
> 10x slowdown and 1 GHz CPU's nowadays considered "obsolete and slow"
> ... is there really space for a problem ?

For playing Blood or quake at higher VESA modes e.g. 1280x1024 you need better machine. Also there are some DOS demos from end of dos era that needs fast CPU like Fulcrum, Heaven 7, etc...

> Doesn't MPXPLAY work with your SB Live card natively ?

Of course I know.

---
DOS gives me freedom to unlimited HW access.