[fpc-pascal] FPC in DOS environment

[Daniel Franzini]

On 1/12/07, Tomas Hajny <XHajT03 at mbox.vol.cz> 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 at 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'')
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20070115/4ed1ed08/attachment.html>