Fantastic photos, we need to make clones of those CoProcessor daughter boards. I've located the Parallel output lines that control the DSP at offset 0x22000 so I know how it communicates.
What would be awesome is to get the ID's off the chip revision, so plug it in and give us the VEN_12EB&DEV_0002&SUBSYS_008812EB&REV_F6 information 😀
I'm only guessing they changed it to F6 from the SQ2500's FA revision.

I guess, a project for a replica won't be an easy one - first, the PCB seems to be at least 4 layer, so it will be rather difficult to recreate it without damaging the original; second, it uses a Lattice programmable logic IC, I'm not a specialist on those, but AFAIK they are extremely expensive and difficult to replicate.
However, if the whole project is feasible and if we find a person with needed skills, equipment and good will to contribute, I will be able to ship the daughterboard on the basic assumption that I will later receive it in the original undamaged condition.

Regarding the SQ2500 rev.C card, I'll do my best to finally plug it in one day (maybe in a month or so - a baby girl occupies all free space and time, so it's hard to assemble a testing machine and do the readings 😀 ).

There is certainly no rush on it, we at least have the base stratdsp microcode the 2050 drivers included which load into the Motorola DSP56362 to use for it.
Everything that Daughterboard was originally designed to do has now been done in software, Dolby encoding/decoding, EAX reverb, more 3D sound sources ect but I'd personally rather have a cloned board running on my SQ2500 than software for that stuff.

Sure 😀
So, if some capable person appears, we'll try to get that going.
Just be aware that I won't sell that daughterboard, so you can be calm that it's within the community till the end of time, and at any moment I'll be willing to help.

Considering how rare those boards are, I would lock mine up after it was cloned for safe keeping. They are in every way the 3DFX Specter's (Rampage) of sound cards. I think less than 10 of those boards were made.

Good to hear this is still being worked on. Do you plan to have this new driver support EAX2 as well or is it outside the scope of your project?

Yes because the scope of this project is to resurrect Aureal in every which way, starting with basic drivers for DOS and each modern Windows versions. I'll backport the working drivers to XP and perhaps 98, but 98 isn't the main focus OS since it has functional/working drivers already.

The next step after getting the drivers up and running is the API rewrite. I dove through the A3DAPI.dll looking for helpful tidbits of info but it's a very large file to fully reverse engineer without writing custom tools for the job. So a rewrite is preferable, and during this rewrite I'll be looking to implement API hooks to pipe EAX1-5, XAudio2, Miles, FMod, OpenAL and whichever other APi's could use a redirect through hardware acceleration buffers. This way the sound positions can get HRTF applied and the buffers can be passed through the Vortex2 for real hardware accelerated audio again.
Most likely the final A3D-X API will be in the joint form of a new A3DAPI.dll and a custom DSound.dll (like alchemy did) so that older games will benefit from the new code base.

The Vortex2 looks as though it can Apply 4 midi FX per 64 Sound Channels which is all EAX2 was, so it should be 100% supportable in hardware. EAX3-5 I am not entirely sure of, but I believe they were a set of DSP code which will not run in hardware on the AU8830 Vortex2 chip, as it is not a DSP but an ASIC with fixed but programmable/routable functions and would require the SQ3500 Turbo DSP board like the one Hard1K got, which is the programmable DSP part of the Vortex2. Or just reprogram it all in software like Alchemy did, or just route out through Alchemy since it's already available...

That's the idea for now since the new API details haven't been fully worked out yet.

Aren't EAX, miles and perhaps even FMOD (before they dropped hardware buffers a year and half ago) all still relying on DirectSound after all?
Also, I'm not sure XAudio2 has anything aside of software. Funnily, "official" Windows audio offloading is just for power saving.
Are you referring to sAPOs perhaps?

EDIT: also, why A3D.dll is so different between X-Fi Fatal1ty and X-Fi Titanium Fatal1ty ?

mirh wrote:

Aren't EAX, miles and perhaps even FMOD (before they dropped hardware buffers a year and half ago) all still relying on DirectSound after all?

If the API is premixing the audio channels then there is little we can do aside from what Creative and Dolby Headphone does, which is apply post-mixed audio filters in the WASAPI pipeline. This means you can only work on up to 8 channels of audio. If the audio API's still have their legacy DS3D fallback for XP systems, then you can route each games sound sources through A3D and have HRTF applied. If they have removed all these functions then one solution is to rewrite their audio API as a function shell and have the games load our custom API instead. There is always a solution to the problem, but the easiest is to make use of their legacy pipelines.

mirh wrote:

Also, I'm not sure XAudio2 has anything aside of software. Funnily, "official" Windows audio offloading is just for power saving.
Are you referring to sAPOs perhaps?

XAudio2 does have a full 3D audio subsystem to use, which is what we should have our API hook or pretend to be and do all the 3D in our hardware buffers instead. Those sAPO's are too far down into the WASAPI pipe to be of any real use, we need to hook the buffers being used for each individual audio source in the games API before they are even sent out through WASAPI and down-mixed into <= 8 channels.

mirh wrote:

EDIT: also, why A3D.dll is so different between X-Fi Fatal1ty and X-Fi Titanium Fatal1ty ?

I'm not sure what they like to stuff in those dll's. The ones I looked at either had custom wrapper code or were just a plain set of A3D buffer inits for routing to their audio hardware.
The source to a tutorial version of A3D.dll is included in the SDK v1.2, I'm sure Creative has some differences they need to account for when having A3D setup the buffers, thus the difference between the two I suppose.

[edit]
To those checking in, I've gone back to doing silent updates in the first post for now.
I'll bump the topic for notable news only.

[double post]

Nice one 😀
Is it possible to use those pins to extract a SPDIF signal and send it to a external DAC? The amp on my Dell Montego II seems to be dying as I need to pump the volume on my speakers to be able to hear correctly (or is it just weak?).
And an external DAC would also help with a far lower noise floor 😀

Beside fixing up the card itself? (I should note that these cards are NOT weak on the output, they can bust your eardrums if you set the codecs extra power level register high)
It appears to be standard S/PDIF output, nothing overly special in the drivers for it.

[edit]
If you read what I put here before, scratch that, my outputs were set wrong, what I thought was piping data through my onboard S/PDIF was really just passing the raw data out through the card >_< need to do more testing to get it working then.

[edit2]
Okay I got it working correctly this time. Use the pinout reference for the I2S/SPDIF jack I posted above and connect the 1.63v sclk to the DACs S/PDIF input.
My problem is I was using the wrong drivers for testing, I used the Montego 2 HomeStudio drivers and those expect more from the daughtercard to sync.
Use the Montego2 Quadzilla drivers instead and then unmute the S/PDIF playback output on the card and it works fine.
Tested with my Win98/ME box's GIGABYTE K8NSC-939 board S/PDIF input

ZanQuance wrote:

Beside fixing up the card itself? (I should note that these cards are NOT weak on the output, they can bust your eardrums if you […]
Show full quote

Beside fixing up the card itself? (I should note that these cards are NOT weak on the output, they can bust your eardrums if you set the codecs extra power level register high)
It appears to be standard S/PDIF output, nothing overly special in the drivers for it.

[edit]
If you read what I put here before, scratch that, my outputs were set wrong, what I thought was piping data through my onboard S/PDIF was really just passing the raw data out through the card >_< need to do more testing to get it working then.

[edit2]
Okay I got it working correctly this time. Use the pinout reference for the I2S/SPDIF jack I posted above and connect the 1.63v sclk to the DACs S/PDIF input.
My problem is I was using the wrong drivers for testing, I used the Montego 2 HomeStudio drivers and those expect more from the daughtercard to sync.
Use the Montego2 Quadzilla drivers instead and then unmute the S/PDIF playback output on the card and it works fine.
Tested with my Win98/ME box's GIGABYTE K8NSC-939 board S/PDIF input

Wow, thanks, this will be very useful 😁

[update]
OPL3 is 100% emulated via the au30dos.com driver. There is nothing performed in hardware on the Vortex 2 chip besides write captures.

Wow, great finding!

Neat, you found the block diagram! Dunno how useful that is going to be, but any documentation find is a good find when there's little public! 😀

I've contacted some people that used to work for Aureal and they might have some of the original technical documents for the AU8820 chip, but not the AU8830.

Fingers crossed...

That's cool!!! If they send you the book, is it possible to scan it all through page by page to upload here?

Neat! That gives much FM emulation info.

It appears it can report itself being OPL2 or OPL3, and when emulating OPL3, there's the NEW bit that describes if a game has set the chip into OPL3 mode. I don't know what the FM address bit is for, maybe for trapping accesses either to FM bank 0 (OPL2) or FM bank 1 (OPL3 extensions, or maybe this could be used for second OPL2 emulation in dual OPL2 emulation as well).

I have a small army of documentation scanner/digitzation people at my disposal ZanQuance, if you can obtain the book and send it my way. 😉