SB16 ASP not operational

[Jarvik7]

A search of the code implies it is, and it is detected in SB16's diagnose program, but fails to operate in the DOS driver's qsound align app or demo. Nothing reported in stderr.

[joncampbell123]

Hm... does there exist any documentation on the SB16 ASP chipset and I/O ports?

[Jarvik7]

Maybe useful: http://www.vogons.org/viewtopic.php?f=46&t=37435

[ghost]

This doesn't seem to appear in dma.cpp: https://git.redump.net/mame/commit/?id=138d42b4116bbdbbdb00c4520e6f62195b087d7e

[joncampbell123]

@box-tortoise that kind of makes sense. it's a question of how to handle the 16-bit value from the DMA controller when the memory cycle is 16-bit wide. Not sure if it's an issue though since I've never seen DOS or Windows have problems with 16-bit DMA and DOSBox-X so far.

It would probably be a fun test case for DOSLIB to offer a way to see what actual hardware does, and which hardware does what.

[ghost]

That sounds very reasonable. As you said, it would be interesting to test with doslib for determining how actual hardware responds; but dosbox-x has no known issue with the dma handling (such as the mame specific issue with SB16 diagnose.exe).

[joncampbell123]

Looking over DOSLIB, the current DMA code uses this for 16-bit DMA, which I've yet to have any problems with.

void d8237_write_base(unsigned char ch,uint32_t o) {
    if (d8237_16bit_ashift & (1<<ch)) {
        d8237_write_base_lo16(ch,o>>1UL);
        outp(d8237_page_ioport_map[ch],o >> 16);
    }
    else {
        d8237_write_base_lo16(ch,o);
        outp(d8237_page_ioport_map[ch],o >> 16);
    }
}

EDIT: I just noticed that DOSBox-X effectively does the same thing as the code you linked to, though differently:

void SetPage(Bit8u val) {
    pagenum=val;
    pagebase=(pagenum >> DMA16) << (16+DMA16);
}

(comments made invalid by reasoning)

I can think of three possibilities:

• 16-bit DMA takes bits 0-14 of the address registers, maps them as bits 1-15 to the ISA bus, and bit 15 is ignored (DOSLIB has worked perfectly fine with this model so far).
• 16-bit DMA takes bits 0-15 of the address registers, sums them to (page register << 16), and sends that to the ISA bus. (reasoning out how this works means NO this doesn't work out)
• 16-bit DMA takes bits 0-15 of the address registers, maps them as bits 1-16 to the ISA bus, and bit 0 of the page register is ignored (this is what the code patch you linked to assumes).

(other comments made invalid by reasoning)

EDIT: I just realized that the first case would work with DOSLIB, because when it comes down to it, DOSLIB writes the same value to bit 15 of address register and bit 0 of page register anyway, therefore ignoring bit 15 has no effect. The 3rd case would also work with DOSLIB because then you're ignoring bit 0 of the page register. In the 1st case and 3rd cases the bits come together to the correct address, regardless which bit you are ignoring. However that would also mean DOSLIB would fail in the 2nd case because bit 15 XOR bit 0 would always cancel out to zero and make the address invalid.

However since 16-bit DMA is documented to have a 128KB range, that would eliminate case 1 because ignoring bit 15 would limit the range back down to 64KB. Only case 3 would permit the full 128KB range.

However there is also this reference to Intel documentation that suggests the DMA controller would act as specified in the first case: http://forum.osdev.org/viewtopic.php?t=21762&p=174239

This is something I want to verify on real hardware. Your link is probably correct, in the way that PC hardware is typically counter-intuitive until you reason it out.

[ghost]

Thank you for your interesting findings - I could follow along.

[joncampbell123]

Test result:

Intel Pentium 133MHz with Intel PIIX3 chipset (obtained mid-1996) vs Creative Sound Blaster 16 ViBRA PnP

• 16-bit DMA takes bits 0-15 of the address registers, maps them as bits 1-16 to the ISA bus, and bit 0 of the page register is ignored

This stands as a counterexample the idea that PCI-based systems dumped the 128KB 16-bit DMA mode, because this motherboard has both PCI and ISA slots.

[joncampbell123]

Test result:

Intel Pentium Pro MMX 200MHz with Intel 430VX chipset (made sometime 1997) vs Creative Sound Blaster 16 AWE64 PnP and Sound Blaster Live! PCI emulation.

• 16-bit DMA takes bits 0-15 of the address registers, maps them as bits 1-16 to the ISA bus, and bit 0 of the page register is ignored

Hm, maybe the guy I referenced on osdev is referring to the Intel ICH chipsets made sometime after 2001 when they dropped chipset support for ISA DMA?

[joncampbell123]

Testing on a Pentium III Celeron with 440FX chipset in progress.

I just found out that running TEST.EXE against the Sound Blaster 16 non-PNP card detects the ASP/CSP chip but then the test seems to make PCM playback silent. Working on that now.

[joncampbell123]

Test result:

Intel Pentium III Celeron with Intel 440FX chipset vs Creative Sound Blaster 16 non-PnP with CSP/ASP chip

• 16-bit DMA takes bits 0-15 of the address registers, maps them as bits 1-16 to the ISA bus, and bit 0 of the page register is ignored

Hm, maybe the guy I referenced on osdev is referring to the Intel ICH chipsets made sometime after 2001 when they dropped chipset support for ISA DMA?

[joncampbell123]

Test result:

Intel Pentium II with Intel (unknown) chipset vs Creative Sound Blaster 16 non-PnP

• 16-bit DMA takes bits 0-15 of the address registers, maps them as bits 1-16 to the ISA bus, and bit 0 of the page register is ignored

Hm...

Well, the code I added to DOSBox-X emulates the 128KB case by default, so it's consistent with actual hardware, but if I do find a chipset where the 128KB 16-bit DMA case doesn't apply, it will be noted. I'm guessing the most likely candidate would be a non-Intel chipset, possibly strange 3rd party stuff.

[Torinde]

Vogons thread with info and documents from somebody trying to reverse engineer the SB16 ASP/CSP (Creative Signal Processor).

List of 20-30 DOS/Win3x/Win9x games using QSound