newold86 wrote:

What are they ?

1) SB16 is extremely noisy
2) SB16 does not support the stereo 8-bit sample replay modes of the SB Pro 1/2
3) SB16 has clicking and popping in the 8-bit sample replay modes of the SB 1.x/2.0
4) Its MPU-401 implementation is only UART mode
5) Its MPU-401 implementation has hanging note bug

take old creative CT1350 card.

take hires photo front + back (so you can see resistor values etc).

desolder all components. take another hires photo.

convert photo to pcb gerber. done.

you could go one more step, convert gerber to schematic with altium.

charge exorbitant prices for your clone.

BloodyCactus wrote:

you could go one more step, convert gerber to schematic with altium.

Missing one "small" step - firmware...

newold86 wrote:

BloodyCactus wrote:

you could go one more step, convert gerber to schematic with altium.

Missing one "small" step - firmware...

SB all used an 8051 mcu, when you write DSP commands, they write directly to the 8051 dsp registers.

sb16 firmware exsts.. a quick look with an 8051 decompiler tells you anything you need to know...

BloodyCactus wrote:

take old creative CT1350 card.

BloodyCactus wrote:

sb16 firmware exsts

CT1350 is NOT SB16...

sure, but its backwards compatible. anything you need to know about the ct1350 firmware is in the sb16 firmware. dsp 1/2x commands list is known. extrapolate from there. its not hard to use your brain you know.

Please don't take this the wrong way, but extracting the copyrighted microcontroller firmware from original Sound Blaster Pro and/or 16 cards and using them to create a bootleg repro card wasn't really what I had in mind.

I agree that basing the DSP of a Sound Blaster clone on the same MCS-51 microcontroller architecture would be era-appropriate and practical. Since this is a common architecture, sourcing modern MCS-51-compatible chips shouldn't be hard. But I really would prefer it if we could implement an open source firmware from scratch, perhaps using a "clean-room reverse-engineering" method similar to how Compaq legally developed an IBM-compatible BIOS for their early PC clone systems back in the day. Not only would an independently developed open source SB Clone DSP firmware make it legal to freely build and sell new Sound Blaster compatible sound cards, it would also provide the opportunity for us to start from a clean slate and avoid the bugs and development mistakes that Creative initially made when they developed the original Sound Blaster firmwares.

Also, if we were to write our own compatible firmware, perhaps we could make the same microcontroller handle fully MPU-401-compatible MIDI functionality as well. That way, we might not even need an FPGA for this design. Modern MCS-51-compatible microcontrollers should be fast and powerful enough to handle all of this functionality simultaneously. What do you all think?

Alternatively, we could also just flat-out ask Creative if they would be willing to release the source code to their original Sound Blaster firmware under a permissive open source license, for the sake of historic preservation and to score some nice publicity and nerd cred. They haven't sold any hardware based on such firmware in a long time, so they wouldn't be losing any crucial IP if they did. 😀

At any rate, I don't think it would be a good idea to use their firmware in a new sound card project without their permission, abandonware or not.

Half an hour ago finished testing first part of firmware for SB (commands available at DSP rev 1.0)
It’s written in C, so easily portable to (almost) any MCU.
At the moment, I’m doing this on my FPGA card, using “soft” CPU NIOS II - extremely flexible approach.
Biggest issue - a have never written anything in C (except things like “Hello world”), so it takes time and the code a bit far from being elegant 😀
Pretty sure I could achieve more-less 100% functionality of SB 2.01 in a week or so, including a hardware design - STM32 (don’t have any experience with MCS-51 and like STM32 more), OPL2 chip and a few 74xx ICs.
There is an issue - motivation. Only real motivation for me in this area - curiosity. I’m curious now to design the “ultimate 8-bit sound device”, but don’t have financial constraints or interest. It does mean that if I don’t loose the motivation too early, I bring the project to more-less working stage, but it will not be practical at all. I don’t care about the project cost, also use a technology not available to most of DIY enthusiasts (BGA packages etc).

I agree... using Creative's code should only be done with their permission.
I suppose the Music Quest card is a bit of a different story: the company has long disappeared, and afaik nobody else acquired the IP, so there is nobody to ask for permission (and conversely also nobody to sue for infringement on IP).

But in both cases, a 'clean room' reverse-engineered and reimplemented version could also do the trick. The SB DSP is quite well-emulated in various emulators, and there's also various products with an MPU-401 implementation, either software emulators or projects like HardMPU.
Having the real thing will give you perfect bug-level compatibility, so if possible, that is what I prefer.

Would a modern Cortex M4 have enough performance to emulate SB, SB Pro, and SB 16 with sufficiently low latency to be acceptable? It would avoid the difficulty of FPGA programming and lower the cost of the BOM.

gdjacobs wrote:

Would a modern Cortex M4 have enough performance to emulate SB, SB Pro, and SB 16 with sufficiently low latency to be acceptable?

Pretty sure, M4 is WAY MORE than enough for SB Pro/16. BUT - if we talk about some other stuff mentioned at the beginning of this thread, we may need extra ICs (for example, audio mixer etc).
Also could be tricky to run MPU-401 int mode AND DSP at the same time on the same MCU, but is it even required (are there any games that require MPU-401 int mode and can use SB at the same time) ?

What I really don't like about my FPGA design - all more-less modern FPGAs don't support 5V signals, so I need to add 7 (!) voltage converter ICs. They are cheap and small, but the design doesn't clean at all...

MCU or CPU is not gonna be enough on its own, you will need at least a CPLD to handle all the address decode and DMA tasks. You'll burn tremendous amount of CPU time by trying to do bus cycles and other things, turning your multihundred MHz thing into single digits stuff barely able to do other tasks. FPGA only or FPGA + MCU/CPU is the way to go. Analog sections will also be substantial unless you use some AC97 or HDAUDIO codecs with all such functions built in. Goodbye variable sample rates then though and resampling is a no-win scenario. (you could get away with CPU alone to some extent, by pulling IOCHRDY on all accesses, but the performance hit is probably gonna be really severe).

Tiido wrote:

you will need at least a CPLD to handle all the address decode and DMA tasks.

It's exactly why I have mentioned "a few 74xx ICs"... Also looked into CPLD + MCU scenario - still possible to get 5V tolerant CPLDs...

Tiido wrote:

FPGA only or FPGA + MCU/CPU is the way to go.

"Soft" MCU inside of FPGA seems most logical, but requires a lot of LEs AND memory - up to a need of external memory chips. Smaller FPGA + MCU seems more logical, but I don't like this approach on principle, doesn't look clean...

Tiido wrote:

Analog sections will also be substantial unless you use some AC97 or HDAUDIO codecs with all such functions built in. Goodbye variable sample rates then though and resampling is a no-win scenario.

It's exactly what I have mentioned before (about audio processing) - so easy with FPGA ! At the moment playing with IIR filter for converting a sample rate - SOO cool !

@Tiido
are you the same guy that messes with megadrive stuff?

Yup, I am !

Great stuff great stuff kudos 😀
/ot mode = off

newold86 wrote:

It's exactly why I have mentioned "a few 74xx ICs"... Also looked into CPLD + MCU scenario - still possible to get 5V tolerant CPLDs...

"Soft" MCU inside of FPGA seems most logical, but requires a lot of LEs AND memory - up to a need of external memory chips. Smaller FPGA + MCU seems more logical, but I don't like this approach on principle, doesn't look clean...

It's exactly what I have mentioned before (about audio processing) - so easy with FPGA ! At the moment playing with IIR filter for converting a sample rate - SOO cool !

74 chips aren't going to be worth it, you need too many of them to do anything interesting and the cost of them all plus time to put them on the board makes a CPLD way more attractive. 5V tolerance should be completely forgotten though, you have lot less parts, and lot more expensive parts aswell to choose from. Those level translators are going to be a very minor issue and visually they'll look like some EISA or VLB card with all the address and data latches 🤣. Or you can be super lazy and rely only on current limiting (not recommended for any serious thing)...

I'm not a super big fan of a soft core in an FPGA, especially when it makes no economic sense. Some small ARM chip + FPGA will cost way less than just FPGA that can hold equivalent of that ARM chip also.

From my experience, only the really complicated resamplers produce good results, simple IIRs and FIRs don't really cut it. But in a big enough FPGA you can do whatever anyway. There is still the problem of analog side mixing, having an ADC per input isn't super great and good digital pots are still really expensive. One can always have array of pots on the edge of the card though and single ADC, it isn't like you normally change mix levels a whole lot anyway and the digital sources such as SB, WSS and FM can be done all in digital domain.

Tiido wrote:

I'm not a super big fan of a soft core in an FPGA, especially when it makes no economic sense. Some small ARM chip + FPGA will cost way less than just FPGA that can hold equivalent of that ARM chip also.

Especially if a soft core requires additional external memory chip... But for experiments I prefer a soft core - much more flexible.

Tiido wrote:

From my experience, only the really complicated resamplers produce good results, simple IIRs and FIRs don't really cut it.

Maybe you are talking about real HiFi applications ? In my experience even a linear interpolation is good enough for something like SB + old DOS game...

Tiido wrote:

But in a big enough FPGA you can do whatever anyway. There is still the problem of analog side mixing, having an ADC per input isn't super great and good digital pots are still really expensive. One can always have array of pots on the edge of the card though and single ADC, it isn't like you normally change mix levels a whole lot anyway and the digital sources such as SB, WSS and FM can be done all in digital domain.

I'm playing with WM8731 - seems like it has all required for such project...

You probably wouldn't need a memory chip, the FPGAs that can hold a NIOS or other softcore will have plenty of RAM in them to implement program and work memory, and since you're pretty much emulating a 8052 or some other similar thing there wasn't much of RAM or ROM to begin with.

Simple linear interpolation will fail badly with FM output, all the noise type sounds (such as precussion) will sound very different from my experience, elaborate methods are required to get output that doesn't add any flavor and it can be hard to achieve. SB and WSS sample playback isn't going to cause any significant headaches though.

That chip seems to be decent enough, though I would still look at some PC targetted codec chip as they have better dynamic range (5V analog side rather than 3.something) and more inputs (so you can handle CD and other things too without more analog stuff).