Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2007-01

FPC in DOS environment

15 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Daniel Franzini

Hi all

i'm trying to use fpc in a old DOS environment by using FreeDOS inside Virtual PC (guess i should be using vmware)

the problem is that i have some low-level code which i would like to port to fpc. FreeDOS came with fpc 2.0.2 which i think is suitable for my needs.

1.) i can't even compile the code
----------------------start------------------------------- C:\>cd
code
C:\code>fpc diskexp.pas

An unhandled exception occurred at $0001072C
:
EAccessViolation : Access
violation

$0001072C

$00010752

$00010CC0

$00010D13

$000100A8

$00006E8F

$00006ED0

$000022E3

$0000279E

----------------------------end------------------------

the strange thing is that if i call fpc without parameters the (huge) usage shows up correctly...is fpc for go32v2 a pmode app? which extender do you recommend me to use?

2.) i have some questions regarding pmode programming with fpc since i never used go32v2. with cwsdpmi, one compiles and links, getting an exe and this exe should be put in the same folder of cwsdpmi.exe. what's the general procedure for go32v2?

3.) in other machine i tried and compiled the code but got some strange results (i can post as soon as a i get home and reach that machine). here is the code:
-------------------------------------------code
start--------------------------------------------------------------------------- program DiskExplorer;

uses crt, dos;
const
        BUFLEN = 4608;
        BUFSECT = 9;
        COMMANDX = 1;
        COMMANDY = 20;
        COMMAND_RT = 79;
        COMMAND_BOT = 24;
        STATUSX = 1;
        STATUSY = 18;
        STATUS_RT = 79;
        STATUS_BOT = 19;
        LEFTSCREEN = 1;
        RIGHTSCREEN = 80;
        TOPSCREEN = 1;
        BOTTOMSCREEN = 17;
        ERROR = -1;
type
        buf = array[0..BUFLEN] of byte;
var
        finished: boolean;
        drive: byte;
        sector: integer;
        buffer: buf;
        regs: Registers;

function DiskRead(drive: byte; sector, n_sectors: integer; var buffer: buf): integer;
begin
inline($55/
{this assembly code does nothing more than saving correct stuff, executes DOS}
$8B/$EC/
{interrupts for read/write the disk, restores stuff, flushes DOS buffer and exits }
$83/$C5/$08/
$1E/
$8B/$5E/$00/
$8B/$46/$02/
$8E/$D8/
$8B/$4E/$04/
$8B/$56/$06/
$8A/$46/$08/
$55/
$CD/$25/
$73/$08/
$9D/
$5D/
$89/$46/$0A/
$EB/$08/$90/
$9D/
$5D/
$33/$C0/
$89/$46/$0A/
$1F/

               $5D);

end;

function DiskWrite(drive: byte; sector, n_sectors: integer; var buffer: buf): integer;
begin
inline($55/
$8B/$EC/
$83/$C5/$08/
$1E/
$8B/$5E/$00/
$8B/$46/$02/
$8E/$D8/
$8B/$4E/$04/
$8B/$56/$06/
$8A/$46/$08/
$55/
$CD/$26/
$73/$08/
$9D/
$5D/
$89/$46/$0A/
$EB/$08/$90/
$9D/
$5D/
$33/$C0/
$89/$46/$0A/
$1F/

               $5D);
        regs.ax := $D00;
        intr($21, regs);

end;

procedure Beep;
begin
        sound(400);
        delay(500);
        sound(300);
        delay(500);
        nosound;
end;
procedure DisplayStartScreen;
begin
        clrscr;
        window(1,1,80,25);
        writeln('=================Disk Examiner=================');
        writeln;
        writeln;
        writeln;
        writeln;
        writeln('-------------------MAIN MENU-------------------');
        writeln('F1: Dump and modify sectors');
        writeln;
        writeln('F10: Exit');
end;
{ main routine }
begin
        drive := 0;
        sector := 0;
        finished := false;
        while not finished do
        begin
                DisplayStartScreen;
                regs.ax := 0;
                intr($16, regs);
                if regs.ax and $ff = 0 then
                begin
                        clrscr;
                        case (regs.ax) of
                                $4400: finished := true;
                        end;
                end;
        end;
end.
-------------------------------------------code
end---------------------------------------------------------------------------

this code compiles fine with tp5.5 (altough the window function does not work)...what is the correct way to make such a thing in fpc?!

how to mix assembly with fpc in the same procedure/function? i tried but it complained about the labels

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'')

Reply by email

Daniël Mantione
to Daniel Franzini

Op Wed, 10 Jan 2007, schreef Daniel Franzini:

Show quoted text 7 lines
Hi all i'm trying to use fpc in a old DOS environment by using FreeDOS inside Virtual PC (guess i should be using vmware) the problem is that i have some low-level code which i would like to port to fpc. FreeDOS came with fpc 2.0.2 which i think is suitable for my needs.

This the situation:
* The Dos port is without a maintainer.
* We are still providing it because many people have need for a Dos version
* Bugs in the Dos port are not being fixed so it is of poor quality.

Show quoted text 25 lines
1.) i can't even compile the code ----------------------start------------------------------- C:\>cd code C:\code>fpc diskexp.pas An unhandled exception occurred at $0001072C : EAccessViolation : Access violation $0001072C $00010752 $00010CC0 $00010D13 $000100A8 $00006E8F $00006ED0 $000022E3 $0000279E ----------------------------end------------------------ the strange thing is that if i call fpc without parameters the (huge) usage shows up correctly...is fpc for go32v2 a pmode app? which extender do you recommend me to use?

Yes, it is a protected mode app, using the go32v2 extender. You need a dpmi service on your system. Normally on real Dos you use cwsdpmi, but any DPMI will do. However, WinNT/2000/XP is troublesome because their DPMI support is buggy.

2.) i have some questions regarding pmode programming with fpc since i never used go32v2. with cwsdpmi, one compiles and links, getting an exe and this exe should be put in the same folder of cwsdpmi.exe. what's the general procedure for go32v2?

go32v2 is the extender, cwsdpmi the dpmi host that comes with it. So you have used go32v2 before, and the procedure is the same with FPC programs.

this code compiles fine with tp5.5 (altough the window function does not work)...what is the correct way to make such a thing in fpc?!

The code you should contains 16 bit assembler. FPC is a 32 bit application. So the assembler needs to be rewritten in 32-bit assembler. Other than that, FPC is compatible with TP. So, just put the compiler in TP mode an compile.

how to mix assembly with fpc in the same procedure/function? i tried but it complained about the labels

Local labels need to start with a @. Please read the manuals, this is well documented.

Daniël

Reply by email

Jonas Maebe
to Daniël Mantione
Daniël Mantione wrote 5 lines
This the situation: * The Dos port is without a maintainer. * We are still providing it because many people have need for a Dos version * Bugs in the Dos port are not being fixed so it is of poor quality.

That's not true anymore since Pierre is back.

Jonas

Reply by email

Tomas Hajny
to Daniel Franzini: Hi all i'm trying to use fpc in a old DOS environment by using FreeDOS inside Virtual PC…

Daniel Franzini wrote:

Hi Daniel,

i'm trying to use fpc in a old DOS environment by using FreeDOS inside Virtual PC (guess i should be using vmware)

I've had difficulties running FPC apps (probably including the compiler itself) under FreeDOS in the past (whereas it works properly with other DOS implementations like MS-DOS, IBM PC DOS and DR-DOS/Novell DOS). Things might have improved since then, though.

the problem is that i have some low-level code which i would like to port to fpc. FreeDOS came with fpc 2.0.2 which i think is suitable for my needs.

.
.

the strange thing is that if i call fpc without parameters the (huge) usage shows up correctly...is fpc for go32v2 a pmode app? which extender do you recommend me to use?

GO32v2 is a protected mode application, indeed - specifically, it's using DPMI (DOS Protected Mode Interface). No special extender is needed if you already have DPMI host available (up and running). Some DOS implementations already include this such DPMI host, similarly DPMI host is provided for DOS applications running under Win 3.x, Win32 platforms, OS/2, etc. If you run GO32v2 applications and no DPMI host is running, the loader/stub (linked into the compiled executable) tries to locate (using standard search rules - current directory and then using %PATH%) and launch CWSDPMI.EXE first (thus starting a DPMI host itself).

Show quoted text 5 lines
2.) i have some questions regarding pmode programming with fpc since i never used go32v2. with cwsdpmi, one compiles and links, getting an exe and this exe should be put in the same folder of cwsdpmi.exe. what's the general procedure for go32v2?

I guess the description above should be sufficient. Alternatively, you can bind the DPMI host directly into the executable (using tools provided within the standard CWSDPMI package), but this is of limited use in general (only reasonable if having single GO32v2 executable on a DOS machine with no DPMI host).

3.) in other machine i tried and compiled the code but got some strange results (i can post as soon as a i get home and reach that machine). here is the code:

.
.

Show quoted text 5 lines
function DiskRead(drive: byte; sector, n_sectors: integer; var buffer: buf): integer; begin inline($55/

.
.

{this assembly code does nothing more than saving correct stuff, executes DOS}

.
.

Surely, this inline stuff needs to be disassembled and ported to a 32-bit protected mode environment in order to make it to work properly with FPC.

this code compiles fine with tp5.5 (altough the window function does not work)...what is the correct way to make such a thing in fpc?!

Rewrite it in proper 32-bit assembler targetted for a protected mode environment. I guess you should be able to find some information available on Internet regarding what needs to be changed and how, but it isn't that simple to be described here (especially with functions requiring a memory buffer shared between real mode and protected mode code like with your disk read/write functions).

how to mix assembly with fpc in the same procedure/function? i tried but it complained about the labels

I guess that it's easier to discuss the particular example you tried directly if you post it here.

Tomas

Reply by email

Daniel Franzini
to Daniël Mantione: Op Wed, 10 Jan 2007, schreef Daniel Franzini: This the situation: * The Dos port is…
Daniël Mantione wrote 7 lines
This the situation: * The Dos port is without a maintainer. * We are still providing it because many people have need for a Dos version * Bugs in the Dos port are not being fixed so it is of poor quality.

well, if so i'm a volunteer to mantain the DOS port...

Yes, it is a protected mode app, using the go32v2 extender. You need a

dpmi service on your system. Normally on real Dos you use cwsdpmi, but any DPMI will do. However, WinNT/2000/XP is troublesome because their DPMI support is buggy.

i was not trying to use it in win nt/xp/2000...its freedos inside a MS Virtual PC....since i don't have a pentium 100 or a 486 i cannot test this on a real machine...

go32v2 is the extender, cwsdpmi the dpmi host that comes with it. So you have used go32v2 before, and the procedure is the same with FPC programs.

ok...when exactly the go32v2 gets linked with my code? is this done automatically by the compiler???

The code you should contains 16 bit assembler. FPC is a 32 bit

application. So the assembler needs to be rewritten in 32-bit assembler. Other than that, FPC is compatible with TP. So, just put the compiler in TP mode an compile.

thanks

can this be compiled directly in a 32bit assembler like nasm (or directly assembled by the fpc internal assembler using directives to use asm inside pascal source)????

i was also looking for a way to rewrite this in clean Pascal language...is this possible in pmode using fpc (note the code contains an interrupt call for a low level operation)???

here is the small assembly source that generates the code i posted:

------------------code start-----------------------------

{diskwrite}
asm
push bp
mov bp, sp
add bp, 8
push ds
mov bx, [bp]
mov ax, [bp+2]
mov ds, ax
mov cx, [bp+4]
mov dx, [bp+6]
mov al, [bp+8]
push bp
int 26h
jnc ok
popf
pop bp
mov [bp+10], ax
jmp cont
ok: popf
pop bp
xor ax, ax
mov [bp+10], ax
cont: pop ds
pop bp
mov ax, 13h
int 21h
ret
------------------code end-----------------------------

Local labels need to start with a @. Please read the manuals, this is well

documented.

sorry...my bad about this...reading the manuals right now, while writing this

Daniël

Daniel

Reply by email

Daniel Franzini
to Jonas Maebe: That's not true anymore since Pierre is back. Jonas

well....like i said before, i'm a volunteer to mantain the port...if Pierre does need some sort of help he can call me

Jonas Maebe wrote 17 lines
On 11 jan 2007, at 10:14, Daniël Mantione wrote: > This the situation: > * The Dos port is without a maintainer. > * We are still providing it because many people have need for a Dos > version > * Bugs in the Dos port are not being fixed so it is of poor quality. That's not true anymore since Pierre is back. Jonas_______________________________________________ fpc-pascal maillist - 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'')

Reply by email

Daniel Franzini
to Tomas Hajny: I've had difficulties running FPC apps (probably including the compiler itself) under…
Tomas Hajny wrote 5 lines
Daniel Franzini wrote: Hi Daniel,

Hi

I've had difficulties running FPC apps (probably including the compiler itself) under FreeDOS in the past (whereas it works properly with other DOS implementations like MS-DOS, IBM PC DOS and DR-DOS/Novell DOS). Things might have improved since then, though.

the compiler does run fine here...i think things got better now, since fpc is now part of the oficial freedos 1.0 packages...things that annoy me in freedos are a bug in setedit which makes the mouse gets crazy and the fact that i could not yet set up my keyboard correctly...the rest does run fine here...

Show quoted text 10 lines
GO32v2 is a protected mode application, indeed - specifically, it's using DPMI (DOS Protected Mode Interface). No special extender is needed if you already have DPMI host available (up and running). Some DOS implementations already include this such DPMI host, similarly DPMI host is provided for DOS applications running under Win 3.x, Win32 platforms, OS/2, etc. If you run GO32v2 applications and no DPMI host is running, the loader/stub (linked into the compiled executable) tries to locate (using standard search rules - current directory and then using %PATH%) and launch CWSDPMI.EXE first (thus starting a DPMI host itself).

this is something still obscure to me....when i target the compiler to go32v2, the compiler generates my code and links it with some magic code in order to work correctly with the funtions provided by the host (which in the general case is a standalone exe)???

Show quoted text 5 lines
I guess the description above should be sufficient. Alternatively, you can bind the DPMI host directly into the executable (using tools provided within the standard CWSDPMI package), but this is of limited use in general (only reasonable if having single GO32v2 executable on a DOS machine with no DPMI host).

i guess i should look for the DPMI host documentation on freedos in order to find out what host it is, if its enabled by default and how to enable/disable it...but thanks anyway

Surely, this inline stuff needs to be disassembled and ported to a 32-bit protected mode environment in order to make it to work properly with FPC.

the code that generates is here:
------------------code start-----------------------------

{diskwrite}
asm
push bp
mov bp, sp
add bp, 8
push ds
mov bx, [bp]
mov ax, [bp+2]
mov ds, ax
mov cx, [bp+4]
mov dx, [bp+6]
mov al, [bp+8]
push bp
int 26h
jnc ok
popf
pop bp
mov [bp+10], ax
jmp cont
ok: popf
pop bp
xor ax, ax
mov [bp+10], ax
cont: pop ds
pop bp
mov ax, 13h
int 21h
ret
------------------code end-----------------------------

Show quoted text 6 lines
Rewrite it in proper 32-bit assembler targetted for a protected mode environment. I guess you should be able to find some information available on Internet regarding what needs to be changed and how, but it isn't that simple to be described here (especially with functions requiring a memory buffer shared between real mode and protected mode code like with your disk read/write functions).

like i said to Daniel Mantionne, the plans are to rewrite it in pure pascal...but it should work first in 32bit assembly...what would be the main differences between the two asm sources??

Show quoted text 6 lines
I guess that it's easier to discuss the particular example you tried directly if you post it here. Tomas

thanks

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'')

Reply by email

Daniël Mantione
to Daniel Franzini: well, if so i'm a volunteer to mantain the DOS port... Yes, it is a protected mode app,…

Op Thu, 11 Jan 2007, schreef Daniel Franzini:

Show quoted text 8 lines
On 1/11/07, Daniël Mantione wrote: > This the situation: > * The Dos port is without a maintainer. > * We are still providing it because many people have need for a Dos > version > * Bugs in the Dos port are not being fixed so it is of poor quality. well, if so i'm a volunteer to mantain the DOS port...

Well, help is certainly very welcome, but note that more is needed than one or two bug fixes. To make it a first platform again someone is needed who really uses Dos, so he quickly notes when something is wrong and can make some new developments available on the Dos platform.

Show quoted text 10 lines
Yes, it is a protected mode app, using the go32v2 extender. You need a > dpmi service on your system. Normally on real Dos you use cwsdpmi, but > any > DPMI will do. However, WinNT/2000/XP is troublesome because their DPMI > support > is buggy. i was not trying to use it in win nt/xp/2000...its freedos inside a MS Virtual PC....since i don't have a pentium 100 or a 486 i cannot test this on a real machine...

Ok, so it is real DPMI. Since it can run OS/2 I think VPC should be of sufficient quality to run a Dos extender but note that many virtual machines don't a PC emulate good enough and can be expected to cause some trouble here. I'm not saying this is the case here, but you shouldn't put limitless trust in your VM either.

Show quoted text 5 lines
> go32v2 is the extender, cwsdpmi the dpmi host that comes with it. So you > have used go32v2 before, and the procedure is the same with FPC programs. ok...when exactly the go32v2 gets linked with my code? is this done automatically by the compiler???

Yes.

Show quoted text 11 lines
The code you should contains 16 bit assembler. FPC is a 32 bit > application. So the assembler needs to be rewritten in 32-bit assembler. > Other than that, FPC is compatible with TP. So, just put the compiler in > TP mode an compile. thanks can this be compiled directly in a 32bit assembler like nasm (or directly assembled by the fpc internal assembler using directives to use asm inside pascal source)????

I suggest to use the internal assembler.

i was also looking for a way to rewrite this in clean Pascal language...is this possible in pmode using fpc (note the code contains an interrupt call for a low level operation)???

You should check the go32 extender documentation wether it supports interrupt 26. If yes, the port will be easy, you can just update the code using 32 bit registers (i.e. ebp instead of bp).

If not, it is harder: you should allocate real mode memory, copy data to real mode and do a real mode interrupt. The go32 contains the procedures to do this.

Daniël

Reply by email

Tomas Hajny
to Daniel Franzini: Hi the compiler does run fine here...i think things got better now, since fpc is now part…
Daniel Franzini wrote
On 1/11/07, Tomas Hajny wrote:

.
.

Show quoted text 20 lines
> GO32v2 is a protected mode application, indeed - specifically, it's > using > DPMI (DOS Protected Mode Interface). No special extender is needed if > you > already have DPMI host available (up and running). Some DOS > implementations already include this such DPMI host, similarly DPMI host > is provided for DOS applications running under Win 3.x, Win32 platforms, > OS/2, etc. If you run GO32v2 applications and no DPMI host is running, > the > loader/stub (linked into the compiled executable) tries to locate (using > standard search rules - current directory and then using %PATH%) and > launch CWSDPMI.EXE first (thus starting a DPMI host itself). this is something still obscure to me....when i target the compiler to go32v2, the compiler generates my code and links it with some magic code in order to work correctly with the funtions provided by the host (which in the general case is a standalone exe)???

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).

.
.

Show quoted text 55 lines
> Surely, this inline stuff needs to be disassembled and ported to a > 32-bit > protected mode environment in order to make it to work properly with > FPC. the code that generates is here: ------------------code start----------------------------- {diskwrite} asm push bp mov bp, sp add bp, 8 push ds mov bx, [bp] mov ax, [bp+2] mov ds, ax mov cx, [bp+4] mov dx, [bp+6] mov al, [bp+8] push bp int 26h jnc ok popf pop bp mov [bp+10], ax jmp cont ok: popf pop bp xor ax, ax mov [bp+10], ax cont: pop ds pop bp mov ax, 13h int 21h ret ------------------code end----------------------------- > Rewrite it in proper 32-bit assembler targetted for a protected mode > environment. I guess you should be able to find some information > available > on Internet regarding what needs to be changed and how, but it isn't > that > simple to be described here (especially with functions requiring a > memory > buffer shared between real mode and protected mode code like with your > disk read/write functions). like i said to Daniel Mantionne, the plans are to rewrite it in pure pascal...but it should work first in 32bit assembly...what would be the main differences between the two asm sources??

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).

Tomas

Reply by email

Daniel Franzini
to Daniël Mantione: Op Thu, 11 Jan 2007, schreef Daniel Franzini: Well, help is certainly very welcome, but…

thanks for the help

Daniël Mantione wrote 8 lines
Well, help is certainly very welcome, but note that more is needed than one or two bug fixes. To make it a first platform again someone is needed who really uses Dos, so he quickly notes when something is wrong and can make some new developments available on the Dos platform.

i use DOS regularly (right this moment, my 'lab' got messed up by a foreign handand i lost a AT power supply so no old PC running; this will get fixed today)

i will do my best to make it up to date and to help Pierre

Ok, so it is real DPMI. Since it can run OS/2 I think VPC should be of

sufficient quality to run a Dos extender but note that many virtual machines don't a PC emulate good enough and can be expected to cause some trouble here. I'm not saying this is the case here, but you shouldn't put limitless trust in your VM either.

well, a think that the problem is with freedos native dpmi (called hdpmi)...i will try to use cwsdpmi inseated to run fpc

i forgot to mention that i noticed that the ide has this strange behavior: it loads, shows up and quickly disappears...no error msg, no crash

for the sake of developing the DOS plataform, which version should i use: the 2.0.x branch or the new 2.1.x ??

Yes.

thanks

I suggest to use the internal assembler.

i will do so

You should check the go32 extender documentation wether it supports

Show quoted text 6 lines
interrupt 26. If yes, the port will be easy, you can just update the code using 32 bit registers (i.e. ebp instead of bp). If not, it is harder: you should allocate real mode memory, copy data to real mode and do a real mode interrupt. The go32 contains the procedures to do this.

thanks for this info...gotta study the go32 unit and the go32v2 extender itself

Daniël

Show quoted text 6 lines
_______________________________________________ fpc-pascal maillist - 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'')

Reply by email

Daniel Franzini
to Tomas Hajny: . . In general case when using plain DOS (when using virtual DOS machines provided by…
Tomas Hajny wrote 9 lines
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:

Show quoted text 34 lines
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

Show quoted text 5 lines
_______________________________________________ fpc-pascal maillist - 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'')

Reply by email

Pierre Muller
to Daniel Franzini: thanks for the help i use DOS regularly (right this moment, my 'lab' got messed up by a…
Show quoted text 6 lines
i use DOS regularly (right this moment, my 'lab' got messed up by a foreign handand i lost a AT power supply so no old PC running; this will get fixed today) i will do my best to make it up to date and to help Pierre

The current 2.0 fixes branch should be more
stable.

Could you please try to download and install
ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v20/i386-go32v2/fpc-2.0.5dos.zip The file datestamp should be January 15. 2007,
or later.
Let's say that you unpack this into
/pas/snp205 directory.
he snapshot ppc386 will then be in
/pas/snp205/bin/go32v2 directory.

Unzip the file and test the IDE,
by compliling and stepping through a simple source. (like the ide/test.pas file).

Please report if this is working OK for you,
or any problems you might encounter.

A second step would be to recompile the IDE
from the current 2.0.5 sources, with debugger information.

First download and install
ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v20/source/fpcbuild.zip You will also need to download and install the GDB libraries: the zip file is:
ftp://ftpmaster.freepascal.org/pub/fpc/contrib/libgdb/v6.1.1/go32v2-v601.zip

Unzip all librairies (lib*.a files)
into \pas\libgdb\go32v2 for example

change to fpcbuild/fpsrc/ide directory

You need to inform where the GDB librairies are,
for this you will need to set GDBLIBDIR variable.

set GDBLIBDIR=/pas/ligdb/go32v2
should work for this.

After this, you will need to recompile several directories

make -C ../rtl DEBUG=1
make -C ../packages/base/graph DEBUG=1
make -C ../packages/base/regexpr DEBUG=1
make -C ../packages/base/gdbint DEBUG=1
make -C ../fv DEBUG=1
make clean all DEBUG=1 OPT=-gl

If everything works fine, you should have at that point a fp.exe file that is about 10Mb in size.

The problem for me, (I am stick for the moment on a windows 2000 computer), is that the IDE tends to crash randomly, but I don't know if it comes from the IDE or from the poor Dos emulation of Windows 2000...

Tell me if you succeed in compiling this and if
the generated IDE is usable, or gives you useful information when crashing (the -gl option, should create a verbose stack on crashes).

Thanks for trying this out,

By the way, testers for emx, os/2 or wdosx targets would also be most welcomed,

Pierre

Reply by email

Daniel Franzini
to Pierre Muller

for now, on MS Virtual PC with fpc2.0.5 stable for go32v2, the IDE does not even get loaded correctly...it displays some info on compiler and ide version, shows the nice FP screen and then exits quickly...i will try to recompile from the sources with debug info to see exactly where it stops (altough i'm no gdb expert)

not sure if this is a problem of freedos or virtual pc buggy DPMI or some kind of combination of these two

when i get home, i will try on a real machine with freedos and with real DOS (if i manage to find my diskset)

Pierre Muller wrote 81 lines
> i use DOS regularly (right this moment, my 'lab' got messed up by a > foreign > handand i lost a AT power supply so no old PC running; this will get fixed > today) > > i will do my best to make it up to date and to help Pierre The current 2.0 fixes branch should be more stable. Could you please try to download and install ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v20/i386-go32v2/fpc-2.0.5dos.zip The file datestamp should be January 15. 2007, or later. Let's say that you unpack this into /pas/snp205 directory. he snapshot ppc386 will then be in /pas/snp205/bin/go32v2 directory. Unzip the file and test the IDE, by compliling and stepping through a simple source. (like the ide/test.pas file). Please report if this is working OK for you, or any problems you might encounter. A second step would be to recompile the IDE from the current 2.0.5 sources, with debugger information. First download and install ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v20/source/fpcbuild.zip You will also need to download and install the GDB libraries: the zip file is: ftp://ftpmaster.freepascal.org/pub/fpc/contrib/libgdb/v6.1.1/go32v2-v601.zip Unzip all librairies (lib*.a files) into \pas\libgdb\go32v2 for example change to fpcbuild/fpsrc/ide directory You need to inform where the GDB librairies are, for this you will need to set GDBLIBDIR variable. set GDBLIBDIR=/pas/ligdb/go32v2 should work for this. After this, you will need to recompile several directories make -C ../rtl DEBUG=1 make -C ../packages/base/graph DEBUG=1 make -C ../packages/base/regexpr DEBUG=1 make -C ../packages/base/gdbint DEBUG=1 make -C ../fv DEBUG=1 make clean all DEBUG=1 OPT=-gl If everything works fine, you should have at that point a fp.exe file that is about 10Mb in size. The problem for me, (I am stick for the moment on a windows 2000 computer), is that the IDE tends to crash randomly, but I don't know if it comes from the IDE or from the poor Dos emulation of Windows 2000... Tell me if you succeed in compiling this and if the generated IDE is usable, or gives you useful information when crashing (the -gl option, should create a verbose stack on crashes). Thanks for trying this out, By the way, testers for emx, os/2 or wdosx targets would also be most welcomed, Pierre _______________________________________________ fpc-pascal maillist - 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'')

Reply by email

Daniel Franzini
to Pierre Muller: The current 2.0 fixes branch should be more stable. Could you please try to download and…

today (quite late) i've got myself some improvements...so far i was unable to even compile some parts od fpc within freedos (inside virtual pc)...the IDE that comes with fpc2.0.5 does not even start at all...now i can compile correctly all the packages needed to build the ide (as Pierre pointed)...the problem now is that make is crashing when i do

make clean all DEBUG=1 OPT=-gl

my guess is that the DPMI support on FreeDOS is somehow incompatible with the standard cwsdpmi (is there any other DPMI server i can use in order to achieve 100% compatibility with go32v2?)...right now i'm making a try with the standard cwsdpmi (provided in the fpcbuild package)...i will post the results soon

now, i think i can perfom a few tests like you pointed with the ide compiled with debug suport...question: is the DEBUG=1 parameter for make to compile with debug support or to instruct the make to be verbose???

it was a bunch of tricky to get it working correctly...seems that fpc and freedos are not quite good friends yet...fpc AND freedos relies on the same env var for completely different things....both of them have the CFGFILE var...to fpc it means the fpc.cfg standard configuration file....to freedos it means the standard config.sys-like file...the (temporary) solution was to unset the cfgfile to freedos and let fpc use it in his way then setting it again for freedos...is there a better solution in the sense of changing the makefile (or makefile.fpc) on the fpc side??

Pierre Muller wrote 75 lines
The current 2.0 fixes branch should be more stable. Could you please try to download and install ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v20/i386-go32v2/fpc-2.0.5dos.zip The file datestamp should be January 15. 2007, or later. Let's say that you unpack this into /pas/snp205 directory. he snapshot ppc386 will then be in /pas/snp205/bin/go32v2 directory. Unzip the file and test the IDE, by compliling and stepping through a simple source. (like the ide/test.pas file). Please report if this is working OK for you, or any problems you might encounter. A second step would be to recompile the IDE from the current 2.0.5 sources, with debugger information. First download and install ftp://ftpmaster.freepascal.org/pub/fpc/snapshot/v20/source/fpcbuild.zip You will also need to download and install the GDB libraries: the zip file is: ftp://ftpmaster.freepascal.org/pub/fpc/contrib/libgdb/v6.1.1/go32v2-v601.zip Unzip all librairies (lib*.a files) into \pas\libgdb\go32v2 for example change to fpcbuild/fpsrc/ide directory You need to inform where the GDB librairies are, for this you will need to set GDBLIBDIR variable. set GDBLIBDIR=/pas/ligdb/go32v2 should work for this. After this, you will need to recompile several directories make -C ../rtl DEBUG=1 make -C ../packages/base/graph DEBUG=1 make -C ../packages/base/regexpr DEBUG=1 make -C ../packages/base/gdbint DEBUG=1 make -C ../fv DEBUG=1 make clean all DEBUG=1 OPT=-gl If everything works fine, you should have at that point a fp.exe file that is about 10Mb in size. The problem for me, (I am stick for the moment on a windows 2000 computer), is that the IDE tends to crash randomly, but I don't know if it comes from the IDE or from the poor Dos emulation of Windows 2000... Tell me if you succeed in compiling this and if the generated IDE is usable, or gives you useful information when crashing (the -gl option, should create a verbose stack on crashes). Thanks for trying this out, By the way, testers for emx, os/2 or wdosx targets would also be most welcomed, Pierre _______________________________________________ fpc-pascal maillist - 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'')

Reply by email

Daniël Mantione
to Daniel Franzini

Op Wed, 24 Jan 2007, schreef Daniel Franzini:

Show quoted text 8 lines
today (quite late) i've got myself some improvements...so far i was unable to even compile some parts od fpc within freedos (inside virtual pc)...the IDE that comes with fpc2.0.5 does not even start at all...now i can compile correctly all the packages needed to build the ide (as Pierre pointed)...the problem now is that make is crashing when i do make clean all DEBUG=1 OPT=-gl

A real crash or does it abort with an error?

Show quoted text 5 lines
my guess is that the DPMI support on FreeDOS is somehow incompatible with the standard cwsdpmi (is there any other DPMI server i can use in order to achieve 100% compatibility with go32v2?)...right now i'm making a try with the standard cwsdpmi (provided in the fpcbuild package)...i will post the results soon

I always used qdpmi (from QEMM). However, cwsdpmi is the most tested solution.

now, i think i can perfom a few tests like you pointed with the ide compiled with debug suport...question: is the DEBUG=1 parameter for make to compile with debug support or to instruct the make to be verbose???

DEBUG=1 will pass the commandline option -gl to the compiler. So the command you use above is a bit double, but it shouldn't harm.

Show quoted text 9 lines
it was a bunch of tricky to get it working correctly...seems that fpc and freedos are not quite good friends yet...fpc AND freedos relies on the same env var for completely different things....both of them have the CFGFILE var...to fpc it means the fpc.cfg standard configuration file....to freedos it means the standard config.sys-like file...the (temporary) solution was to unset the cfgfile to freedos and let fpc use it in his way then setting it again for freedos...is there a better solution in the sense of changing the makefile (or makefile.fpc) on the fpc side??

If necessary the Makefile can be changed to use a different variable.

Daniël

P.s. I think this discussion should be moved to fpc-devel.

Reply by email