Ever been wondering why there are chips labeled MHS on many Sound Blaster cards, and why there usually was some chip with a © Intel marking? For example this one, on a Sound Blaster 1.5 (1991):
Or this one, on a Sound Blaster Pro 2 (1994):
I was wondering the same…
MHS, or Matra Harris Semiconductor, was a joint venture between French Matra and US-based Harris Semiconductor, started in 1979. In 1989, just about the time Sound Blaster production started, Harris withdrew from the joint venture and the company was now Matra MHS SA. It is likely that the early MHS-branded Sound Blaster chips were manufactured in Nantes, France.
But what does Intel have to do with this? Well… the MHS-branded and Intel-copyrighted chips were the Sound Blaster DSPs, or Digital Sound Processors (not Digital Signal Processors!). In reality, the DSP was an Intel MCS-51 family microcontroller with pre-programmed ROM.
This is why the chips bear two © labels: The microcontroller as such is copyrighted by Intel, but the ROM was developed by Creative and bears a separate copyright. And MHS had a license from Intel which allowed it to manufacture the microcontrollers.
The DSP could still be found on 1994-1995 Sound Blaster 16s and AWE32s as a separate chip (in later models it was integrated):
As the above specimen shows, not every DSP chip was made by MHS; some were made by Intel, for example. Then again, the photo also shows that Creative had other chips produced in France, too (and on Malta—that was presumably SGS Thomson, now ST Microelectronics, another company with French heritage).
The fact that the Sound Blaster DSP was a standard microcontroller makes it naturally interesting as a target for dumping and disassembly. Not surprisingly, certain people are already on it.
It is not known to me if anyone had disassembled any DSP revision ROM yet. But it would obviously be of use to emulator writers, since even the early DSP revisions implemented quite a few undocumented commands. The Sound Blaster diagnostic utilities from Creative are heavy users of those commands.
It is plausible that the Sound Blaster DSPs had been reverse-engineered before. Some Sound Blaster clones (e.g. the Yamaha 724 chips) provide very good compatibility and pass all the Sound Blaster Pro diagnostic utility tests. Other clones (e.g. the ES1370 chips) are less thorough and Creative’s utilities reject them.
Sound Blasters were likely an early example of a PC sound card utilizing an off-the-shelf microcontroller design, but the use of microcontroller in sound processing is far older. For example Yamaha’s FM synthesizers had a built-in custom microcontroller with its own program in ROM. That design goes back to the early 1970s and is clearly described in J.M. Chowning’s original US Patent 4,018,121 (1975). The patent shows a custom “microcontroller” built from discrete parts (many from Intel, not surprisingly) and running a simple program.
Many later synthesizers likewise used off-the-shelf microcontrollers or microprocessors (e.g. Motorola embedded 68K CPUs on certain Turtle Beach or Ensoniq boards). By the year 2000, PC CPUs had enough spare power that sound cards with complex standalone logic were on the verge of extinction and most control functions were taken over by the main CPU together with the chipset.
We’ve got a mostly working low level emulation of the SB16 too. Finding the commands in a disassembly is easy too. For example, 0xF9, rather than being ASP related given an offset just returns the 8051 RAM contents at that address.
Very cool. I realize that for MAME, it’s not actually necessary to fully disassemble the ROM, but did someone do it and thoroughly document the commands as well as the external interface? Alternatively, are the ROM dumps available? What I’m looking for is something similar to this (see the links inside, too).
And what about older Sound Blasters, how similar/different are their DSP command sets? And did anyone figure out how to get the ROM contents out without desoldering (by exploiting the ROM itself)?
I disassembled it myself while writing the emulation as I had to figure out the fully undocumented mcu to dma-dac unit interface. I accidentally deleted the disassembly but it isn’t hard as there is a clear jump table for the top 4 bits of the commands. The ROM is around in sb16.zip in the MESS set (the Internet Archive doesn’t have it yet though) send me an email (the one with this post) if you can’t find it.
The older Sound Blasters also had an 8051 but it was connected directly to the cpu bus and the dac. So rather than having an ASIC which handled the dma, the timing and the output the mcu had to do them itself (look at the MESS emulation of an SB1.0 clone the ATI Stereo F/X). That’s why 0x40 Set Time Constant is strange. The time constant value is written directly into the 8051 timer so it’ll get an interrupt when a new sample needs to be sent to the dac. As for exploiting the rom, I didn’t find anything that would work although I didn’t look that closely and I’m far from an expert in that sort of thing so there might be something I missed.
Perhaps disassembling the ROM will find the cause of that pesky “struck note” bug that affected several revisions of the DSP found on the SB16/AWE32.
That occurred to me too, although I don’t know if anyone conclusively proved that the hanging note problem is caused strictly by the DSP (and not something else on the board).
Really interesting! I actually had no idea that they had microcontrollers, especially in a mass-produced (cost-sensitive) device that far back in time when I guess it would have been more expensive to put in a microcontroller compared today. I thought it might have been all all hardware, i.e. custom ASIC and no real execution engine. Wonder how many other controllers there were back then in standard PC – I think the keyboard controller on the mainboard (handling keyboard, A20 gate etc.) was also programmable and had a CPU. How about in the keyboard themselves? Did graphics cards also have them? Others? Of course back then it was mostly ROM so probably no user-programmable. Today it’s flash so potentially user programmable/hackable.
Today there’s of course CPU’s in everything – I think even the cheapest SD cards have 32-bit ARM’s in them 🙂
Reminds me of something: I had a Sound Galaxy NX II card in my old IBM PS/1 80486SX from 1993, but the computer shop (which mounted it) had supplied both disks for NX II and NX Pro. I found that the NX Pro programs were much cooler but unfortunately I ran one of their configuration tools and caused a permanent change to the card so it wouldn’t work immediately on boot. There was no remedy for that using either the NX II or NX Pro utilities that could bring it back. From that point on I needed a special supplied utility in autoexec.bat (SGVOL /R) or something like that to reset the card on every boot which would fix it for that session. Fortunately Windows 95 still had autoexec.bat so I could still use this remedy there when that came out 🙂
(My point with the above was that one of the NX Pro utilities probably made some change to the EEPROM settings or something, which were incompatible with the NX II firmware and apparently could not be set back to sane values by the NX II utilities).
Yes, the keyboard controller is a classic (8042/8047, although alternate implementations existed too). Keyboards had/have them as well. I think especially the OTP and ROMed chips actually weren’t all that expensive and that’s why they were used.
Graphics cards were all over the place. Some were quite “dumb” (e.g. VGA), others had a RISC CPU (e.g. TIGA), and everything in between existed too. Oh, SCSI controllers often had generic microcontrollers/CPUs on them too — Z80, 8051, 80186, all sorts of stuff. The SCSI HBAs often had programmable microcontroller firmware. IDE/SCSI hard disks of course had microcontrollers or CPUs on them too.
With the exception of some graphics cards, the embedded CPUs were not user-programmable, not even in cases where firmware had to be uploaded (various sound cards, e.g. Ensoniq SoundScape). So they were considered a black box and there was no documentation because there was nothing for the users to tweak.
Interesting about the NX II EEPROM. Probably some unintended behavior. I’ve had a LCD panel lose its EDID, which is also quite nasty; fortunately it was possible to reprogram it again.
The 3c505 nic had an 80186 and the Dectalk PC speech board did too.
And then there’s the related category of DSPs, like IBM’s Mwave. This was a DSP and not a generic CPU or microcontroller, but it was user-programmable, in theory at least (not sure how much documentation IBM ever made available). They did stuff like AdLib emulation in the DSP.
The WD1015 found in some XT hard drive adapters is an 8048-compatible microcontroller. Of course, the original Xebec XT hard drive adaptors used a full-blown CPU (a Z80) rather than an MCU.
The Wyse WY700 graphics card uses an MC68705P3, but there’s no rebadging there.
I suspect the chip labelled IBM 1503828 / SC81155P on the IBM 3270 PC keyboard adapter may also be a microcontroller (in the same sort of role as the 8042 on the AT motherboard), though I don’t know how one could tell short of official schematics or decaps.
Might as well also mention the IBM PGC (designed by Vermont Microsystems AFAK) which included an 8088.
Cool thanks for the referrences 🙂
Also the Commodore 64 disk drive 1541 and a full-fledged 6502 processor and in fact implemented the file system management routines in the drive themselves.
How about floppy controllers in PC’s? I seem to recall there were some “microcode bugs” in some NEC-compatible controllers. Might suggest they had a kind of controller internally (although microcode could also mean true microcode, i.e. ROM tables of low-level control signals).
There definitely is a microcontroller in the PC FDC. Whatever control program there is only exists in a ROM though, there’s no programmability. NEC was quite active in the CPU/MCU field and NEC chips would be found in, say, Yamaha synthesizers (seen in an FB-01 for example).
The CBM 1541 is a classic indeed (same CPU as the C64), and then there was the Apple LaserWriter printer with a RISC CPU more powerful than the Mac driving it.
Basically in a random PC there could be quite a few microcontrollers and microprocessors besides the main CPU.
Actually the original LaserWriters used 68000 CPUs. They were clocked higher than the Mac’s (12 MHz vs 7.something), but that was about it 🙂
As far as microcontrollers, the GI AY-5-3600 keyboard decoder used in later-rev Apple IIs and II Pluses has some sort of embedded microcontroller, and GI was making the first PICs in the late 70s (Microchip bought GI’s PIC business in the mid-80s). Also check out recent MESS progress emulating several dozen late 70s/early 80s electronic toys and games containing early 4-bit and 8-bit microcontrollers (Simon, Speak and Spell, etc, etc).
>definitely is a microcontroller in the PC FDC
afaik its a simple state machine, at least thats what I remember from block diagrams and patents