Latest version: 0.04
You are not logged in.
I am planning to include it in the next release, but for it to actually be usefull I would aslo have to include full FAT12 and user program support.
So maybe all this comes in the next version, and maybe not.
Problably it will just be able to read any sector and then display it on the screen as ASCII or hex.
I also have alot of things to sort out with interfaces for devices, drivers and programs.
/ Christoffer
Offline
This sparks some questions in my own mind as I write my own code. I am currently working out the details to go to protected mode. I have initiated flat-real in order to probe memory and do few minor OS initializations. I want to be able to install and uninstall device drivers at will. This leads to a chicken before the egg syndrome, I think, if I am not over analyzing it. I need device drivers for video (text mode mainly, at this stage) and the keyboard. I would prefer not to have them integrated into my main kernel, but currently they are. I also want to incorperate file access for FAT filesystems. BTW, I haven't yet implemented a memory manager either, so I realize this needs to come first. So, is it feasible to, or has anyone done this, have a device manager that loads (default) device drivers after one has already gone into protected mode? To me this means having a low level floppy controller driver already, which I'm trying to avoid being a part of the kernel. I suppose I could use flat-real mode (I've only experimented with probing memory (works quite nicely on my test machines)) and use the BIOS to call the disk access routines. But is that a dorky way to implement it (read unprofessional, or wierd)?
I'd be interested your thoughts.
Offline
Well, to keep the kernel neat I will have to fix interfaces for devices and drivers soon. But the chicken&egg syndrome makes it hard to have drivers as separate files if you don't have any way of loading 'em.. 
I guess that I would have to include some standard drivers into the kernel for it to function, or I could write a better bootloader (with second stage loading), which would make it possible to load more then one file (basic drivers) before calling the kernel.
AS for MM, I haven't got into any position where I needed it. 
I will problably wait with that until I can load and run user programs.
The best solution to all of this (as far as I can see right now) is to:
a) Write a bigger and better bootloader which saves all BIOS data you need (MM map, VESA info etc), loads the basic drivers and the kernel, then jumping to the kernel.
b) Use GRUB..
c) Start the kernel in 16-bit/unreal mode for the initiation and then switch to 32-bit before starting the shell/doing other things..
I wouldn't recommend you to stay in unreal mode becasue of the beloved BIOS ints.. 
Yeah, that would be unprofessional..
/ Christoffer
Offline
BTW: With option c) on my list you can quite easy switch between 16- and 32-bit in the kernel when you feel like cheating with BIOS ints.
Dex4u does this in DEX, a switch to 16-bit, change video mode, and back to 32-bit.. And it's not even slow..
/ Christoffer
Offline
Well, selection a) is a possibility, since currently I am doing what you're doing, within my kernel, all the setup stuff (not reuseable code either, one time use). My boot loader loads the kernel from FAT12 floppy, and I suspect I can just as easily change that to a boot loader, then load the kernel. I'll ponder this some more...
b) Grub, isn't that a worm of some type? 
Seriously, that would also mean redesigning the current path I've already gone down, and I want to avoid that if possible.
I think I will probably run with option c) since this seems to be the easiest to implement in my current stage of development. I'm about to implement my Memory Manager just after I test memory mapping (nearly done) in the next couple of weeks.
Thanks for your insight. 
Offline
No problem.
Offline
I didn't mean it like that. I plan to support GRUB.. But it isn't as fun as doing it yourself...
Offline
crc wrote:
b) Use GRUB.. sad
GRUB isn't that bad. It can actually save a lot of headaches 8)
I don't mean to put it down either...
As bubach points out, I like the intellectual stimulation of knowing how to do it myself. Even if I do it in an unprofessional (less engineering savy) way.
Offline
Dex4u kernel is loaded by bootprog ( which is a bootloader, that loads a exe or com file from floppy), i am planing on making my own ver, which will have a menu to load CLI or GUI, there will also be other option, all this will be done in realmode before moving to pmode.
Offline
The floppy code I got from Dex4u is now almost intergrated into BOS.. :-)
Offline
Pages: 1
