download source code, PXE binary, floppy binary, CD-ROM binary

making it modular

2009-03-06 02:04:00, dustwolf

Kohlrak wanted to have the option to compile the kernel code as something simpler, with text mode, for easier debugging. Seeing this as a chance to ensure that the kernel source code really is usable for other projects, I have been working on optimizing the code structure so that it can be modded this way.

The code you can download now contains what you need to assemble a version of the kernel that displays output in text mode. To see this in bochs, just type "make debug". The file "textmodedebug.iso" is the CDROM ISO image that boots the text mode kernel. It does not contain any mouse code so it will run on machines without a PS/2 mouse as well.

textmode screenshot

The interesting part here was being able to make the text mode kernel run basically the same code as the VESA graphics one, displays the same text, etc, but with a few different includes. We are still working on this modularity, Kohlrak has a solution for the IDT and GDT and in general making the kernel highly configurable. He has a working prototype of the code. I actually have to wait for him to install the improvements into the source code before I can continue.

So there is much to do and much to discuss... which makes the whole thing very interesting right now.

Stay tuned.


2009-01-31 01:05:00, dustwolf

I updated the website a little... made an esthetic fix as well as added those (+X -Y) in the changelog on the right. In case you are not familiar with them, they indicate the number of lines removed or added in the code, and if a line is just changed, it is both removed and added.

As is clearly visible, we have not been making any drastic changes to the kernel recently. This is partially because our kernel is so cool that even when we need to change something, we only have to change something like four instructions (I'm kidding of course)... and partially because we've been lazy lately. Well maybe lazy is not the right word, remember even programmers can only work on something as much as life (yes, life... I have one) allows. I've been dedicating a lot of my free time for another project (and getting over being ill) and Kohlrak's been kept bussy with school... although as you can see this didn't actually stop him poking at the kernel for random optimizations. We do in fact, care about keeping this project alive and giving you something interesting to read.

Otherwise, everything seems to be working fine and it is time for me to start thinking about a plug-in system for the kernel. That is, most kernels out there detect devices on each boot, which is what the waiting is all about, we have decided against this approach, favoring a much more intelligent approach of only detecting devices while the kernel is being installed. The idea is that eventually, we would create an interactive program to let people pick what they want in the kernel, but for the time being enable support for this by making the kernel in modules that can either be included or simply not. This is already being done, since using this approach you can take the same kernel and pick the boot method by including the right files ("pxe.asm" for PXE, "mbr.asm" for Floppy or "eltorito.asm" for CDROM), as well as all the other components like "mouse.asm", "pcspeaker.asm" and so on. The real challenge however will now be to make the kernel support either PS/2 mouse or Touchpad depending on what file is included. Shouldn't be too hard but I haven't gotten started yet.

On the brigt side, Kohlrak has been working on a project that uses code from this kernel. That in itself is a fine example of what I wanted this kernel to be good for in the end. It's code that works and you can pick the files you like and use them in your own projects. I would like to think that the documentation is sufficient, though you can always ask us (see source code for contact info). :)

Working on the kernel is fun so I hope to manage to schedule some more time to work on it.

I guess he really can count...

2009-01-31 00:46:00, Kohlrak

As most of you don't know, in my humble little town of Lewistown, where I reside, there teaches a very, uuuuuuhhh, by the book teacher. Whenever a debate between a student and the book arrives, he almost always sided with the book first. Well, until one day, about a year ago, my Junior year of Highschool. Me and two other students were taking the Advanced Placement Computer Science A course, which was simply a not so in-depth course into Java. Well, we were studying either recursion or step loops, I honestly can't remember since both were an equally old, dry topic for all three of us, but there was some other lesson we were supposed to learn about debugging code the hard way by executing it in our heads. I think there was a fancy name for it, but any attempt to remember it is futile.

It wasn't long before we started to argue with the book on an individual iteration of the loop (or recursive routine), which was "irrelevant," since the end solution was the same anyway. The details of the algorithem and starting values elude my memory, however, the argument hasn't. This particular iteration involved a division of 10 by the number 2. Now, one would imagin that this is simple math, right? Wrong. Upon arguing that 10/2 is 5, not 8 like the teacher edition says, we ended up arguing for half an hour. Eventually, he realized that he was saying 10/2 is 8, and that this is not a true statement. But, he waited to realize that after becomming angry with us for "wasting class time."

Now, less than a week ago, my mind started to wander as we were doing reviews in the Visual Basic 2 (part 2, not version 2) Course, as this was for people who hadn't taken part one in over a year (the district just approved, this year, the teaching of the second half of the book, which informs everyone alot about how technologically advanced my district is). Some of us were also picking on him, again, for his mathematical mistake, and also having our usual talk about hex and assembly verses high level languages. Well, I got to thinking, "What is 10h/2?" To test my theory (as I've come to the inevitable conclusion upon conceiving this idea) I checked my math in Hex mode of the windows calculator (the school district is also very MS friendly), and realized that the book wasn't wrong in saying the result is 8, but wrong in that it did not append an "h" to the original number. Since this wasn't a class that used hex more than chapter one, where it told us that such a notation exists and that magic is needed to use it in Java, hex was the last thing on our four simple minds.

Perhaps we may finally stop picking on our poor computer teacher (who, might I add, is one of those HLL advocates who knows very, very little about assembly, not to mention he was one of those teachers that just happened to be available when computers started to be taught in the district, which was when they took ANYONE who was willing to try it). Or, at least we'll stop picking on him for his mathematical ability, since his age and a few other things are still fair game.


2008-12-30 03:28:00, dustwolf

I was continuing work on the mouse, which was interesting due to being the first device with an IRQ I implemented support for. I worked on general code cleanup as well, split out the old keyboard code, etc.

A Bochs screenshot for your amusement:

It actually works fine on an actual machine as well, though it only supports PS/2 mice (and not say, touchpads, unfortunately for Kohlrak). Work on this was actually somewhat more fun than frustrating, I only gave up twice durring development. IBM manuals saved me here, they're great albeit written in inverse logic: To understand the basics, you have to read the footnotes and vice-versa. I'm guessing this is a classic case of a manual written for those who already know everything and don't need a manual.

As usual there were other docs around, but if you actually read what the IBM docs say some of the stuff was extremelly silly. Can't blame people for not knowing what they're doing I guess, as they prolly reverse-engineered the whole thing from a Linux (which has a big ugly 50 page code hierarchy on mice as usual) or something, but I feel it strange that nobody cared to consider that PS/2 was an IBM thing! Poor IBM.

Rearanged the code so that the debugging macros could be used anywhere. Cursing self for making code look like C with codeless header includes (macro includes), but at least it's still tidy (unlike C). Threw out fancy16, because the kernel boots to graphics mode too fast for you to see it anyway. Renamed some files to keep some sense in filenames. Take a look.

Older >>

2013-03-03 16:14:08, Jure Sah

webpage fixes

makefile (M)

2013-02-17 14:19:39, Jure Sah

debug bochs hacks and requirements

INSTALL (M)  debug.bochs (M)

2013-02-17 14:07:03, Jure Sah

ubuntu 12.04 compatibility

bochsrc (M)  makefile (M)

2012-10-27 13:00:31, Shane Tyler "Kohlrak" Yorks

Commented out the mouse (due to hang) and cleaned up the makefile, a well as fixing a bug introduced with the AVX instructions being added to FASM.

bochsrc (M)  cdrom.asm (M)  debug.bochs (M)  eltorito.asm (M)  end.asm (M)  fancy32.asm (M)  floppy.asm (M)  main.asm (M)  makefile (M)  mbr.asm (M)  pxe.asm (M)

2012-10-26 22:28:35, jure sah

mess cleanup

2009-08-11 21:59:21, convert-repo

update tags

.hgtags (A)

2008-06-23 01:03:30, dustwolf

dustwolf smoke microkernel start

2009-03-06 03:00:37, dustwolf

copyright data update

VESAflip.asm (M)  cdrom.asm (M)  floppy.asm (M)  keyboard.asm (M)  main.asm (M)  makefile (M)  mouse.asm (M)  textDebugger32.asm (M)  textResolution.asm (M)  textmodedebug.asm (M)  transition32.asm (M)

2009-03-06 02:37:59, dustwolf

fixed hex output

textDebugger32.asm (M)

2009-03-06 02:30:56, dustwolf

text mode macros now work perfectly (I think?)

textDebugger32.asm (M)  textmode.asm (M)

2009-03-06 01:59:06, dustwolf

writing up on actual text mode output

textDebugger32.asm (M)  textResolution.asm (M)  textmode.asm (M)