The reason you can't select 8 bit signed and 16 bit unsigned is because 8 bit unsigned and 16 bit signed are the default values.The unsigned 8 bits go from 0 to 255 and the signed 16 bits go from -32,767 to 32,768. In reality, it doesn't really matter whether it is signed or unsigned, as long as you know which one it is.

The 16 bit and 8 bit should come out to the same size and speed because my program converts the 16 bit to 8 bit. It also converts stereo to mono

I want to improve solver so that it works like this. A = B. Instead of 0=B-A. And to do this, I am going to have to screw with the system monitor and solver's context vectors. I know almost nothing about these because there isn't much information released about them. But I know that people have the information. So basically, I just need to be filled in.

The sdk, was slightly helpful, along with wikiti. But what I've gathered so far is this. cxMain and the 6 vectors after it are basically a call table. When an event happens, one of the vectors is followed and the code is executed. But each one of those vectors appears to have it's own guidelines just like the hooks do. I can probably figure out the usage with enough debugging, but some notes would be greatly appreciated.

Edit:
    So I'm starting to figure some of it out. It looks like for cxMain, it gives you A = key, and you return the new key to be pressed in A with NZ set if it should be used.

The main thing I'm trying to figure out now is how the screen get's drawn. It doesn't look like cxRedisp ever gets called.

It takes a sample rate of bytes per second. So most calculators average around 23,000Hz making for 23,000 bytes per second. (This makes DCS look tiny )

DJ, thanks for finding the bug with the C++ runtime libraries. I've had several people tell me they weren't necessary, but I guess they are.

With the microsoft 8 bit pcm, I don't know what other format they could have used. 8 bit seems pretty straight forward to me. One possibility is that my speed test actually finds a glitch in wabbitEmu. The instruction ADC HL,BC runs 4 t-states too fast. WabbitEmu is supposed to run at 15,000,000 Hz which gives a proper sample rate of 15,000,000/696=21,552. But if you say that you had to double the speed, then there's a different problem.

So are you saying that an 8 bit song playing at twice the speed was the same size as a 16 bit file playing at the right speed?

And finally, wabbitEmu tends to add some really nasty high pitch noises into the song. (It might be the sound card too). So don't think that those are final. But surprisingly, you're song didn't do it DJ, that might be because it was made with a computer.

Would you look at that. Someone made a hooks page.

Since it is a wiki, feel free to fix any mistakes I made.

(This marks the first time that I linked the word "that")

That's strange... What are you using to compile the program? I used visual studio 2010. The year probably doesn't matter since this is a simple program, but perhaps if you don't have visual studio, you won't have exactly the same libraries.

It depends how your parents are and how comfortable you are with working with your hands. But I have fixed similar problems in 3 laptops by taking them apart and using an air compressor on the grate. (just be gentle )