Introducing my kernel.
Introducing my kernel.
I've made a floppy image of my kernel called Dolphin. You can download the image here. I've also attached a screen shot.
Right now it's pretty basic. Personally, I consider it a microkernel although some may question that. I'll post the code if anyone wants it but it really is ugly right now. Save a couple of files, the entire thing is in really badly formatted C. It took me since september although I took about 3 months in-between due to the Google Highly Open Participation Contest.
As of right now, it has a console driver, and a mostly complete vfs layer(but is completely lacking in *real* filesystems). It also has a simple pci server that as of right now will print the installed devices slot and bus number and vendor id. I think the best feature is its console driver which uses VESA! The only mildly interesting thing you can do during runtime is typing.
Oh yeah, BTW, as of right now, it's hard-coded to use 1024x768 32bpp mode so if you're running it on qemu, i would recommend running it fullscreen. Also, if it just freezes that means something had a page fault in graphical mode and as of right now the kernel can't print on a console handled by an external server but i'll fix this soon(this is one reason some people don't consider it a pure microkernel).
As you can see in the screenshot, the corners have been cut off.
Tell me what you think.
*EDIT*
one last thing, the last couple of lines about the VFS is basically the console server registering itself with the VFS layer. In the future, all console io will take place through the VFS. The hello on the last line is what the console server currently returns on read messages. Basically, what is happening is that the vfs(as a simple test) is reading from the console server and then writing it back out. Just thought I'd explain what that is doing there.
Right now it's pretty basic. Personally, I consider it a microkernel although some may question that. I'll post the code if anyone wants it but it really is ugly right now. Save a couple of files, the entire thing is in really badly formatted C. It took me since september although I took about 3 months in-between due to the Google Highly Open Participation Contest.
As of right now, it has a console driver, and a mostly complete vfs layer(but is completely lacking in *real* filesystems). It also has a simple pci server that as of right now will print the installed devices slot and bus number and vendor id. I think the best feature is its console driver which uses VESA! The only mildly interesting thing you can do during runtime is typing.
Oh yeah, BTW, as of right now, it's hard-coded to use 1024x768 32bpp mode so if you're running it on qemu, i would recommend running it fullscreen. Also, if it just freezes that means something had a page fault in graphical mode and as of right now the kernel can't print on a console handled by an external server but i'll fix this soon(this is one reason some people don't consider it a pure microkernel).
As you can see in the screenshot, the corners have been cut off.
Tell me what you think.
*EDIT*
one last thing, the last couple of lines about the VFS is basically the console server registering itself with the VFS layer. In the future, all console io will take place through the VFS. The hello on the last line is what the console server currently returns on read messages. Basically, what is happening is that the vfs(as a simple test) is reading from the console server and then writing it back out. Just thought I'd explain what that is doing there.
- Attachments
-
- Screenshot-QEMU.png (22.94 KiB) Viewed 5829 times
very nice. worked great on VPC2007 here.
if you get around to re-formatting your code, I would deffinately like to look at the source.
if you get around to re-formatting your code, I would deffinately like to look at the source.
Website: https://joscor.com
Cool. That's good news because I've only tested it on qemu, bochs, and real hardware, but not vpc.
I'll try and get the code in a distributable state by tomorrow. The problem is I have a lot of manuals and other stuff in my source folder that I'll have to get rid of. I still need to get it into some sort of version control.
I'll try and get the code in a distributable state by tomorrow. The problem is I have a lot of manuals and other stuff in my source folder that I'll have to get rid of. I still need to get it into some sort of version control.
Partly cleaned up sources. Don't scream at me for their really bad style. I'm still working on most of the main kernel files and all the server code.
I'm not too sure if the version I've attached will compile or not. The makefile also creates an image but the hard disk image I use is 10 MB which is too big to have included. However, all the source files are there. To try to compile it, run DolphinBuild first and then enter i386 as the architecture and press enter then type make. Hopefully you'll get a file named dolphin and dolphin.pod and something in boot/ called dolphin_wake. Dolphin_wake is the kernel as used by grub and dolphin.pod should be loaded as a module.
Now for source organization.
boot/ contains the 1st stage loader which is specific to each platform. It sets up paging and loads the 2nd stage which is contained in an archive(more on that later).
pod/ contains a simple archive utility which is basically used to keep things cross platform as grub is specific to i386. By loading only one module which is an archive, all I have to do is contain platform-specific code for loading one file from disk. The archiver also aligns everything on page boundaries to greatly simplify loading and make some guarantees that the multiboot specification does not(although I still assume some things in the kernel).
src/ is the most complex. generic/ and i386/ contain the generic kernel files and the i386 platform specific files respectively. Include/ obviously contains include files. servers/ contains code for all the four servers: init, console, vfs, and pci. klibc/ is a simple static library which provides low-level access to the system call and interface(and a high level hash-table, heap, thread implementation, pod archive support, and console support). The code is pretty simple. If you have any questions just ask.
Last thing, I know that ipc is a bit complex but I'm working on it.
You can find the source here.
I'm not too sure if the version I've attached will compile or not. The makefile also creates an image but the hard disk image I use is 10 MB which is too big to have included. However, all the source files are there. To try to compile it, run DolphinBuild first and then enter i386 as the architecture and press enter then type make. Hopefully you'll get a file named dolphin and dolphin.pod and something in boot/ called dolphin_wake. Dolphin_wake is the kernel as used by grub and dolphin.pod should be loaded as a module.
Now for source organization.
boot/ contains the 1st stage loader which is specific to each platform. It sets up paging and loads the 2nd stage which is contained in an archive(more on that later).
pod/ contains a simple archive utility which is basically used to keep things cross platform as grub is specific to i386. By loading only one module which is an archive, all I have to do is contain platform-specific code for loading one file from disk. The archiver also aligns everything on page boundaries to greatly simplify loading and make some guarantees that the multiboot specification does not(although I still assume some things in the kernel).
src/ is the most complex. generic/ and i386/ contain the generic kernel files and the i386 platform specific files respectively. Include/ obviously contains include files. servers/ contains code for all the four servers: init, console, vfs, and pci. klibc/ is a simple static library which provides low-level access to the system call and interface(and a high level hash-table, heap, thread implementation, pod archive support, and console support). The code is pretty simple. If you have any questions just ask.
Last thing, I know that ipc is a bit complex but I'm working on it.
You can find the source here.
Yes you do need to pass -std-vga for qemu to "Simulate a standard VGA card with Bochs VBE extensions (default is Cirrus Logic GD5446 PCI VGA). If your guest OS supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if you want to use high resolution modes (>= 1280x1024x16) then you should use this option."
If you don't qemu can't handle the resolution. That's qemu's problem though. It should work right out of box in bochs(No pun intended).
If you don't qemu can't handle the resolution. That's qemu's problem though. It should work right out of box in bochs(No pun intended).
I'm pretty new to VESA. I tried to implement it myself.
Anyway, here's my process(All interrupts are run in vm8086 mode):
1. call int 0x10 with al=0x4f00
2. find the modes array
3. go through each mode calling int 0x10 with al =0x4f01,ecx=mode
4. If the x, y, and bpp are not what i want, go to step 3
5. call int 0x10 with al=0x4f02, bx=0x4000|mode
6. map the linear frame buffer.
7. start drawing.
is this right?
Right now, i don't do any error checking, I just assume everything works.
Anyway, here's my process(All interrupts are run in vm8086 mode):
1. call int 0x10 with al=0x4f00
2. find the modes array
3. go through each mode calling int 0x10 with al =0x4f01,ecx=mode
4. If the x, y, and bpp are not what i want, go to step 3
5. call int 0x10 with al=0x4f02, bx=0x4000|mode
6. map the linear frame buffer.
7. start drawing.
is this right?
Right now, i don't do any error checking, I just assume everything works.
-
- Member
- Posts: 391
- Joined: Wed Jul 25, 2007 8:45 am
- Libera.chat IRC: aejsmith
- Location: London, UK
- Contact:
Are you setting di to the location of a vbe_info struct, with the signature set to "VBE2"? If not, try doing that.iammisc wrote:1. call int 0x10 with al=0x4f00
(If that doesn't make sense, look at this - line 239 in vbe_detect)
Kernel works, but backspace doesn't and the floppy motor doesn't switch off. Anyways I try to type HELP, HELLO, SHUTDOWN and nothing. Is that all?
My web site: http://inflater.wz.cz (Slovak)
Derrick operating system: http://derrick.xf.cz (Slovak and English )
Derrick operating system: http://derrick.xf.cz (Slovak and English )
Re: Introducing my kernel.
Sry for bumping; but it works on VirtualBox OSE.
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)