OSDev.org

This is a continuation of my above post.

I now have the ability to read the contents of files on an ISO 9660 filesystem (Rock Ridge long file names are supported) on an ATAPI CD!
There is a shell thread that does the reading & writing, a file system thread, and a device driver thread. I have an asynchronous API (you hand a callback to IO operations, they don't return anything immediately) - unfortunately it's messy to write that way in C.

AWWW YEAH!!

Just got assigned my first DHCP IP Address!!

Look out, Internet. Your new master has arrived!

AWWW YEAH!

Just got my first HTTP GET / HTML/1.1 response back from www.microsoft.com and dumped it to the screen...

I got a complete web page from http://www.osdev.org!

AWWWW YEAH!

I think I'm going to take a break from networking for a while and work on playing PCM audio.

I'm trying to decide to start with something simple and go with a simple SoundBlaster 16 driver, or just go ahead and bite the bullet and write an HD Audio driver. I'll eventually do both, but which one should I start with?

SB16 is probably simpler, overall, but it does rely on the old DMA controller. I assume that HD Audio uses PCI bus master and buffer lists, which may actually be easier to code for than DMA.

What do you guys think?

Bite the bullet. Old things are a waste of time. Intel HD Audio supports a lot of real hardware.

And for that hardware which doesn't, AC97 is supported by just about anything. Anything much older than that and you're into Pentium pre-MMX territory.

Wasn't it the problem with in particular AC97 and possibly HDA as well that they are just bus controllers, and you still had to support the individual devices of the whole myriad that could be wired behind the front controller (pretty much functioning like USB without hotplugging features and not actually being one-driver-fits-all)?

Probably when I completed my custom filesystem "VectFS" specification and it booted from a USB stick on real hardware
Aw yeaahh

Combuster wrote:Wasn't it the problem with in particular AC97 and possibly HDA as well that they are just bus controllers, and you still had to support the individual devices of the whole myriad that could be wired behind the front controller (pretty much functioning like USB without hotplugging features and not actually being one-driver-fits-all)?

That is a problem, but for AC97, almost every sound card/motherboard sound device uses one of Realtek's AC97 ICs. The ALC101 is about as bare as you get (16-bit/48kHz out, two channels, three line-level stereo in, one mic in, amplified stereo line out, external clock), while the ALC202 and 203 have things like 20-bit DACs, 96kHz SPDIF out, internal crystal/clock, etc. Targeting the ALC101 would probably get you sound on most AC97-compatible motherboards.

I probably have 3, first time I booted a simple hello world bootsector. First time in protected mode. And more recently when my VFS and FAT12 code was at the ls/dir and type/cat stage. Sadly lost all that code, which made me shelf the whole OS for another 2 years. Hard to keep away much longer then that though! Seem to always circle back.

Got drivers loading through Reflection, AWWWW YEAH!

Getting this from the serial out of my old cellphone:

- Seeing a Raspberry Pi output my text with my software-defined font to HDMI in 1080p on the first try
- Finding out why it takes a few million opcodes to switch to the idle task, to find out that there are two different bugs interacting in perfect unison to produce the right behaviour. One was following an uninitialized pointer, the other mapped pages in on-demand (without clearing them).
- Booting a computer into long-mode directly from your own loader when all docs at the time said you couldn't.
- Seeing a directory listing from my own code.
- Having GCC compile with a special myos target without any problems.

task switching on ARM