Re: [Freedos-devel] I want my 10K
>> But mostly, I think it would look really cool to have all Zeros in >> the Conventional Memory Column. > I think this would be an exercise in futility. After all, there are > parts of the kernel, which are the first part of (Free)DOS being > loaded (by the boot code in the MBR) and then are being used to put > in place any further drivers, etc, including any memory manager. I > am not so sure that this part "could" be in fact moved up in higher > memory (and thus no longer accessible in Real Mode) without opening > up not just a can but a whole 55gal drum of worms... Ralf is correct. There are just some parts of DOS that must be below the 640k barrier, particularly if you want to remain compatible with older hardware (8088/80286 CPUs) and older programs. There are a lot of complicated "games" that go on in the background to get some parts of some programs above 640k or into Expanded or Extended Memory. If you want things to work correctly, some things just need to be in conventional memory. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
On 5/15/2023 4:46 PM, jer...@shidel.net wrote: As you can see, the only thing in low memory is part of SYSTEM using nearly 11K. The machine still has 94K free upper memory and 84K of that is still in a single large block. Yes, I know why this is "the way it is" and you don’t need to explain it to me. But, it doesn’t need to be that way. That portion “could" be moved and it would free nearly all lower memory. Possibly through some cooperation between the Kernel and Jemm. Obviously, the Interrupt Vectors, BDA, etc would need to remain. But, the rest could be in upper memory. But mostly, I think it would look really cool to have all Zeros in the Conventional Memory Column. I think this would be an exercise in futility. After all, there are parts of the kernel, which are the first part of (Free)DOS being loaded (by the boot code in the MBR) and then are being used to put in place any further drivers, etc, including any memory manager. I am not so sure that this part "could" be in fact moved up in higher memory (and thus no longer accessible in Real Mode) without opening up not just a can but a whole 55gal drum of worms... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] trying to understand execrh.asm -- calls to EXECRH cause my 286 system to lock up
On at 2023-05-09 21:02 -0500, rehsd.i...@gmail.com wrote:
Thanks again, Eric, for the previous info. I've done a bit more digging but
haven't found the root cause of the issue yet. I have tried forcing LBA
(using sys & sys config). I have also added a bit more debugging info on
boot. I added more details to the following webpage, including a video
walkthrough trying to better describe the issue, in case anyone is bored or
just looking for a challenge. In execrh(), there are a pair of calls (likely
to a disk driver); the first of these calls ("call far the strategy") is
where I run into the issue. I'm not sure what "strategy" means in this
context.
The so-called strategy and interrupt entrypoints to DOS device drivers
are just part of the device interface, used by both block device drivers
(sector-based) and character device drivers (text-/byte-based).
You can read more about the device driver header in the interrupt list
[1], and also about the request header contents used by the various
function numbers [2]. There are some books describing this, too.
Technically, the two entrypoints are always far-called from the kernel
back to back, and the actual work by the device driver can happen in the
strategy entrypoint or in the interrupt entrypoint. Traditionally, the
strategy only ever saves the pointer it received into a buffer internal
to the device, and then the interrupt actually carries out the requested
command.
Possibly, the right information isn't being passed into the
execrh() routine, due to a failure at an earlier point. I plan to start
stripping down the kernel next -- to simplify testing and see what I can
learn.
https://www.rehsdonline.com/post/troubleshooting-freedos-boot-on-my-286-syst
em-hangs-on-execrh-call-in-kernel
If the strategy call doesn't return to the kernel soon it probably
called a bad pointer. Look at the source for the block device header
[3]. It uses GenStrategy as its strategy entrypoint, this only saves the
pointer [4]. The interrupt entrypoint is specific to the block device
[5], and it dispatches into a table in the C sources [6]. If you use a
kernel debugger you can break on and step into the far calls to the
strategy and interrupt entries to make sure they work as expected.
Regards,
ecm
[1]: https://fd.lod.bz/rbil/interrup/dos_kernel/2152.html#table-01646
[2]: https://fd.lod.bz/rbil/interrup/dos_kernel/2f0802.html#table-02595
[3]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L165
[4]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L202
[5]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/io.asm#L521
[6]:
https://github.com/FDOS/kernel/blob/afe7fbe068bf7f3cc99dc01bf8e402311095757b/kernel/dsk.c#L132
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] stack setup in BIOS, prior to loading FreeDOS
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 0x 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
