OS Development Series code question

[Andyhhp]

That maths is looking ok to me.

However, if your kernel is coded correctly then a 1K stack should be fine. After the initial setup, all stack is needed for is interrupt handlers.

Having said that, a 22K kernel is rather small and you will need more space than that eventually.

~Andrew

[halofreak1990]

Just to let you guys know, I've finally slaughtered the Floppy disk read problem.
Somehow there was a flaw in the floppy driver, though I've changed so much it'd be impossible to say where.
I added lots of debug output to the floppy commands like SEEK and CALIBRATE, and found out it couldn't find the proper sector.

Now that it works, I'm going to try and see if I can get it to support multiple drives (let it detect which one's where, and adjust the settings automatically), and add the option of writing data to the disk.

EDIT: But now I've broken VirtualPC. Will have to find a way to make it work on both, but I'm glad it works on real hardware like it should.

Also, the dma_reset_flipflop routine is flawed; you only use 0, or 1 as input values, but in the function it returns if the parameter is less than 2.
It should be changed to return if the parameter is equal, or greater than 2

From:

Code: Select all

//! resets flipflop
void dma_reset_flipflop(int dma){

	if (dma < 2) //this is wrong, since this way the rest of the function never executes
		return;

	//! it doesnt matter what is written to this register
	outportb( (dma==0) ? DMA0_CLEARBYTE_FLIPFLOP_REG : DMA1_CLEARBYTE_FLIPFLOP_REG, 0xff);
}

To:

Code: Select all

//! resets flipflop
void dma_reset_flipflop(int dma){

	if (dma >= 2) //this is correct
		return;

	//! it doesnt matter what is written to this register
	outportb( (dma==0) ? DMA0_CLEARBYTE_FLIPFLOP_REG : DMA1_CLEARBYTE_FLIPFLOP_REG, 0xff);
}

Since you need to reset the flipflop for the entire thing to work

[halofreak1990]

In response to a previous post of mine:

Also, I noticed the kernel is loaded at RealMode address 0x3000, and the stack at 0x9000.
Now, a bit of calculating tells me there's roughly 24 KB between those two points in memory.
You told me the stack grows downwards... which means that, with my kernel being 22-23 KB in size, there's about 1KB for the stack before I start running into the kernel's back-end.

I have to say this IS an issue: as of this writing, my kernel is 33KB in size, meaning it spans from 0x3000 (where it has been loaded) to 0xB400
That's roughly 9KB above the stack, which means the stack sits INSIDE the kernel.

Am I correct in my assumption that the Tutorial kernel doesn't change the stack?
If so, either it should, or the second stage bootloader ought to set the stack somewhere else as to prevent instabilities.
Once the tutorial kernel grows enough, Mike will run into trouble, and he will have to overhaul all kernel chapters to include this change.

I've changed the following line in the 2nd stage bootloader, assuming it set the stack for the kernel

Code: Select all

mov	esp, 9000h		; stack begins from 90000h

into

Code: Select all

mov	esp, 9FBFFh		; stack begins from 9FBFFh

not mentioning the error in the originals comments. Perhaps Mike forgot a zero?

[Mike]

Hello,

It is important to note that the bootloader provided by the series was not designed (but sort of can) load 64k+ kernels. We do provide an alternative that can however.

You are correct in that the series' bootloader first loads the kernel to 3k. Thank you for pointing out the potential issue with overwriting the stack. You are correct - the kernel currently does not reposition the stack (which it is recommended to do so).

Once the tutorial kernel grows enough, Mike will run into trouble, and he will have to overhaul all kernel chapters to include this change.

It isnt the first time Still a lot of work however.

[halofreak1990]

I might have discovered a (bug?) in the kybrd.h/.cpp code files.
in the _kkybrd_scancode_std array there were 8 items missing (scancode 0x4a - 0x4f) and scancode 0x47 and 0x49 had the wrong char codes assigned.
I'm using a keyboard with the US layout, in case you were curious.

the old code:

Code: Select all

   KEY_HOME,		//0x47
	KEY_KP_8,		//0x48	//keypad up arrow
	KEY_PAGEUP,		//0x49
	KEY_KP_2,		//0x50	//keypad down arrow
	KEY_KP_3,		//0x51	//keypad page down
	KEY_KP_0,		//0x52	//keypad insert key
	KEY_KP_DECIMAL,	//0x53	//keypad delete key

my fix:

Code: Select all

   KEY_KP_7,		//0x47	//keypad home
	KEY_KP_8,		//0x48	//keypad up arrow
	KEY_KP_9,		//0x49	//keypad page up
	KEY_KP_MINUS,	//0x4a
	KEY_KP_4,		//0x4b
	KEY_KP_5,		//0x4c
	KEY_KP_6,		//0x4d
	KEY_KP_PLUS,	//0x4e
	KEY_KP_1,		//0x4f
	KEY_KP_2,		//0x50	//keypad down arrow
	KEY_KP_3,		//0x51	//keypad page down
	KEY_KP_0,		//0x52	//keypad insert key
	KEY_KP_DECIMAL,	//0x53	//keypad delete key

Also, for some weird reason I haven't figured out yet, the keyboard does not set the ScrollLock and NumLock leds when I press those keys. CapsLock, however, works fine.
At first, I assumed it was because you often have to wait for the input buffer to be cleared--which the kkybrd_set_leds function didn't do--before sending a command, but after changing that, it was still only CapsLock that worked.