On at 2023-05-13 18:09 -0500, rehsd.i...@gmail.com 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
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
