OS Coding philosophy

[pini]

If I got a kernel, that should work correctly but does only on some machines and not on other (problem couldn't be found out), what should be my philosophy ? Continuing the developement or waiting until the current kernel works over all the machines ?

[richie]

For example if you use a special command or mode (like protected mode) the kernel won't run on computers older than 386s (286 supports something between real protected mode and real-mode). If you plan that your kernel should run on processors higher than 386 it is ok if you don't care of old machines. But if your code works on a Pentium1 90Mhz without crashing the computer but it doesn't work on a Pentium2 266Mhz you should try to find the bug. In this case it is really a bug and not a requirement your OS has. And if your kernel has a bug it is better to search for this bug in 10000 lines of code instead of ignoring the bug and then try to find it in 1000000 lines of code. The smaller your Program/OS is the easier it is to find a bug.
Sometimes it is easier to rewrite the whole program/OS (if it isn't to big) and use your experience that you get from the first version than finding a bug in for example a unstructured code.

[pini]

okay, I see what's you're POV. My kernel is not big at all, so I think you're right when you say that I should re-write it entirely. Note that my kernel works on a P166 & on a 386 but not on P90 & on a PIII667, so I can't be absolutely sure that there's a bug, it may come from some "exotic" hardware, I don't know. I should make more test on more machines...

[pskyboy]

Thats sounds like a BUG to me. What are the exact problems you are getting and what have you done with your kernel so far. The thing that pops to mind without knowing any more details is memory how much memory is on the machines.

Peter

[pini]

I have a kernel with GDT,IDT, PIC programming, Text driver & Keyboard handler.

The machines where it works :
P166, 32 Mo RAM
386, 2 Mo RAM

The machine where it doens't work :
P90, 24 Mo RAM
PIII667, 128 Mo RAM

[jrfritz]

You should read info on how how the newer processors work differently than the old ones.

[pini]

This could explain why it doesn't work on the Pentium III, but not why there's a problem on the Pentium 90 (especially when considering that it works on a Pentium 166, which is from the same processor class)

[pskyboy]

Unless you post the code we cannot help you anymore then giving you ideas from idle speculation.

Peter

[Curufir]

Don't assume it's something to do with the processor. It could be a BIOS interrupt issue, or your setting of the A20 line, or a number of other things.

Are they all using the same motherboard? Because that's where I'd start my search.

It would be much handier if you could flesh out the details a bit. It doesn't work isn't a particularily useful summary. What doesn't work? Does it reboot? Is the text just not appearing?

[pini]

[attachment deleted by admin]

[pskyboy]

The extra 4Kb sounds right to me. No doubt your linker script aligns code to pages and so basically when you include mem.c it causes it to be bigger then 4Kb so it aligns it to the next page so it will be say 9Kb.

Peter

[pini]

Okay , and what about my memory probing function ? Is it okay ?

Please check my other thread : http://www.mega-tokyo.com/forum/index.php?board=1;action=display;threadid=2522 where I explain what I found out about a int 15h function

[pskyboy]

Okay so you are starting at 1Mb and counting up by 1Kb at a time. So why do you set memcount to 1023 surely that should be set to 1mb so 0x100000.

Other then that it looks like it should work to me. If not you could always try mine which is here:-

Code: Select all

   //Print a Message to let the Developer/User know we are checking the memory
    kprintf("Checking Memory", 3);
    
    UINT* pStartMem = (UINT*)0x1FFFFC;    //Start at top of 1mb (2mb - 4bytes) as we already know we must have 1mb
    const UINT uiMBOfMem = 0x100000;      //Amount of bytes to make up 1mb, define as const as this doesn't change
    
    const UINT uiTestDWORD = 0x506E6978;  //Test DWORD to write = Pnix, for Phoenix, define as const for speed up
    UINT uiTotalMemory = 0x100000;        //We know we have 1mb already
     
    //Write to the Highest DWORD in each megabyte to test for amount of memory available
    do
    {
        //Calculate next memory address    
        pStartMem = (UINT*)(uiMBOfMem + (UINT)pStartMem);
        
        //Write the test DWORD to top of this 1Mb of Memory
        *pStartMem = uiTestDWORD;
        
        //Calculate the Amount of Physical Memory now available 
        uiTotalMemory += uiMBOfMem;
        
    }while(uiTestDWORD == *pStartMem);
    
    //Store the result from the memory test in the Total Amount of Pages
    //Shift amount of mem left by 12 to give amount of pages
    uiTotalPages = uiTotalMemory >> 12;

[pini]

My function gives the amount of KB of memory installed in the system, that's why I begin with 1023 (first Meg). I don't use 1024 because of my while() struct : I have my memcount++ before my test.

Your function avoids this by using a do...while structure, but both functions works as well (I made tests with differents configs with bochs).

BTW, thanks for your help

[pini]

Ok, I fixed that there is a problem, probably located in my bootloader, with the BIOS floppy read function.
It seems that the loader is able to read more than a track at a time (currently 50 sectors) but not with AMIBIOS.

This may explain all the troubles I had last days...