DOS ain't dead - Interrupts and FAR calls from DPMI

Laaca

Czech republic,
27.02.2012, 10:03

Interrupts and FAR calls from DPMI (Developers)

I want do do some experimetns with PNP BIOS and SMBIOS. These services are called by FAR Call with parameters pushed od stack. There is no problem in real mode with it but how to do it from DPMI (I want to use realmode interface)

Normally I use int 30h/AX=300h (or 301h) with values passed into register structures but now I have to first time solve how to add parameters from DPMI into realmode stack.

Can you show me some DJGPP C code for it?
(I will programm it in Freepascal but C is readable for me)

---
DOS-u-akbar!

Khusraw

Bucharest, Romania,
27.02.2012, 13:48
(edited by Khusraw, 27.02.2012, 18:14)

@ Laaca

Interrupts and FAR calls from DPMI

Post reply

> I want do do some experimetns with PNP BIOS and SMBIOS. These services are
> called by FAR Call with parameters pushed od stack. There is no problem in
> real mode with it but how to do it from DPMI (I want to use realmode
> interface)[...]

> Can you show me some DJGPP C code for it?
> (I will programm it in Freepascal but C is readable for me)

#include <stdio.h> #include <dpmi.h> #include <sys/movedata.h> /*real mode "C" far proc which returns in dx:ax the sum of two 32-bit signed numbers*/ static char farproc[] = {0x55,0x89,0xe5,0x8b,0x46,0x06,0x8b,0x56,0x08,0x03,0x46,0x0a,0x13,0x56,0x0c,0x5d,0xcb}; int main() { long numbers[] = {12312, -3233232}; __dpmi_regs regs; int seg, sel; if ((seg = __dpmi_allocate_dos_memory(((sizeof(farproc) + 15) & -16) >> 4, &sel)) == -1) { printf("Not enough DOS memory\n"); return -1; } dosmemput((void *)farproc, sizeof(farproc), seg << 4); regs.x.cs = seg; regs.x.ip = 0; regs.x.ss = 0; regs.x.sp = 0; __dpmi_simulate_real_mode_procedure_retf_stack(&regs,sizeof(numbers)/2,(void *)&numbers); printf("The result is %d\n", (regs.x.dx << 16) + regs.x.ax); __dpmi_free_dos_memory(sel); return 0; }, or use your own preallocated-in-DOS-memory stack and copy the parameters there.
EDIT: obviously, in case you don't want to call directly int 31h/ax=301h using assembly language.

---
Glory to God for all things

Laaca

Czech republic,
28.02.2012, 16:02

@ Khusraw

Interrupts and FAR calls from DPMI

Post reply

I see. Thank you, I didn't know about function __dpmi_simulate_real_mode_procedure_retf_stack

It is not in Freepascal's GO32 unit but I can code it in assembler - no problem.
But how can I use prealocated stack in DOS memory?
1) If I understant it correct I have to allocate buffer id DOS memory
2) regs.x.ss and regs.x.sp set to this buffer
(but on the begining of the buffer or on the end of buffer?)

---
DOS-u-akbar!

Khusraw

Bucharest, Romania,
28.02.2012, 17:19
(edited by Khusraw, 28.02.2012, 17:38)

@ Laaca

Interrupts and FAR calls from DPMI

Post reply

> I see. Thank you, I didn't know about function
> __dpmi_simulate_real_mode_procedure_retf_stack
>
> It is not in Freepascal's GO32 unit but I can code it in assembler - no
> problem.

If you can code it in assembler, better push the parameters on your PM stack (as words if their size is smaller than dword, i.e. "pushw" or "push word"), and fill CX with the total number of words pushed. Before executing the interrupt, ESP has to point to the last parameter pushed.
If you still want to use your own RM stack:
regs_ss:regs_sp has to point to the end of the DOS memory buffer minus the size of parameters, the parameter values having to be copied at its end. The buffer has to be large enough because the procedure may use stack allocated local variables etc.

---
Glory to God for all things

marcov

29.02.2012, 10:35

@ Laaca

Interrupts and FAR calls from DPMI

Post reply

> I see. Thank you, I didn't know about function
> __dpmi_simulate_real_mode_procedure_retf_stack
>
> It is not in Freepascal's GO32 unit but I can code it in assembler - no
> problem.

I've an old unit that contains such functions. Naming is different (dpmi_call_rm_procedure_with_retf_frame).

http://www.stack.nl/~marcov/dpmi.pp

note that calling conventions have changes since (this is 1.0.x stuff)

RayeR

CZ,
02.03.2012, 20:51

@ Laaca

Interrupts and FAR calls from DPMI

Post reply

In DJGPP there's already allocated a piece of DOS memory called transfer buffer (usually 4kB in size - can be changed in stub/crt0) for transfer data between RM and PM. I don't know how i FP.

---
DOS gives me freedom to unlimited HW access.

Khusraw

Bucharest, Romania,
02.03.2012, 20:59

@ RayeR

Interrupts and FAR calls from DPMI

Post reply

> In DJGPP there's already allocated a piece of DOS memory called transfer
> buffer (usually 4kB in size - can be changed in stub/crt0) for transfer
> data between RM and PM. I don't know how i FP. buffer (usually 4kB in size - can be changed in stub/crt0) for transfer

In fact it defaults to 16K, and you may use stubedit.exe for changing its size.

---
Glory to God for all things

RayeR

CZ,
02.03.2012, 21:25

@ Khusraw

Interrupts and FAR calls from DPMI

Post reply

> In fact it defaults to 16K, and you may use stubedit.exe for changing its
> size.

Yes, you're right. Minimum 2kB.
http://www.delorie.com/djgpp/v2faq/faq18_2.html

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
03.03.2012, 21:31

@ RayeR

Interrupts and FAR calls from DPMI

Post reply

Yes, in FP is preallocated transfer buffer too.

---
DOS-u-akbar!

RayeR

CZ,
05.03.2012, 15:16

@ Laaca

Interrupts and FAR calls from DPMI

Post reply

> Yes, in FP is preallocated transfer buffer too.

And what you're goning to do with it? Some power management for NTBs?

---
DOS gives me freedom to unlimited HW access.

Laaca

Czech republic,
07.03.2012, 07:17

@ RayeR

Interrupts and FAR calls from DPMI

Post reply

> And what you're goning to do with it? Some power management for NTBs?

I don't know yet but it is good to have prepared "technology".

---
DOS-u-akbar!

bretjohn

Rio Rancho, NM,
07.03.2012, 18:08

@ Laaca

Interrupts and FAR calls from DPMI

Post reply

> > And what you're goning to do with it? Some power management for NTBs?
>
> I don't know yet but it is good to have prepared "technology".

It's possible something like this could come in handy for future USB things as well. At least in my current USB drivers, parameters are passed via a pointer rather than the stack. But, in the future, I suspect something like this might come in handy for certain applications.