Native sound format

[Octocontrabass]

That's disappointing, but good to know. I'd be interested to know what the specs are on that machine.

The first test box is a 386 with 20MB of RAM, running at either 16 or 40 MHz depending on the turbo button. The BIOS date is 1991.

The second test box is an AMD K6-2 with 512MB of RAM, running at 402MHz (overclocked from 400MHz). The BIOS date is 1998.

If you need more detailed information, I don't mind opening them up to get a list of components.

How much RAM is on that machine? I am making some assumptions about available RAM, but that code "should" work with anything over 4 MB.

Is "A20 has been enabled properly" one of those assumptions?

[SpyderTL]

Is "A20 has been enabled properly" one of those assumptions?

Yep.

I'll see if I can make my boot loader a little smarter, and update the disk images later tonight.

EDIT: Okay, both download images on CodePlex have been updated to use the "legacy" keyboard controller A20 enable routine, and the memory map BIOS call has been commented out, for now. See if those images work better on those two machines.

[Octocontrabass]

I tried the floppy disk on both machines. It still doesn't work, but it also doesn't reboot, so that might be an improvement.

On the 386, it erased the disk.


The CD version no longer reboots when I press tab at a blank prompt. Instead, it hangs. At least this time I can get a good look at what it says:

Code: Select all

>_
Acpi Audio Boolean Debug Double Float

[SpyderTL]

I tried the floppy disk on both machines. It still doesn't work, but it also doesn't reboot, so that might be an improvement.

On the 386, it erased the disk.

Well...

That's... new.

The CD version no longer reboots when I press tab at a blank prompt. Instead, it hangs. At least this time I can get a good look at what it says:

Code: Select all

>_
Acpi Audio Boolean Debug Double Float

You should get a list of all of the "classes" that have been marked as "static". There should be 23 of them, right now. I have several of the commented out because my hand-rolled boot loader apparently has issues above 1 MB. Instead of hitting TAB, you can try typing them in manually.

Code: Select all

Acpi Audio Boolean Debug Double Float Hexadecimal Integer Matrix MemoryReader MemoryWriter Internet InternetConnection Network NetworkConnection Pci Processor Real Storage System User Vector2 Vector3

You can normally type a class name and a dot (.) and hit Tab, and it will list the static methods of that class, but if that does not work, you can try this:

Code: Select all

>Class.Find("Acpi").GetStaticMethods

This should give you enough information to start exploring the functions that are available, and maybe find a few things that actually do work.

I've been using VirtualBox, mainly, as a test bed, but I've also used VMWare, VirtualPC, SimNOW, QEMU and BOCHS, which all seem to work pretty well. If you just want to see how everything works, you can try one of those.

Have fun!

[Octocontrabass]

I've been using VirtualBox, mainly, as a test bed, but I've also used VMWare, VirtualPC, SimNOW, QEMU and BOCHS, which all seem to work pretty well. If you just want to see how everything works, you can try one of those.

Nah, real hardware is more fun.

All of those virtual machines you list support features that are a bit newer than any of the test machines I've used so far. With that in mind, I've decided today's test machine should be something a little newer. How about...

...Dual Xeon E5-2650 v3 with 64GB of RAM.

As you might have guessed, this is not a desktop PC. Obviously there is no floppy disk drive, and I don't feel like burning a CD either. Fortunately, servers tend to have interesting remote access tools, and in 2015, remotely-accessible virtual floppy and CD drives are standard.

The floppy disk doesn't work.

The CD boots, and it works pretty well. Pressing tab to list the static classes actually lists them all, without hanging or rebooting between Float and Hexadecimal. I managed to get a list of PCI devices and ACPI tables, and the processor brand string "Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz". Trying to get the storage devices appeared to hang the machine, but after a while it printed some garbage and resumed with no apparent issues. Trying to get the audio devices hung the machine and did not recover.

That was fun. Maybe I should try some other OS projects on this kind of hardware...

[SpyderTL]

Well, that makes me feel a little better.

I'd love to be able to test on a ton of old hardware, but I've been getting rid of all of my old machines over the years and replacing them. I never thought that I'd miss them. :/

Thanks for the help!

[rdos]

Any new audio design should support HDA, which is part of most new PCs. Soundblaster and AC97 are old things you shouldn't bother with.

As for audio-formats, PCM is what is used in HDA, so you at least need to provide HDA with that. You should support several bit-depths. Number of channels is also a parameter, but HDA transmits multi-channel data on several streams, so stereo streams are the basics there. As for MP3, I have this as a user-level library.

[SpyderTL]

Trying to get the audio devices hung the machine and did not recover.

I think it was waiting for a response from the (non-existent) sound blaster.

I originally "detected" the ISA sound blaster by flipping the reset bit, and reading 0xAA from the data port. The problem is this forcefully resets the SB even if it is currently in use, so I changed it to send the "GetVersion" command, and waited for a response -- indefinitely. It works great, as long as you have a sound blaster on port 220.

So, I need some way to detect a sound blaster without resetting the device, and without waiting forever for a response. The most obvious solution would be to add a timeout to the wait function, but I don't to waste time looking for something that will probably never be there if I don't have to (if there is another way).

Does anyone know of a quick way to detect a SB16 card without using the reset bit, and without needing a hard-coded timeout?

EDIT: For now, I've just added a timeout on the SoundBlaster code. The images on CodePlex have been updated.

[SpyderTL]

Any new audio design should support HDA, which is part of most new PCs. Soundblaster and AC97 are old things you shouldn't bother with.

Yeah, I thought about starting with HD Audio, but ultimately decided that I would work on the SB16 first, thinking that it would only take a fraction of the time to get working... I may turn out to have been wrong.

I did get some garbage audio playing within a few hours, and got actual sine wave audio playing within a day or two, so that's pretty quick for me, all things considered. I'm assuming that HD Audio will take a bit longer to get working... Plus, I was really more interested in working on the OS side of things, handling audio streams, mixing audio streams, down-sampling from stereo to mono, etc. Once I know all of that is working and stable, I'll start adding more audio devices.

[Combuster]

I originally "detected" the ISA sound blaster by flipping the reset bit, and reading 0xAA from the data port. The problem is this forcefully resets the SB even if it is currently in use, so I changed it to send the "GetVersion" command, and waited for a response -- indefinitely. It works great, as long as you have a sound blaster on port 220.

Why is this a problem if you would only ever want to do this once? If you do hardware detection once at boot time and keep the soundblaster listed as a device thereafter, you know it's not yet in use when you reset it, and you don't need to reset it ever after, when it might be in use.

[SpyderTL]

Because the OS doesn't have an internal list of devices, at the moment. It just allows the user to enumerate devices on the fly. The user can "save" a reference to these devices, or they can just re-enumerate them later.

Code: Select all

Audio.GetDevices.First.Play(SineWave.Create(440.0, 44100))

versus

Code: Select all

User.Objects.Add(Audio.Devices.First)
User.Objects.First.Play(SineWave.Create(440.0, 44100))

This all works fine for PCI devices (assuming everything runs in a single thread), since they can be detected repeatedly without interrupting them.

And it's really not a big problem for the SoundBlaster when you're are just playing audio clips. I just ran into issues trying to troubleshoot some interrupt problems, because using the first approach (above) reset all of the interrupt registers every time.

Of course, all of this will have to change, eventually, to make all of these devices "thread safe", so-to-speak. But that will probably happen after a complete rewrite...