Hi Kevin, > Bochs bios is compiled with "bcc" and "as86". I've ported it to "gcc" > and "gas". I did convert most of the assembler to C code. > SF.net/mailarchive/forum.php?thread_name=20080222155930.GA7310%40double.lan&forum_name=bochs-developers
Hmm thats a long page but I do not see the why of the Asm -> C there...? > sourceforge.net/mailarchive/forum.php?thread_name=20080330153030.GA1402%40ohio.lan&forum_name=bochs-developers > The hard drive is accessed via PIO mode, so enabling irqs isn't > required for correct hd operation. I'm guessing bochs bios turns on > irqs so that the system ticks and other timers don't go unanswered Hmm interesting. Then maybe it would be better to keep IRQs off... > that the problems stop occuring. Unfortunately, when I enable irqs > and put tests in the bios ISR routines, I don't see them getting > called with low stack space... Okay but how much stack space do your BIOS IRQ handlers use for themselves? > how much stack space does the freedos ISR routines need... Depends. FreeDOS itself does not install any IRQ handlers at all. The BIOS has handlers for the keyboard, timer and ps/2 IRQs, and if you install an (optional) DOS keyboard driver or a lowlevel style mouse driver, those will install keyboard, ps/2 or serial port IRQ handlers. Other DOS apps or drivers might install IRQ handlers for timer, USB or other things. > appears that EMM386 is installing a wrapper around int 13 calls That is true, but it is odd that the offset of this emm386 int13 handler seems to the same as the offset of the lbacache one... Probably a coincidence. > I'm using freedos 1.0 - everything installed from the standard > cd download. Try updating to the versions used in the rugxulo.googlepages.com (2-3) diskette distro or at least mateusz.viste.free.fr/fdupdate/ > I'm emulating with qemu. It can dump memory areas to a file, > and it also allows one to attach gdb to the virtual machine. With Bochs, you even get a very nice debugging console as part of Bochs itself, as you probably already knew :-)). > No lbacache: 03a6:00cd = 00d1:0e68 (stack start at 00d1:0d60) > I believe stack starts at 0d60 because I see 48 consecutive 00 Correct - so the block device driver leaves your int 13 handler only 48 bytes more stack than it actually uses. Total size of the stack before blk_stk_top is 192 words = 384 bytes: 0074:0620* apistk_bottom 0074:07a0 _error_tos (620 to 7a0 initially has 0x90 0x90...) 0074:0920 _disk_api_tos (... 90 ...) 0074:0aa0 _char_api_tos (... 90 ...) (mixed non stack data follows) 0074:0ed6 blk_stk_top (d56 to ed6 initially has 00 00...) 0074:0f56 clk_stk_top (... 00 ... relatively small stack) (actual memory location is 0x60:0 later, 0xd4:..., or with older kernels at 0xd0:... or 0xd1:... see kernel.asm and *.map) > I guess stack starts at 2afc because I see 18 consecutive 20 values. You are right, the stack initially contains the value 0x20 for each byte, but only 18 bytes left is very little. After all, the lbacache stack is 64 to 84 bytes smaller than the stack of the FreeDOS block device driver. I assume I should change this and let lbacache use 64 to 96 bytes more RAM, right? Opinions? > lbacache tuns: 03a6:00cd = 03fa:00ec (stack start at 03fa:0000) > I see 26 consecutive 20 values. (This is with > "INSTALLHIGH=lbacache.com 6000 TUNS" added to fdconfig Sounds correct :-). So there are 236 bytes of stack when lbacache calls your BIOS and the BIOS uses all except 26 bytes of that. > If I dump all of memory, I see the "90" pattern at (absolute) ... It would be easier to express the locations as kernelds:offset, not as absolute linear addresses... > There is plenty of free space at those addresses (0x1c0, 0x50, > 0x164 respectively). Good to know. Those probably are the kernel int21 error/disk/char stacks listed above, and as Tom already said, the int13 calls use the kernel block device stack instead. My older mail was wrong, I had believed the int21 disk stack would be involved. Each of the 90 90 ... filled stacks is 0x180 bytes long, so the "0x1c0 free" probably really is the space for more than one stack combined, with one or more of the stacks not yet used at all (int21 error stack?). Eric ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
