OSDev.org

After a lot of development learning around a 12-year full time span, I have noticed that the PC is crippled in standard hardware but at least it has the functions to enable the different video modes, 32 or 64 bits, using storage media and the like.

But an area where at least a modern PC absolutely lacks any BIOS or standard functions (even around, before and after year 2000) is sound, the sound card. Without sound that can be readily used after booting, not many people think about making games or multimedia programs without Windows.

With such a modern card that could just be used after boot (like a driverless standard Sound Blaster), the PC platform as it is would immediately become a real option as a gaming console platform, and many people, not just big enterprises, could implement games and multimedia programs again easily.

We just need to seriously use brain power to concentrate efforts to implement a PCI sound card that works as a truly standard Sound Blaster, find out which chips to use, and do it.

So I have been thinking, why not look for a way to document in the Wiki and the forum how to make PCI cards? From there, it would be necessary to find the right sound, signal and processor chips to program the Sound Blaster logic, commands, DMA usage, etc.

These are Google results I have found very useful:
http://www.pyroelectro.com/2011/06/29/making-your-own-pci-interface-diy/
http://hackaday.com/2005/10/07/pci-simplified/

http://google.com/search?q=how%20to%20pci%20card
http://google.com/search?q=how%20to%20make%20a%20pci%20card



I'm thinking that we always resent in practice that there are no longer standard hardware devices such as video and sound cards, but now there are many powerful things like FPGAs, Arduino, and there are even some x86 test board, and probably other kits I don't know about that we could use to build PCI cards that have open standards with full compatibility with legacy PCs, but now running in modern machines.

For sound, we just need to find which integrated circuits are needed, which processors, how to implement the MIDI logic, the wave table, the frequency generator (this one to play sound), which DAC and ADC chips we could use, and look for a way to provide at least Line In, Line Out and Microphone. Those should probably be different chips so as to provide all those functions simultaneously.

So why not make a serious and continuous try at implementing PCI devices that really work and that are really standard, which have the full logic implemented into the hard card so we don't really need drivers to enable, find or use those functions? It would probably be more beneficial to preserve and port the standard features that are fading or that were left only in ISA hardware (simple yet scalable NE2000 network, Sound Blaster sound, standard SVGA with already-accelerated processing for all graphics hardware operations), would unstall most of OS development that always stops at trying to drive non-standard hardware, and would finally make feel that the PC platform is safe from dying by the complete loss of hardware standards for driving devices given that now we would openly implement those devices.



Maybe Ben Lunt could also make a tutorial about handling the PCI logic, hardware, circuitry, bus, protocol, etc. Then it would also be possible to build open hardware and books that talk about implementing PCI cards with updated/ported legacy standards, and the first thing that comes to mind in order of importance are always sound cards that at their base are fully compatible and usable without drivers even from old DOS games as Sound Blasters, to then add AC'97, but without leaving out the full Sound Blaster specifications.

We already have a modern standard for sound cards. It's the Intel High Definition Audio Specification.

But even with that specification we still don't have sound available in every machine even while booting, which should be corrected.

We would still need to implement our own cards, PCI, USB, etc.

Those existing cards, Intel-based or not, will still use registers, commands and other vendor-specific details that don't allow having sound available without a driver, unlike prior standard hardware which at most changed only the port addresses and IRQs, but retained the rest of the same structure across all vendors.

Also, just like with VGA/VESA, CPUs, file formats of the same kind, and many other things, we would need a sound card that contains more than a standard mode for keeping compatibility, a standard structure for past PC generations, and being able to easily use and select standard modes without a real driver, just a few commands (so we could change between Sound Blaster, AC'97 and the Intel specification). It would be like a standard VGA card with different modes according to what the program wants to do. The BIOS should even be presented a BIOS from the sound card (option ROM) so that standard or new IRQ vectors could access sound services, but it should be open too.

Also, as far as I have read and understood, recent sound cards only have a high definition sound chipset. They have no more capabilities than producing sound, and receiving input and microphone audio. But they supposedly don't have MIDI processors, the hardware itself can't adjust the quality of the wave data. It doesn't mix audio on its own. The driver adjusts the quality, mixes, produces MIDI, all with software.

If that's true, it means that our modern sound cards practically have no functions on their own. They are like incomplete hardware that depends on a driver to perform all of its advanced tasks, unlike original ISA Sound Blasters, which is what I'm talking about converting to PCI.

At the very least, if we were to implement a programmable PCI sound card, it would be an advantage in itself since it would be open hardware to begin with, using the most capable generic chips for DSP, MIDI, wave table, frequency generation, DAC, and ADC input/output. It would have the advantage of having all of the capabilities built into the sound chipset and the firmware which we would need to write. From there we could conveniently implement the original Sound Blaster specification fully, then as time advances, we could add AC'97 and Intel Sound.

But what is more important here is to implement the Sound Blaster. Of course audio quality should be selectable in hardware, but the highest sound quality would depend on the hardware itself, so it could sound as well or better than the original Sound Blaster, but would have its capabilities as the bare minimum, and more, given the possibility to expand the onboard logic.

That's what I'm seriously thinking about to make PCI more understandable, and on the other hand to prevent good and necessary standards like Sound Blaster from disappearing (found even in every game or DOS emulator around all PC and tablet platforms), given that now we should learn to find adequate chips and use them to implement capable and truly standard, truly configurable cards.

It would probably be the best option to experiment implementing a PCI card and very easily making sure that it really works correctly by using only any easy to find legacy software that makes use of Sound Blasters.

The most important functions - playing and recording audio - are entirely standardized in Intel HDA, and do not require any vendor-specific commands. One generic driver will work with all HDA devices.


Modern computers are more than capable of emulating older sound cards entirely in software.


No one uses BIOS services outside of bootloaders, so there is no reason to waste time adding new ones that aren't going to be used by bootloaders.


That's because modern computers are more than fast enough to do all of that in software, and at much higher quality than any hardware implementation.

Computers might be fast in general since PCI exists, but if we see closely, only sound cards have evolved backwards. Every other peripherals (graphics chips, CPU, USB, disks) are smarter, have many more onboard capabilities than a decade ago, and still have a minimum standard mode of operation.

So it's clear that having a more capable sound card that again takes it to the level it had in the Sound Blaster era (MIDI, adjustable sound quality, etc., all in hardware) is better, specially for programs and games that just want to run.

Or we will forever be stuck with unavailable sound outside Windows, where previously we could enable it when we wanted.

It's the same as programs that know next to nothing about sound file formats and algorithms, and just use DirectX. It would be better. Sound would still have some form of glue driver and would use DirectX for the most efficient access under Windows.

What would benefit would be sane accessible/legacy architectures and standards, the original Sound Blaster (obviously), tiny games and multimedia applications, hobbyists, tiny custom OSes like the ones we see here all the time, DOS/FreeDOS, Linux, and the PC as a valid, complete option as a console (although we would need to implement also a NE2000 network card or another standard one).

There are two reasons for that:

1. All of the devices you've listed operate at significantly higher speeds than any sound card in existence, and
2. All of the devices you've listed require backwards compatibility in order to boot existing operating systems.

It would be equally possible to offload the capabilities of other peripherals to software, but no one has done it because software can't run fast enough to compete.


Programs and games that "just want to run" won't be directly manipulating hardware, they'll be using the operating system's interface. Application software doesn't need to care if those features are implemented in hardware or software because the operating system and drivers do all of the work.


All major non-Windows operating systems already have HDA drivers.

Tiny operating systems, legacy games and programs and the BIOS/DOS don't seem to have HDA drivers, or the capability to make use of sound everywhere.

Even then, to do all you want (MIDI, different sound qualities) would require an enormous driver that would probably prevent some games from running, and everything you write would be huge. There would be no option but to implement all functions in software unless they are included in the hardware, which would then make that optional.

If I build an OS, why would I want to implement a driver? It would be the same, it would be like a program that isn't interested in manipulating hardware, just using a sound interface. I'm no longer a regular system user when writing a kernel, so having those capabilities in the hardware instead of in a driver would be the same, but only best because all memory footprint required by a driver, the complexity of implementing it and the standardization of the interface would be better invested in making a fully portable, fully capable sound card, which already prove to be the most powerful option as demonstrated by the many enjoyable demos and games that people doesn't stop using and downloading since the 386 era and the fact that emulators don't stop implementing Sound Blasters.

Those applications and every casual OS and multimedia programmer would make a lot of stuff with such capable and standard cards. With modern electronics they could sound as well as the Intel HD sound while having Sound Blaster programming. Many cards have that compatibility and AC'97 for example.

Implementing MIDI and the rest of stuff like a mixer would be basically the same as in software, but as I said, the investment would be much more valuable than writing a random driver version, because that's not the real need right now. A better and more accessible sound card is what is needed.

Just think that designing such sound card would be useful not only for a standard PC, but also to implement USB versions of the Sound Blaster, and beyond that, we could use this same circuit in embedded non-PC and ARM devices. We could also use it just about everywhere sound is needed, even analog AM/FM radios could make use of this Sound Blaster chipset, and we could perfectly trim it down knowing how it works if we need to, or leave it as is to signal different tones with MIDI or wave table.


________________________________________________________
________________________________________________________
But now for the actual chips to use, I have only found out that FPGA can be used as a PCI interface that can get to identify itself. Now the question is how could we generate a random tone and maybe implement a test register to enable or disable it, or probably to switch to a mode where we could write 8 to 32-bit wave data?

What sort of generic chips could we use to plug to the FPGA and then take pins and an amplifier circuit/chip to implement a Line Out? After this, we can start playing around and then decide which Sound Blaster commands would be needed to handle playback, at least for an 8-bit wave data stream.

There's a program around called DMAW that plays raw WAV files by manipulating Sound Blasters. This program could be used to determine which commands to implement first, build a Sound Blaster emulator that only implements them, and then describe the logic to implement them in a way that is understandable and portable to any onboard programming.

So far I'm also assuming that 8-bit 8KHz means 8000 or 8192 bytes per second of 256-tone audio.

Ohhhhh, man. It has been a while since a good ~ thread came along. Let me go get my popcorn.

• Tiny operating systems tend to be lacking drivers in the first place. Sound drivers are not a priority for most developers.
• Legacy games can run in emulators, which makes hardware compatibility irrelevant.
• The BIOS has never had support for sound cards.
• DOS is only useful in emulators, which makes hardware compatibility irrelevant.

Why would the size of the driver have any effect on whether or not a game will run? Why would the size of the driver have any effect on the size of other software?


You seem to be the only one who thinks so. Everyone else is fine with HDA.

Why would you not want to implement drivers if you're writing an OS? As the operating system, you're responsible for doing exactly that, operating the hardware to provide a unified system, or to look at it in another way, you'd still have a program somewhere, that operates the sound card, thus being interested in manipulating said sound card hardware, making it a driver. Also, since Intel HDA is already pretty much standard, why move back to the Sound Blaster interface and standardize that? Writing drivers for HDA is already simple and streamlined, write the driver once and you'll have audio on practically every modern x86_64 based computer. In that sense, doesn't it already fit what you want by standardizing the interface? Wouldn't then, moving back to a sound blaster interface throw away an elegantly designed fully portable, fully capable sound card interface?

I want to write a driver. What I don't want to do is doing that thousands of times for every model. I'd rather implement a card that is programmable and include there all logic and all circuitry instead of in a driver.

Implementing a full Sound Blaster with MIDI, wave table, mixer, adjustable sound quality in hardware and the rest of the specification, into the card itself, not in the driver, would make things much simpler. It's still more capable than HDA, at least for legacy stuff that is still used. HDA won't cover legacy compatibility and ease of programming, nor sound processing fully based in hardware.

The driver would only be glue code that invokes the sound card commands sequentially but everything else would be left to the card, unless you choose to mix and generate digitized sound yourself, but that would now be optional. If you can't the card would do all of that. Very important if you want to turn the PC into a console. Just implement NE2000 or a standard and known network interface, and you have a great gaming machine without needing Windows, although logically most people would use it, but programs would be much less tied to it now.

Such card could contain base support for Sound Blaster, and also AC'97, HDA, etc. could be added later. Many cards, at least those around the Pentium III era, like the one integrated into the IBM Thinkpad 390x, have compatibility with multiple standards, Sound Blaster and above.


__________________________________________________________________
__________________________________________________________________
Frankly, I'm currently at a level where I need to decide which base chip to use for PCI (FPGA...) and study/decipher/emulate the basic commands used by DMAW, as well as find out how to generate output sound, or write it at least without DMA to begin with (what matters first is to just generate any output audio wave from a PCI card).

Break the cycle and stop using legacy stuff

Hi,



Or embrace the legacy and use the PC speaker and PIT chip for sound...



Because this forum is for OS developers, not for hardware manufacturing; and because (unlike software where "manufacturing costs" is zero because it costs nothing to copy file/s and you only have to care about "development costs"/creating something to copy) for hardware development the manufacturing costs for a commercially viable product (e.g. ASICs that don't violate someone else's intellectual property) is "millions of $$ that nobody has".


Cheers,

Brendan

Of course not. That's why you put common functionality like that in a separate library or something. For example, your HDA driver can call the library function to synthesize MIDI, while your SoundBlaster driver can send the MIDI directly to the hardware synthesizer.


It's not supposed to. The point of HDA is making a cheap, high-quality product by having the CPU do all of the complex processing.


Funny you should mention that. Since the nineties, consoles have used the CPU to do all of the audio processing, and the built-in sound hardware is extremely simple. (Simpler than HDA, with fewer features!)

Here's an aside which a fan of ancient systems ought to find interesting: the original Macintosh drove both the graphics and the audio in software, using the 8Mhz 68000 CPU for almost everything. It would use the interrupt timer to issue the hrefresh signals at some fraction of a second, and on the vrefresh, it gave them 180 cycles while the cathode gun repositioned in which to perform the audio. They managed to squeeze four voices of playback into that 180 cycles, and still give 95% of the CPU time to the application.

It is safe to say that modern CPUs can handle the audio processing just fine without much hardware support. The only reason the MS-DOS Era PCs used it was because audio beyond the internal beeper wasn't a standard part of the system.