On 1/12/07, Tomas Hajny <[EMAIL PROTECTED]> wrote:
In general case when using plain DOS (when using virtual DOS machines provided by some other platforms like WinXX or OS/2, DPMI is provided directly by the platform and interface to it is part of the VDM kernel). The only "magic" is detection of DPMI (int 31h support) availability, potentially launching CWSDPMI.EXE host and switching into 32-bit protected mode. Interfacing to functions provided by the host is part of GO32v2 RTL (using int 31h services), or some host services just overlay the usual DOS services (overridden int 21h calls).
wow...this is some hardcore stuff...gotta read the manuals and try some code in order to understand it correctly (specially the overriden part) Just very briefly:
1) Read what our manual, wiki and mailing lists contributions state on FPC calling conventions (i.e. how parameters are passed to functions/procedures and how the stack organization and processing look like) - this is certainly different from TP/BP. This implies changes of code using [bp]. 2) In general, you should use 32-bit registers rather than 16-bit registers (I believe there's even some speed penalty on some CPUs when using 16-bit registers, but more importantly, the overridden functions may even _require_ providing parameters in 32-bit registers as opposed to e.g. standard DOS functions) - i.e. eax instead of ax, etc. 3) If you need to exchange data with the underlying 16-bit code like BIOS functions (yes, this includes your read/write sectore functions), the used memory buffer must be placed in a memory area where the 16-bit code can access it (= within the first MB of RAM) if it's your code allocating the buffer and you need to make sure that you can access it too. This is achieved using DPMI functions (read DPMI specification to find out more, or at least have a look at some FPC RTL code using these int 31h functions). 4) In general, you don't touch any segment registers - all your data are available in flat memory model, where everything is available using 32-bit addressing and ds=es=ss (i.e. no instructions like lds/les needed, no mov es:[xx],yy, etc.). There's one exception directly related to the previous point related to sharing data with 16-bit code - if you pass parameters to/receive results from 16-bit code/functions, you need to translate the 16:16 16-bit addresses to 0:32 addresses used in 32-bit code and vice versa (as described above) and then you obviously might need to change some segment registers too immediately before/after the 16-bit function call (however, these cases are normally solved using helper functions like the DPMI support function for calling 16-bit interrupts, i.e. your code wouldn't be directly messing with segment registers anyway).
thanks for this...i've got myself some firmware code to write for work but as soon as i get home and setup my old box this will be studied carefully Tomas
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
-- Daniel "Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth) "Yes, technogeeks can be funny, even if only to each other." ( http://www.boogieonline.com/revolution/science/humor/)" "Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'')
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
