Kevin,
> On Sun, Apr 06, 2008 at 01:34:11PM +0200, Tom Ehlert wrote:
>> a) freedos *always* calls int13 on the block device stack
>> with stack bottom
>> DOS DS:aa0
>> and top DOS DS:ee2 (384 byte); DOS DS is usually 0x00D0 or 0x00d1
> I don't understand: 0xee2 - 0xaa0 is 1090 bytes.
you are right. I took that straight from kernel.map
0070:0aa0 _char_api_tos
0070:0ee2 blk_stk_top
but
; blockdev private stack
global blk_stk_top
times 192 dw 0
blk_stk_top:
shows that there are other data in between ;)
so freeDOS block device stack extends from xxx:0ee2 down 384 byte
>> OTOH I'm wandering why you don't just turn any int 13 read/write
>> request into a VM_CALL(DiskRead, buffer, num_sectors) or similar
>> this should be *much* faster
> The bochs bios is used by at least 5 projects: bochs, qemu, kvm,
> virtualbox, and coreboot. These projects also support OSes that
> directly access the hardware (eg, Linux and Windows). So, it wouldn't
> make sense to also have to support emulated bios calls.
sure, you have to support direct hardware access.
but this would a) accelerate BIOS b) simplify BIOS and c) make it
easier to write an (optional) device driver for Virtualbox etc.
> In the case
> of coreboot the goal is to implement an open source bios for real
> hardware.
that's true
>> lbacache tuns: 03a6:00cd = 03fa:00ec (stack start at 03fa:0000)
>>
>> you might be able to set a memory break point at 3fa:0000; either
>> using the debugger, or compiling into the virtual machine directly
>> (I have no idea what the Bochs debugger is able to do)
>>
>> if the debugger fires, find out which interrupt was called ...
> Thanks.
> The general feedback I'm getting is that 236 bytes of stack space
> should be sufficient for a bios call (and any ISRs). I can make this
> work today, but adding new features (eg, support for hard drives over
> 2 TB) is becoming difficult.
> I don't want to drop support for freedos.
afaik freedos works great on bochs, qemu, kvm,virtual box etc.
(and some people would probably kill you if qemu dropped freedos
support ;)
this *might* be a problem with larger stack overhead for a C based
BIOS
> One option is to have the
> bios use its own stack - but that raises new questions - where to put
> it and does the bios have to handle recursive calls.
int 13 BIOS is definitively not reentrant
Tom
-------------------------------------------------------------------------
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
