VOGONS


Reply 20 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
firage wrote:

The results for AWE64 are representative of both CT4380 and CT4520 types? And the non-PnP SB16 represents everything from CT1740 to CT2740, or?

I didn't take down all the model numbers, yet. At this stage I was more concerned about getting the test to work and working out the bugs. The tests are still developing in some areas.

When I re-do the tests with the updated software, I will make sure to take pictures of the cards along with the graphs.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 22 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Harekiet wrote:

oh that's a pretty nice way to measure things. sloooow samplerate to make it more obvious and maybe also time when an irq occurs.

Just added IRQ logging, yes!

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 23 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Harekiet wrote:

Slightly offtopic but seeing as you're doing sountblaster tests
I've wondered about the amount of processing time and buffering the soundblaster DSP has.
How soon after a sample is read through DMA does it appear on the output. Is there some small fifo in there to allow for a bit more output to cover the time to restart the dsp after an irq.

To answer this question, my test program shows that the FIFO is somewhere between 16 and 20 bytes large. But only if you use the SB16 DSP commands that enable the FIFO. If you use the FIFO-disabled versions, or any pre-SB16 commands, then it only buffers 1 sample.

Creative Sound Blaster 16 AWE 64 PnP - SB 16 DMA single cycle DSP test, 4000Hz, 4000 bytes, FIFO on.start.png
Filename
Creative Sound Blaster 16 AWE 64 PnP - SB 16 DMA single cycle DSP test, 4000Hz, 4000 bytes, FIFO on.start.png
File size
23.32 KiB
Views
475 views
File license
Fair use/fair dealing exception

EDIT: The 2-byte jumps seen in the snapshot are probably an artifact of not recording the DMA counter fast enough.
EDIT: Just ran the program on the old Compaq (ESS688 chipset). Sure enough, the graph shows a 64-byte FIFO load for SB compatible commands and a 256-byte FIFO load for ESS688 extended mode commands.
EDIT: Looking at the 4KHz FIFO on SB16 test, the AWE64 card seems to have a 20-byte FIFO, which it fills to 19 bytes at the start.

Last edited by TheGreatCodeholio on 2017-10-26, 12:59. Edited 2 times in total.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 24 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
firage wrote:

The results for AWE64 are representative of both CT4380 and CT4520 types? And the non-PnP SB16 represents everything from CT1740 to CT2740, or..?

The AWE64 is a CT4500 and the ViBRAC is a CT4180.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 25 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Harekiet wrote:

oh that's a pretty nice way to measure things. sloooow samplerate to make it more obvious and maybe also time when an irq occurs.

Actually, I had IRQ logging enabled, but having interrupts enabled means jitter and dropouts in the recording of the DMA counter, so I had to remove it. The test now runs with interrupts disabled for accuracy. Look at the ESS688 graphs in the git repo to see what I mean about interrupts causing dropouts, it's visible in the graph.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 26 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I added testing to time DMA counter vs time with 16-bit PCM.

Preliminary testing shows so far:

FIFO fill for 8-bit PCM shows a burst of 20 bytes for 8-bit PCM, and 40 bytes for 16-bit PCM. I wonder if what the DSP is doing is upconverting everything to 16-bit internally anyway, and the FIFO is really just 20 16-bit samples rather than just 20 bytes.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 27 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Okay, here's is the first card I am testing with the newest code.

This is a CT4500, which is a "AWE64 PnP Value" according to Creative's web site.

CT4500 bracket side ISA.cropped.jpg
Filename
CT4500 bracket side ISA.cropped.jpg
File size
62.93 KiB
Views
429 views
File comment
Bracket side
File license
Fair use/fair dealing exception
CT4500 bottom side ISA.cropped.jpg
Filename
CT4500 bottom side ISA.cropped.jpg
File size
756.86 KiB
Views
429 views
File comment
Bottom side
File license
Fair use/fair dealing exception
CT4500 top side ISA.cropped.jpg
Filename
CT4500 top side ISA.cropped.jpg
File size
1.29 MiB
Views
429 views
File comment
Top side
File license
Fair use/fair dealing exception

Testing is in progress now.

EDIT: The latest DOSLIB commit contains the full test results.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 28 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Found out something about the ADPCM commands on the AWE64.

The maximum sample rate possible is quite a bit higher than the official sample rates published in Creative's official documentation.

You can go up to 25KHz with 2-bit ADPCM playback.

However if you exceed the maximum possible on AWE64 the decoded output sounds jittery, as if the DSP can't keep up decoding.

The 20-byte (8-bit) / 40-byte (16-bit) FIFO load is consistent although it's only in samples, not sample pairs. Stereo 8-bit playback doesn't load 40 bytes and 16-bit stereo playback doesn't load 80 bytes.

There is one graph in the commit that suggests this 40-byte FIFO only loads about as 2x as fast as playback when playing something as high bandwidth as 16-bit stereo PCM at 45454Hz.

This was done with the 16-bit DMA on a 16-bit wide DMA channel. I'll do another test in the future to see if DMA timing changes if I use the same 8-bit DMA channel for both 8 and 16 bit PCM.

EDIT: Yes, apparently 16-bit stereo PCM at 45454Hz is fast enough that when you assign both DMA channels to an 8-bit DMA channel on the ISA bus, the data rate it reads over ISA is hardly faster (about 1.1x) than the data rate needed to play 16-bit PCM at 45454Hz.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 29 of 30, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I have photos of the ViBRA 16C card (CT4180) and test results complete if anyone here wants to see them.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 30 of 30, by georgel

User metadata
Rank Member
Rank
Member

Very interesting topic. Unfortunately the DSP 4.13 firmware hasn't been reversed and is used as-is within MAME for example. Too pity no other 4.xx firmware dumps are available. These tests also could indirectly reveal which SB clones used clean room reversing and which used directly the DSP firmware.