Page 1 of 1

What should the first articles be about?

Posted: Sat Jun 24, 2006 1:07 am
by chase
So in my spare time I'd like to start writting articles for the wiki and I'd also like to make a list of the most wanted/needed documents.

In the long run I want the OSDevWiki to be something more book/wikipedia like and not like a FAQ. I've got the two exising tutorials at http://www.osdev.org/howtos/1 and http://www.osdev.org/howtos/2 and I've got part of a third somewhere about boot sectors.

So I'm asking for requests, anything from PMode startup to boot sectors to FAT12/16, EXT3, UFS, Hello world assembly, to just completely rewritting the existing howtos.

Suggestions?

Posted: Mon Jul 24, 2006 12:30 pm
by ComputerPsi
Perhaps an article on accessing devices at a low level? (Thus how to make device drivers.)

Posted: Mon Jul 24, 2006 3:12 pm
by Dex
Yes simple stuff, like device drives to start with, first do a article on checking for device and vendor ID, by scan through PCI space.
Then you can move on to converting info in pdf like this :
http://redmoon.openbsd.de/~merith/RTL8180spec_1_2.pdf
To a devic driver, by read/writing to address from the offset of vendor/device id and changing bits at differant address etc.

Posted: Thu Jul 27, 2006 11:57 am
by chase
If we start of with a simple device driver I think I'd want to start off with a serial port driver since it would have a lot of debugging use. But pci card detection would be number 2 on the hardware tutorials so far. I personally think a nic driver should come after networking/loopback tutorials but we'll need a well documented pci card like the Realteks if we want a simple example pci driver. Can anyone think of a pci card to use in a tutorial that wouldn't require networking stacks, sound subsystems, etc ? I'm thinking the hardware we write about should be hardware that is emulated in popular virtual machines so that everyone can use the tutorials.

Posted: Thu Jul 27, 2006 4:46 pm
by carbonBased
I agree! The first driver I wrote for my OS was a serial port driver, and I've been quite happy with it. Redirect your OS tracing to it, and you've got a method of logging loads of trace to a file (either through a terminal application on the other end of an actual serial connection, or using qemu's redirection of the serial port to a device!).

--Jeff

Posted: Fri Jul 28, 2006 1:19 pm
by Dex
Yes a serial port driver, sounds good to me too, also as a bonus, built in IR in laptop's etc, will also work with the same driver.
Thats how my "furby" program i wrote works :lol:

Posted: Fri Jul 28, 2006 3:09 pm
by carbonBased
What's the baud rate on one of those suckers, anyway?

And what's this furby program you speak of? :)

--Jeff

Posted: Mon Nov 13, 2006 9:15 am
by inflater
I wroted formerly too a tiny serial port "driver" (real mode); well, it was no driver, but a routine to access serial ports through BIOS. So no IRQ (i dont knew what is IRQ when i wroted that driver). BIOS for this operation VERY suxxx, because if you are receiving some data, you'll likely lose it - BIOS COM port functions are good only when transmitting data, like for Plotter or something.

Baud rate: 9600 bd :D:lol: (faster not possible with BIOS)

Little OFF TOPIC:
When the IRQ3 (COM2 port) triggers? When it receives data? Or i must program this myself?
//EDIT:
I must probably do this, when I want to trigger COM2 IRQ when data receives:

or ax,0
mov dx,3F9h
out dx,ax


Please correct me if I have in this error.

inflater