The Place to Start for Operating System Developers
http://f.osdev.org/
It's possible, but I think it would be easier to write a USB driver.pranavappu007 wrote:Can I use interrupts with preserving the BIOS ones for using in real mode?
Yeah, but instead of reporting an error in your interpreter it crashes your whole system. Also, how do you plan on implementing delays, preemption or wallclock without interrupts? Even in a monotasking system with busy loop delays you'll need a wallclock (a way to measure time regardless what code is running).pranavappu007 wrote:Now my question is: Is not implementing interrupts bad?It works without the interrupts
Probably not. However you should care about correctness and stability, even in a "not so serious" project.pranavappu007 wrote:I don't know if I should care about efficiency as this is not a serious project at all
Yes. Make sure you don't mess up the first physical page in RAM (0x0 - 0x1000 IVT and BDA), and the EBDA area (usually somewhere 0x9?000 - 0xA0000). Then set up your IDT whereever you like. Before you switch back to real mode to access BIOS, load an idt value of (offset 0, length 0x3ff), do the BIOS stuff, and when returning, restore IDT.pranavappu007 wrote:Also, as I needed the BIOS routines, Can I use interrupts with preserving the BIOS ones for using in real mode?
If I were you, I would do some PoCs to get myself familiar with interrupts, and when it is working fine, only then would I add it to the current kernel. BTW this is a good approach for all features, not just for interrupts.pranavappu007 wrote:I can try setting up some interrupts to learn about the interrupts as another project, but should I redesign the kernel to work in the standard manner and implement interrupts in this one? This question may sound a bit odd, if so please forgive me.
Not in a thousand years. Switching to real mode, do an int, return to prot/longmode is a LOT easier than parsing PCI bus (to find the root hub), and write native device drivers for hubs and storage as well. But it is unavoidable for a stable system, that's true, just not easierOctocontrabass wrote:It's possible, but I think it would be easier to write a USB driver.
Congratulations, I think you are already quite far in your OS development. (Well it dpeends with which OS you compare itpranavappu007 wrote:Hello, I am making a Boot loader and a kernel(sort of) using assembly and C. I used a tutorial for the basics like GDT, address bus, segmentation etc. but the rest of it(almost entirety of my kernel) was just my own random ideas glued together. As of now I can use keyboard, print a prompt that looks nice(for me), a somewhat usable text editor, and some other lazy commands like list "files", CAT, show time,etc. and an 'interpreter' that will crash the entire system if I miss-typed one letter in my 'Programming language'
.
)It's easier until it isn't. The more hardware you touch, the more things you must reset to the BIOS default before you can call the BIOS. And this assumes you know what the BIOS default is: it will vary from one computer to the next, and if you make a mistake your BIOS call may crash or hang forever.bzt wrote:Switching to real mode, do an int, return to prot/longmode is a LOT easier than parsing PCI bus (to find the root hub), and write native device drivers for hubs and storage as well.
I frankly don't think I'll ever write or be able to write a USB driver.iansjack wrote:Redesign your OS now before it gets too advanced. I'd strongly suggest avoiding the BIOS too. You don't need USB right now - run your OS in a VM until you are ready to write a USB driver.
With my current stage or even with my end goal, This is faaar better than a USB(I don't even understand USB, I triedOctocontrabass wrote:It's possible, but I think it would be easier to write a USB driver.
)
Actually, the interpreter crashes due to not implementing error-checking yet. My usual method is to check errors rather than catch errors. Not efficient maybe, but it'll do. Preemption is not possible in interrupting the kernel, but I think I can make the interpreter stop what it's doing, save variable spaces and set up a way to resume it later. Maybe not in the most efficient way, or maybe not even doable, but that's the current plan. As for delays, I can poll RTC for larger delays, and loops for smaller ones I think.bzt wrote:Yeah, but instead of reporting an error in your interpreter it crashes your whole system. Also, how do you plan on implementing delays, preemption or wallclock without interrupts? Even in a monotasking system with busy loop delays you'll need a wallclock
Thanks! That was one of my major concern, not being able to use BIOS.bzt wrote:Yes. Make sure you don't mess up the first physical page in RAM (0x0 - 0x1000 IVT and BDA), and the EBDA area (usually somewhere 0x9?000 - 0xA0000). Then set up your IDT whereever you like. Before you switch back to real mode to access BIOS, load an idt value of (offset 0, length 0x3ff), do the BIOS stuff, and when returning, restore IDT.
I don't think I ever willPeterX wrote:And how are you gonna build a complete OS with multitasking and timers and devices
I don't know, I find it hard. Or is it not as hard as I think? Can you give the details on that?PeterX wrote:USB iansjack gave a good advice
About virtual machines: On Linux you have Qemu (which I recommend), Bochs, VirtualBox. Search this site's wiki and/or the internet how to use the VM.iansjack wrote:You don't need USB right now - run your OS in a VM until you are ready to write a USB driver.
I use linux and have qemu installed. I first test on qemu, which is easy as it will tolerate simple errors. If it does, I will restart and test on my actual hardware, find any bugs. It was all going well until I tested it on an older hardware which lead to my other post here regarding BIOS freeze. Fixed it though, It's working now.PeterX wrote: On which OS do you develop your OS? Windows? Linux? Which Linux distribution?
What you mean by "traditional" way? Using interrupts are pretty traditional, even 8086 had them. They were in heavy use by TSRs under MSDOS too 40 years ago.pranavappu007 wrote:Is implementing features using interrupts harder than traditional way?
Hah, let me see. You don't need ACPI for interrupts. You don't need ACPI for multicore SMP (but you'll need to parse some ACPI tables to get the address of the LAPIC/IOAPIC, but for a VM, you could hardwire those addesses, they won't change).pranavappu007 wrote:I don't know if I could've done this much because I didn't go too complicated and kept the general structure of kernel like that of a simple program. Also, if I'm going to use interrupts, should I consider switching to ACPI mode or something to get control of all threads in CPU? Is it even possible without going too complex?
What simple guide do you mean? The wiki has all the information you need. Setting up IDT is simple as one instruction, lidt. That has one parameter, IDT_value, which contains another pointer and a size to describe an array. Filling up an array (just like with any other arrays) can be done statically or dynamically, your choice. For static, you'll need something likepranavappu007 wrote:Also,most guides regarding IDT and and PIC are done in C using inline assembly, but frankly at that level I prefer direct assembly(intel). Could anyone help for a simple guide to implement the subroutines and IDT structures in something like nasm?
Code: Select all
lidt [idt_point]
...
idt_point:
dw idt_end - idt_start - 1
dd idt_start
...
idt_start:
irq0:
dw isr0
dw 0x0008
db 0x00
db 10101110b
dw 0x0000
irq1:
dw isr1
dw 0x0008
db 0x00
db 10101110b
dw 0x0000
irq2:
dw isr2
dw 0x0008
db 0x00
db 10101110b
dw 0x0000
...lot more of these records.