Re: [Freedos-devel] stack setup in BIOS, prior to loading FreeDOS

[C. M. <pu...@ul...>]

On at 2023-05-13 18:09 -0500, reh...@gm... wrote:
> I am working to get FreeDOS running on my 286 system. As part of this, I am
> trying to improve my BIOS code. As I look at the stack setup when the system
> initializes, I am using the following.
> 
> 	; org 0x0000
> 	xor		ax,	ax
> 	mov		ds, 	ax
> 	mov		bp, 	0x8000
> 	mov		ss,	ax
> 	mov		sp,	bp
> 	mov		ax, 	0xf000				; ROM data
> 	mov		es,	ax
> 
> Based on https://en.wikibooks.org/wiki/X86_Assembly/Bootloaders and
> https://github.com/kaneton/appendix-bios (and as I understand it), 0x8000 is
> used for bp and sp upon system initialization. I expect FreeDOS changes the
> location of the stack multiple times during boot as the boot sector is
> loaded/moved and as the kernel is loaded.
> 
> Am I OK with the stack setup I am using prior to loading FreeDOS, or should
> I consider a different/better approach?

Assuming 512 Bytes per sector, your choice of 0:8000h for ss:sp is 
sufficient to allow the initial boot sector loader entry to utilise 512 
Bytes of stack space (linear 7E00h to 8000h). This is fine. However, in 
my bootloadable debugger I chose to use 0:7C00h for loading a sector 
(MBR or partition boot sector) instead, which gives a much larger stack 
[1]. For its BOOT PROTOCOL CHAIN command I use some common loader code 
which happens to set ss:sp to 0:7BF0h (sp = 7C00h minus 10h) by default [2].

You're correct that DOS loaders and kernels will relocate the stack 
several times. Therefore it really doesn't matter much what default 
stack you set up before you run the loader, it just shouldn't collide 
with any memory that is in use (IVT, BDA, EBDA if any, boot sector 
itself, video memory, ROMs).

Here's where FreeDOS's kernel sets up a new stack early on: [3]

And here, as an example, the FAT12/FAT16 boot sector loader also sets up 
its own stack early on: [4]  This sets up the stack as 1FE0h:7BA0h, 
after relocating the loader itself to that position to make space for 
the kernel file data.

One more note: You should always set ss in the instruction immediately 
before the one that sets sp. You're already doing that here. It is 
important to keep in mind if you edit your sources, however. This is 
because writing only ss will generally lock out interrupts until after 
the next instruction has run, to allow atomic changes of the current stack.

Regards,
ecm


[1]: https://hg.pushbx.org/ecm/ldebug/file/861707b9adc5/source/boot.asm#l789
[2]: 
https://hg.pushbx.org/ecm/ldebug/file/861707b9adc5/source/boot.asm#l2529
[3]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/kernel.asm#L220
[4]: 
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/boot/boot.asm#L183