OS development - 16/I 0.0.3

[Auxilium]

I know it was a bad idea making the I lowercase, going to change that.

Yeah, I know, the name is not longer 32/I but now is 16/I, sorry about that.
I realized this is my very first hobby operating system, and I wanted to keep it as simple as possible, and I realized that there was no need for 32 bit. For simplicity sake, and for the ease of programming, and since it is my first hobby OS, I just felt I wanted to be able to complete something than give up on something more complex. I'm positive i'm not going to need more than the 64k real mode limit, considering my 2nd stage loader + kernel is only 2kb large so far, and over 70% of that comes from the strings, because I love my strings.

Either way, I worked 12 hours today, rewrote everything from scratch.

So far it has: 2nd stage boot loader where it will do diagnostics or whatever, then the kernel which has an extremely basic CLI with 3 supported commands. Help, about and reg, which dumps the register contents.

So far I also made a Binary to ascii, hex to ascii, and decimal to ascii, and boy, the hex to ascii was a pain to implement, then I realized I made a simple error

Here is a GIF, over 1 minute long

[radnomguywfq3]

Looks like you're coming along quite well. Nice to know someone else here is into kernel development. You may want to look into to digital electronics as well (I know that is was through low-level programming that I got interested into electronics.)

Anyway, are you testing your algorithms inside of the virtual machine? I always found that debugging the logic inside of i.e visual studios and then reimplementing it into the kernel really increased development times, since the debugging environment your virtual machine has to offer isn't much compared to what visual studios has to offer.

You could also consider using qemu which has a (primitive but probably sufficient) debugger until you establish some sort of interface for a more advanced kernel debugger.

[Auxilium]

Looks like you're coming along quite well. Nice to know someone else here is into kernel development. You may want to look into to digital electronics as well (I know that is was through low-level programming that I got interested into electronics.)

Anyway, are you testing your algorithms inside of the virtual machine? I always found that debugging the logic inside of i.e visual studios and then reimplementing it into the kernel really increased development times, since the debugging environment your virtual machine has to offer isn't much compared to what visual studios has to offer.

You could also consider using qemu which has a (primitive but probably sufficient) debugger until you establish some sort of interface for a more advanced kernel debugger.

I mostly use bochs for testing, which I find is pretty nice.
I've checked out qemu but never actually installed it.

I only use virtual PC when I want to see the OS after I know everything should be working fine, because I think Virtual PC is superior to bochs when trying to give a genuine computer feel, though bochs is for the debugging.

I'm going to rewrite most of the command line interface and the commands because I just whipped something together as a demo of sorts, and the code is horribly messy and rushed. As for now, I'm just working on the actual system itself

[Auxilium]

Update:

Done working for today. 16/I is now version 0.0.4 with a working exception handler! I made a suicide command just to test if my exception handler works, and it does All it does divide 0 by 0 and since the IVT now holds a pointer to my code, it will execute the death screen instead of just halt the machine.

The death screen right now just dumps registers and says what exception happened.

[Margherita]

Damn, good luck with this shit, you're doing good.