   OS Dev Series - Tutorial 13
  Hey everyone,I have finally managed to get around finishing the next tutorial and uploading it.Here it is...Tutorial 13: Kernel: Basic Concepts Part 2This tutorial finishes the Kernel: Basic Concepts subsection with the series. It has alot of topics that we have not gone over yet...no worries. Everything will be explained in later tutorials when needed.I am thinking of using a hybrid microkernel for the series OS. I want our readers to have a good understanding of both microkernels and monolithic kernels, and feel that by integrating them together as a hybrid kernel, it might help our readers experience both worlds.Please let me know if their are any questions, comments, or suggestions :) Also, I plan on adding to this tutorial to add content related to exokernels.In the next tutorial, we will start looking at our own design, and start developing our hardware abstraction layer (HAL) and kernel. This is what is planned, anyway.Also, I apologize for the lateness of this tutorial. Inside of the tutorial explains everything regarding why this series temporarily halted.If you are interested in OS development or the series in general, the following link will take you to the base site:OS Development Series Base SiteThanks for all of the support so far for this series[smile]   
  This series is coming along nicely. This is the first I've heard of it in awhile.   ;  its good someones do this but there are some missing parts.first of all i think for making this tutorial fully meaningfull i think it needs assembly examples or explanations of boot memory and otherher device controll technics/standards.or may be you can write a ide for oop codes of any spesific hardware directly[smile]?for example on some assembly tutorials they explains the boot option of bios just in some lines.;  Thanks for the replies!Quote:This series is coming along nicely. This is the first I've heard of it in awhile.Sorry about that... There was alot of other things that I was working on that took time away from the series. I hope things get smoother again soon [smile]Quote:its good someones do this but there are some missing parts.Thanks![smile]Quote:first of all i think for making this tutorial fully meaningfull i think it needs assembly examples or explanations of boot memoryEverything regarding booting is covered within the Bootloaders part of the series. Tutorial 7 includes a complete software port map table and real mode memory address map.Quote:or may be you can write a ide for oop codes of any spesific hardware directly[smile]?I apologize, I am not quite sure what you are asking here. Can you please elaborate for me? Thanks.Quote:for example on some assembly tutorials they explains the boot option of bios just in some lines.The bootloader tutorials (Both part 1 and 2) is pure assembly. Everything regarding how the BIOS executes the bootloader is discussed in Tutorial 3.   ;  sorry i see allmost anything is there about boot loaders.about other fact. did you planning to add openg.or dma for vga .or vga drivers.for eample on dos just 2 important problems exists.firs memory on dos is limited because dos did not hawe driver or dma correctly for ram.and some things valid for vga too.i hope you can fix that one day on your os.and i think if you add command line which contains 'dir cd del mov etc...' it will be realy a useful operating system for some of peoples.anyway i think you need fat / ntfs and other spesific structure info for reading disc.me to were planning to do similar things and its realy interesting for me.because linux too is not allways open source and it looks good.also making a game on its own os will make it more faster.also linux kernel is open source i think you can use its source or just some lines for some necessary things.hey also there is some necessary boot loader for hdd and cdrom ? flash.? etc. exists. [smile]   ;  Hey,Quote:sorry i see allmost anything is there about boot loaders.No worries[smile]Quote:about other fact. did you planning to add openg.or dma for vga .or vga drivers.Only VGA at the moment as it is the most common and hence more portable. I do not know what systems our readers are using, so need to plan accordingly for portability. Also, VGA can access fairly good resolutions (800x600) to help produce nice graphics.I was thinking about SVGA and VESA...Im still not sure do to portability reasons.Quote:or eample on dos just 2 important problems exists.firs memory on dos is limited because dos did not hawe driver or dma correctly for ram.DOS was a 16bit real mode (rmode) OS, which is what limits the amount of physical memory DOS can address.We are developing a full 32bit protected mode (pmode) OS, which can address up to 4GB of memory.Quote:and i think if you add command line which contains 'dir cd del mov etc...' it will be realy a useful operating system for some of peoples.That is soon to come, but is still a little too complex right now to implement.Quote:anyway i think you need fat / ntfs and other spesific structure info for reading disc.It does--Currently it boots and executes on a FAT12 formatted file structure. Please see the Bootloaders 4 tutorial for details. This tutorial covers parsing the FAT12 filesystem to load and execute the second stage loader. (Which in turn does the same to load the kernel image through FAT12, parsing the PE header info and executing the C++ kernel.)Quote:also making a game on its own os will make it more faster.While this might be true, it might not be true. Because there is absolutely no driver support, it is almost impossible to gain hardware level performance that OpenGL and DirectX provides. Everything must be done through software.Quote:also linux kernel is open source i think you can use its source or just some lines for some necessary things.I rather not.Quote:hey also there is some necessary boot loader for hdd and cdrom ? flash.? etc. exists. [smile]hdd and flash drives are not that hard for providing support for. (Although proper hdd support is different.)The system already works on CD's through floppy emulation. (I personally only use CDs to test the demos in the series and my own system.);  i dont know why 16 bit system cant access to all the system ram .its physically incorrect.i dont know enough info about difference between 16 bit and 32 bit software.but on low level just yoiu are sending to ram a adress of memory and starting to write or read. so if 16bit systems cant send 32 bit data this does not mean its impossible.this just software and i think pretty much with some modifications allmost any 16bit  system can send this message to ram. and chek a 32bit or 64 bit adress.i think this is something like 16bit/or 32bit while loop and kernel programmers simply dont want to bother about it.;Quote:i dont know why 16 bit system cant access to all the system ram It has to do with the 16bit registers and the seg:offset addressing used in real mode, while protected mode software being 32bit, and using linear addressing (descriptor:offset) instead of seg:offset addressing.Each segment register is only 16 bits. This limits the size of a segment to 64KB.  (After all, a 16bit value can only store from 0 to 65,535) If the segment is equal to 65,535, we convert the seg:offset address to its linear address we get: (65535 * 16 = 1,048,560), which is 1MB.Protected mode uses 32bit linear addressing (4bytes), which can store values from 0 to approx. 4,294,967,295; or approx. 4GB.I think I covered protected modes desc:offset addressing somewhere, but cannot seem to find it atm...Quote:i think this is something like 16bit/or 32bit while loop and kernel programmers simply dont want to bother about it.This is the limitation of the real mode processor addressing mode, and the 16bit segment register limitation. (There is no 32bit segment registers, as it is not needed.)...Its only 16bits.The basic idea is that, because segment registers are 16bits in size (2bytes), they can only store the values from 0..65535.Using seg:offset notation, this is 65535:0. Converting this to a linear address is = 1MB, as shown above the quote box.As you may know, because it is limited to a 16bit value, going beyond 65535 will cause problems.   ;  This is probably the best tutorial I ever read about OS development.Got a little question though, I notice all OS devvers seem to use Nasm. Is possible to use Masm for OS dev? Because at school they teach us masm. (Just general courses, nothing on os dev)   ;  Hey,Sorry for the late reply and I thank you for your great response!Quote: Is possible to use Masm for OS dev? Almost any i86 assembler should work as long as the binary image is loaded and executed properly.The bootloader is a special case, as not all assemblers can output binary programs. (It must be a binary image, not a program image.) NASM can do this; I am not sure about TASM nor MASM however.I personally prefer NASM because it provides more options, and nicer syntax over MASM and TASM. It also supports more output formats then MASM and TASM. Also, IIRC MASM cannot output binary images, only 32 PE and COFF images, which will not work for bootloaders.NASM syntax is very simular to MASM (With slight differences.), so it should not be to hard to learn both.Before I leave, I want to wish everyone here a happy new year!![smile]   