OSDev.org

First of all let me greet all of you.
In all the darkness of my mind, finding you was a lightful suprise; i didn't know how big was the world of OS development.

I'm a student in informatic engineering in Rome and i'm preparing my thesis.
Going around in Internet i found the article of Krishnakumar on LinuxGazette about "Writing a Toy OS" and i was fascinated by it. Talking with my teacher, we decided to prepare myself about OS Development. In particular he asked me to write a little OS that can permit two computers to send messages each other by a network card.

Now i'm in problem.
On the first time i thought "well, what's the problem? Like in the article of Krishnakumar, i use a software interrupt, load values in some registers and then all is done!" . Well, i was in panic when i didn't found, in the documents that i found on the Net, any software interrupt for the network card.
I searched in Internet and i found a document (http://www.crynwr.com/packet_driver.html)
that says that values for software interrupts for network cards range between #060 and #080 and i need to scan handlers to find my software interrupt. Is it true? There is no other method to find these int? (I visited the Ralf Brown's Interrupt List but, it seems to me, i don't find a software interrupt associate with my network card)
In the case this is the reality, a question is raised in my head: if the software interrupts are different for each computer configuration, it means that my toy OS will probably not run on other computers?

I have already searched the forum for some answers but unfortunately i didn't found anything.
I'm open to understand my work and i'm really interested in what i'm doing, so if i was wrong in something, i appreciate very much that you explain to me.
(I have enough knowledge of network protocols, programming language and assembly to understand you so you could talk directly without too much circumlocution)

Thanks everyone and best regards[/url]

Hi!

I just read a bit into the document you specified... unfortunately it doesn't tell anything about the environment the driver is expected to run in (protected mode/real mode and stuff). As it seem to deal with interrupt handlers directly, I suspect it should run in real mode, and that it installs a custom interrupt handler at initialization (how is the initialization done? didn't find anything about it...)

Assuming the above is true, your OS should scan the interrupt handlers registered for 0x60 to 0x80 and search for the string "PKT DRVR". Then you'll know which interrupt the driver registered for.

AFAIK Ralph Brown's interrupt list documents standard BIOS service interrupts which have nothing to do with this specific piece of software.

I hope I could help you a bit....as I said, I don't know anything about this packet driver, but that was what I could read in the documentation.

cheers Joe

Thanks for the answer Joe

Ok now, with your words and re-reading the document and the Ralph Brown's interrupt list, i have understood a little more.

Ok, so i have other questions.
I write my OS on my floppy and then boot from it.
In my OS assembly code am i stricted to use only the Bios interrupts?
If it is so, what's the way to send packets via a network card, considering that there is no interrupts for networking?
Do i have to initialize a driver and then use the functions of this driver?

This is my first approach to OS development, and for my teacher too (as he said me). It gave me this exercise maybe, as me do, thinking it would be a, relatively, simple work, but, more i understand of this world, more i understand that is not as easy as we thought.

Let me sorry for questions that could seem ridicolous

Hi Zalantos,

Welcome to the world of OS programming! You're about to embark on an arduous journey...full of self fulfillment.

First, if you code you own OS, you control the interrupts. In otherwords you can choose the ones you want to use, except for the Archetecture's specific owns that are used by default. You can get this from the archetecture books available for that platform. For instance, Barry Brey's The Intel Microprocessors: 8086/8088, 80186, 80286, 80386, 80486, Pentium, Pentium Pro, Pentium II, Pentium III, Pentium 4, Seventh Edition, © 2005, Prentice-Hall, 912p, ISBN: 0-13-119506-9, earlier editions © 2003, © 2000, © 1997, © 1994, © 1991, and © 1987

Second, you can determine on boot up where particular interrupts are located by scanning the IVT (Interrupt Vector Table) at memory address 0.

Third, there are several ways to communicate between two machines. You'll have to narrow down your requirements first and then do a trade to determine if one solution is better than another based on your criteria. A safe solution is one already tried and true with a lot of documentation with explanations, etcetera. Devloping new ways adds the risk of not making your deadlines and perhaps going over budget. You can for instance use USB, parallel ports, serial ports, IDE, SCSI, or simple jumper wires between two machines, this needs to be defined more specifically.

Fourth, plan your approach as much as possible. Do weekly bearing checks to ensure you're still on course. If things change (and they always will) you can make adjustments and continue down a path towards success.

Fifth, download a freely avialable source code for ideas on design. Your particular project is just to communicate between two machines. I would suggest a small DOS type OS, without a lot of overhead, there is no need for graphics, not need for FPU use, etcetera. Basic text display and a way to command each machine to send and receive data between one another.

Sixth, check out the FAQs and the Wiki.

I hope this helps...

Thanks a lot for the big answer.

First, if you code you own OS, you control the interrupts. In otherwords you can choose the ones you want to use, except for the Archetecture's specific owns that are used by default.

Second, you can determine on boot up where particular interrupts are located by scanning the IVT (Interrupt Vector Table) at memory address 0.

But the IVT is not loaded by default, isn't it?. E.g., if i write a small toy OS that write a char on the screen, how can my cpu recognize the instruction "int 13" if IVT it is not initialized? or there is something that i didn't understand?

Fifth, download a freely avialable source code for ideas on design. Your particular project is just to communicate between two machines. I would suggest a small DOS type OS, without a lot of overhead, there is no need for graphics, not need for FPU use, etcetera. Basic text display and a way to command each machine to send and receive data between one another.

I agree with you. I thought too to a OS with only the network function and some basic text displaying.
But being just arrived in this work, i'm yet finding hard where to look in Internet for things in which i'm interested (for instance, like source code of already made OS).

Sixth, check out the FAQs and the Wiki.

Yes, i'm doing this too in the meanwhile. But, like i said first, i find yet difficult what to read and what to discard, and, while preparing this work i have to study for other exams too, so i have to schedule my times and take advantage of the help that a forum could give, too. So, until my questions will become distubing , i wanna integrate them with the reading of the FAQ, Wiki and the other topics of these forum and the other document or books that i find.

Thanks again for your time.

First you will need a ethernet card, that has good doc's (eg: RTL3189 ), then once you have your basic OS done, you need to start writing code for pci scanning to test for vendor and device ID, from there you write a driver for your card and then TCP/IP stack code etc.

I have done all this and your look at least 6 months work.
Your driver can be poll rather than int driven.

PS: MiniDOS may be worth a look at as a basic OS.
http://board.flatassembler.net/topic.php?t=5275&start=0

PPS: This link may also help:
http://www.elet.polimi.it/upload/fornac ... index.html

Zalantos wrote:But the IVT is not loaded by default, isn't it?. E.g., if i write a small toy OS that write a char on the screen, how can my cpu recognize the instruction "int 13" if IVT it is not initialized? or there is something that i didn't understand?

The IVT actually IS loaded before your OS boots. The BIOS initializes it for you. (It needs to, the BIOS needs interrupts to be even able to load your OS into memory) So once your OS is loaded, it can use all the ints the bios provided and the bios will take care of the rest. What you do with the IVT later on, is up to you.

Zalantos wrote:Thanks a lot for the big answer.

You're quite welcome and my pleasure!

Zalantos wrote:But the IVT is not loaded by default, isn't it?. E.g., if i write a small toy OS that write a char on the screen, how can my cpu recognize the instruction "int 13" if IVT it is not initialized? or there is something that i didn't understand?

As wrote, the IVT (I think you may be confusing with IDT) is setup by the Basic Input Output System (BIOS) and there are quite a few basic interrupts you'll need to know in order to use the BIOS. Additionally, you'll want to look up IRQs. You'll want to do this for realmode (I assume this is where you'll work) and perhaps protected mode. Protected mode you will not be able to use all the functionality of BIOS directly and adds a significant amount of overhead to your already steep learning curve.

Zalantos wrote:I agree with you. I thought too to a OS with only the network function and some basic text displaying.
But being just arrived in this work, i'm yet finding hard where to look in Internet for things in which i'm interested (for instance, like source code of already made OS).

I would recommend miniDOS as a start. Then there is FreeDOS, but I don't know where it is.

If you are going to use a specific ethernet card or wire something to the motherboard for that matter, you're going to have to learn how to use ports (essentially the ASM IN and OUT opcodes, which I think you may already know).

Zalantos wrote:Yes, i'm doing this too in the meanwhile. But, like i said first, i find yet difficult what to read and what to discard, and, while preparing this work i have to study for other exams too, so i have to schedule my times and take advantage of the help that a forum could give, too. So, until my questions will become distubing , i wanna integrate them with the reading of the FAQ, Wiki and the other topics of these forum and the other document or books that i find.

Ask away, there are a few folks here who get irritated with people for not looking over the Wiki before asking questions, so be prepared to get lambasted a couple of times. Knowledge required time to ingest and then absorb. Soemtimes we ingest and we don't absorb or we absorb, but discard it along the way. Regardless of where it is it all takes time.

Zalantos wrote:Thanks again for your time.

No problem, glad to give my two cents (lira?) when I can, as are others here.

JoeKayzA wrote:Unfortunately it doesn't tell anything about the environment the driver is expected to run in

It seems to be a collection of DOS drivers for various networking chipsets. As the sources are in assembler there's little point in trying to use it with everything but real-mode. It might however be possible to make the driver free-standing so that it works without DOS running in the background.

Personally I wouldn't use the driver as it's limited to 16 bit mode. There are certainly more modern opern-source drivers that you could use for your system.

Apart from that there are a couple of other things you could do to speed-up your project:

a) Use GRUB as your kernel loader: This saves you from having to deal with the lenghty (and irrelevent) loading process of the x86 architecture.
b) Choose only one network chipset that you'll support. This will still work with most computers as the underlying hardware is often the same.
c) Try to recycle open source-drivers wherever possible. After all it's not your job to implement drivers but to write an operating system.

regards,
gaf

JoeKayzA wrote:Hi!
AFAIK Ralph Brown's interrupt list documents standard BIOS service interrupts which have nothing to do with this specific piece of software.

OT: AFAIK, it's not completly true, it also describes some additional software besid BIOS.

Thanks to all!
You have answered some of my doubt.
Now i have something to work on.