Try to Compile Doom Legacy for DOS

[Marty2Doom]

Hello,

 

I would like compile Doom Legacy to DOS. The problem is i have  no idea which excact DJGPP gcc tools i need.

The Readme tells for DJGPP 2.02 but which version of Make,Gcc, etc..  should i use.

 

I would like to compile v1.42 and then newer. So i start with the last version for DOS 1.41.

 

I got the things from Delorie DJGPP Website. The last make version causes a cwsdpmi crash on every vm.

I took then the previous version. Then it still needs libsocket 0.7.4. As it turns out, it was later renamed to v0.8.0....

 

Then I still have a problem with the LibBCD (-lbcd). in the readme of Legacy, the BCD 1.03 is included. After the blank compilation of Legacy 1.41 this lib does not exist. I searched the Inet for it. I only found BCD 1.02 and version 1.04. But where is the version 1.03 now?. I'm looking for exactly the library. I keep getting errors about undeclared external variables like lowest_tracks, hightest_tracks and the missing external reference tracks structure.

 

For Nasm. I found 0.98.31. Later version changed the format.. any..

 

I tried to compile for 2 days and searched the internet. A couple of times it worked to compile Doom Legacy under Dos. Manual Editet the bcd.h. However, my exe is 3.5mb and the one in the legacy archive is 1.xxmb. Mine doesn't start either. This then crashes with countless cwsdpmi erros.

 

 

 

How was version 1.41 compiled under DOS?

 

greetings

Edited January 6, 2021 by Marty2Doom

[Marty2Doom]

After Hours ...

 

I Successfully compiled v1.42 with bnu211b, gcc302b, mak3791b ...

if i use the -m (march) how -pentium/-m386-m486 in the makefile i become crashes with countless cwsdpmi erros. If i remove it. It works. Now i test newer GCC versions

 

[Redneckerz]

Summoning @wesleyjohnson for this since he often mentions that Legacy has a DOS port but he cannot test it. Thus these results might be interesting for him.

[Marty2Doom]

I upload later my complet Enviroment Archive. He can look and Test it. He definitely has more in-depth knowledge of DOS programming.  Now GCC 3.41b (~ Released 2005) is the last successfully result with -o3 and -mtune=i586.

Versions after 3.41b brings "use of cast expressions as lvalues is deprecated" as error and not as warning.

[wesleyjohnson]

Thank you for trying the DOS compile.

I have been looking for some compilers for DOS, but all I seem to have is an old Pascal (circa. 1983).

 

For the project, the main interest would be upgrading the code to support the newer compilers, as that is mostly likely what some user would use.

I also would like to support compiling and running on FreeDOS.

 

Compiling the 1.41 and 1.42 versions first is a good idea.

 

In 1.48, the code under the djgpp directory has been blindly updated over the years, without a chance to compile or test it.

I would be surprised to hear of it compiling without errors.  I must have made at least a few errors over the years.

Please submit a bug report at SourceForge for any code errors that are found, as that allows me to use the bug reporting tools.

https://sourceforge.net/projects/doomlegacy/

 

Please note:

I have DOS 5.0, on 5 1/4 floppies, but the drives for reading those have been in the old hardware box for years.

I have FreeDOS (which got damaged during the motherboard failure somehow).

I have an old Win98, and a WinXP, which have MSYS and MINGW installed on them.  That is it for Windows.

Those each have a odd DOS.

 

I also have some DOS support books, and a Borland C++ compiler for Windows 3.1, on floppy disks.

 

Is cross compiling from WIndows an option ?

You did not mention what DOS or platform you were using for compiling, if it required some version of WIndows, or if it required MINGW.

 

I DO NOT have the usual IDE Windows compiling environments, as I run Linux, and have Linux based tools.

This WILL involve a bit of work before I can compile anything DOS.

 

 

Edited January 6, 2021 by wesleyjohnson

[Marty2Doom]

Thanks for your feedback :)

 

Using updated compilers and DJGPP with new Doom Legacy versions is pretty steep. First you have to find out which version is still working and which version is too new.

 

I am currently reviewing one version at a time. First of all, I use the programming tools that are in the readme of Legacy v1.41. So:

DJGPP 2.02

Allegro 3.12

Instead of libsocket 0.7.4 (beta 4), the LibSocket 0.8.0

bcd 1.03,

that turned something on that I can create a lib I checked out Github. It seems that many people BCD 1.03 have changed individually. That's why that irritates me too is in your readme. (inlcude in this package), Hm yes only the header file. Where is the lib and or bcd.c?

GCC 3.02b

nasm 0.98bf (new versions require a new format and the command line)

 

Now I'm with version

DJGPP 2.05 with the libc.a from DJGPP 2.04 .. hum. The 2.05 gives me undefined's _env_ things

GCC 3.41b

BinUtils v2.1.61b

Make v3.8.10

 

I was able to compile Doom Legacy Version 1.43. With asm, -O3 and -mtune = i586 what there is already a performance boost at higher resolutions under DOS. I think .. it feels like it or I lost the feel of the game with all the testing ...

 

I'm already happy to get this far as a noob.

 

The jump to Doom Legacy v1.45 Beta1 and yes that's right. From this version the incompatibility violently. So far I have not been able to compile 1.45. Definitely too many declarations and types that are not compatible and and and .... the list is long and starts with i_Video.c. I don't even know where to start first. Is it the GCC / DJGPP environment or the leagcy code ... i thin GCC and DJGPP + Legacy Code ...

 

Somehow I need the complete gcc output in a text file ... asked? how was the command?

 

Does it even make sense to post bug reports for old versions (Legacy 1.42 > 147 ) of DOS?

Somehow you have to find out which latest version of GCC under DOS is playing with it.

 

Because the last latest new make version crashes as well as some GCC versions. Such a really stable all-round carefree package probably doesn't exist.

 

Here are the DJGPP environments in the Dosbox (Portable) under D:\Bin is the finished compiled Doom Legacy version and otherwise just enter make

 

DJGPP (DJ202)(gcc341b, bnu2110b, mak3791b)(Legacy 1.42)

DJGPP (DJ202)(gcc341b, bnu2161b, mak3791b)(Legacy 1.42)

DJGPP (DJ202)(gcc341b, bnu2161b, mak3810b)(Legacy 1.42)

DJGPP (DJ202)(gcc341b, bnu2161b, mak3810b)(Legacy 1.43)

DJGPP (DJ205)(gcc341b, bnu2161b, mak3810b)(Legacy 1.43)

 

Now don't hit me but I think you need a Windows Enviroment.... :D

 

greetings :)

Edited January 6, 2021 by Marty2Doom

[Marty2Doom]

Note and Edits:

 

File Not Found Erros ... 
In the  Src directory, i renamed p_heretic.c/.h to p_hereti.c/.h
In C:\DJGPP\lib\gcc\djgpp\3.41\include\syslimits.h to syslimit.h

 

Under Terminating String and Compile Break fixed. From .. to

            if(ch==70)  // crtl-break
            {
                asm ("movb $0x79, %%al
                     call ___djgpp_hw_exception"
                     : : :"%eax","%ebx","%ecx","%edx","%esi","%edi","memory");
            }

           	if (ch == 70)  // crtl-break
            {

                asm("movb $0x79, %%al\n\t"
                    "call ___djgpp_hw_exception"
                    : : : "%eax", "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
            }

 

I can't Resolve this and try this to resolve at yesterday.

objs/i_cdmus.o: In function `I_PlayCD':
DJGPPDOS/i_cdmus.c:403: undefined reference to `_lowest_track'
DJGPPDOS/i_cdmus.c:403: undefined reference to `_highest_track'
DJGPPDOS/i_cdmus.c:414: undefined reference to `_tracks'
DJGPPDOS/i_cdmus.c:403: undefined reference to `_highest_track'
objs/i_cdmus.o: In function `Command_Cd_f':
DJGPPDOS/i_cdmus.c:187: undefined reference to `_lowest_track'
DJGPPDOS/i_cdmus.c:194: undefined reference to `_highest_track'
objs/i_cdmus.o: In function `hms':
DJGPPDOS/i_cdmus.c:75: undefined reference to `_tracks'
objs/i_cdmus.o: In function `Command_Cd_f':
DJGPPDOS/i_cdmus.c:75: undefined reference to `_tracks'
DJGPPDOS/i_cdmus.c:200: undefined reference to `_tracks'
DJGPPDOS/i_cdmus.c:201: undefined reference to `_tracks'
DJGPPDOS/i_cdmus.c:194: undefined reference to `_highest_track'
objs/i_cdmus.o: In function `I_PlayCD':
DJGPPDOS/i_cdmus.c:403: undefined reference to `_lowest_track'
DJGPPDOS/i_cdmus.c:403: undefined reference to `_highest_track'
DJGPPDOS/i_cdmus.c:414: undefined reference to `_tracks'
objs/i_cdmus.o: In function `Command_Cd_f':
DJGPPDOS/i_cdmus.c:403: undefined reference to `_lowest_track'
DJGPPDOS/i_cdmus.c:403: undefined reference to `_highest_track'
DJGPPDOS/i_cdmus.c:414: undefined reference to `_tracks'
DJGPPDOS/i_cdmus.c:420: undefined reference to `_highest_track'
DJGPPDOS/i_cdmus.c:425: undefined reference to `_highest_track'
objs/i_cdmus.o: In function `I_PlayCD':
DJGPPDOS/i_cdmus.c:403: undefined reference to `_lowest_track'
DJGPPDOS/i_cdmus.c:403: undefined reference to `_highest_track'
DJGPPDOS/i_cdmus.c:414: undefined reference to `_tracks'
objs/i_cdmus.o: In function `I_UpdateCD':
DJGPPDOS/i_cdmus.c:373: undefined reference to `_highest_track'
DJGPPDOS/i_cdmus.c:374: undefined reference to `_lowest_track'
DJGPPDOS/i_cdmus.c:376: undefined reference to `_tracks'
DJGPPDOS/i_cdmus.c:376: undefined reference to `_tracks'
objs/i_cdmus.o: In function `I_StopCD':
DJGPPDOS/i_cdmus.c:252: undefined reference to `_highest_track'
objs/i_cdmus.o: In function `I_UpdateCD':
DJGPPDOS/i_cdmus.c:403: undefined reference to `_lowest_track'
DJGPPDOS/i_cdmus.c:414: undefined reference to `_tracks'
DJGPPDOS/i_cdmus.c:382: undefined reference to `_highest_track'
collect2: ld returned 1 exit status

 

The Libbcd is in the lib(rary) directory from DJGPP.

The BCD Header is in the I_cdmus.c

The External Reference is in the BCD Header ans the Static Int is in the BCD.c. I have no idea and i tried many things.

 

HELP

 

 

greetings

[wesleyjohnson]

Since 1.44 there has been a compile control to disable all the CDROM music.

#ifdef CDMUS

#endif

This was added because some of the libraries used for CDMUS were obscure, and not many people actually used it.

I suggest you disable all the CD music code and the calls to those functions, rather than fight with an obscure

library that you probably do not need.  It will not affect playing Doom.

 

The CDMUS control in the ver 1.44 Makefile also disables the compiling of i_cdmus altogether, for djgppdos as well as the others.

All the calls to functions in i_cdmus are disabled by #ifdef CDMUS.

 

I cannot patch 1.41 or 1.42 for you, I can only fix 1.48.

 

Edited January 7, 2021 by wesleyjohnson

[Marty2Doom]

 

Hello and Hi there,

 

I found out. CD Music is playing. It would be a shame. Because my Dosbox Fork supports CUE (also separate tracks) where the WAVE / FLAC / MP3 files can be exchanged as well as the CHD (Mames Compressed Hunks of Data Format). So you can under DOS. Hear Doom remixes / remakes and covers :)

 

Since it is really crap with the isolated externals. I changed the bcd.c.

#include "bcd.h"

typedef struct {
  int is_audio;
  int start, end, len;
} Track;

static int mscdex_version;
static int num_drives;
static int cur_drive;	/* current drive - for use by mscdex functions */
static int cur_drive_no;/* index of current drive - for use by programmer */
static int num_tracks;
static int lowest_track, highest_track;
static int audio_length;

#ifdef STATIC_TRACKS
static Track tracks[99];
#else
static Track *tracks;
#endif
.  
.
.
/* Internal function to get track info */
static void bcd_get_track_info(int n, Track *t) {

#include "bcd.h"

struct Track
{
    int is_audio;
    int start, end, len;
};

struct LHTrk    /* lowest, Highest Track */
{
    int lowest_track;
    int highest_track;
};
struct LHTrk TrkOrder;

static int mscdex_version;
static int num_drives;
static int cur_drive;	/* current drive - for use by mscdex functions */
static int cur_drive_no;/* index of current drive - for use by programmer */
static int num_tracks;
//static int lowest_track, highest_track;
static int audio_length;

#ifdef STATIC_TRACKS
struct Track tracks[99];
#else
static Track *tracks;
#endif
.  
.
.
/* Internal function to get track info */
static void bcd_get_track_info(int n, struct Track *t) {

changed the lowest_track and highest_track to TrkOrder.lowest_track and TrkOrder.highest_track.

 

added to the bcd.h (Not the bcd.h in the djgppdos folder)

#define BCD_VERSION 0x0103

   /* uncomment this line to force BCD to use a statically allocated
	  Track array instead of using malloc */
#define STATIC_TRACKS

extern struct Track tracks[99];
extern struct LHTrk TrkOrder;

maked a libbcd.a

 

Change the bcd.h in the djgppdos folder

---------------------------------------------------------------- Removed
extern int lowest_track, highest_track;
/* uncomment this line to force BCD to use a statically allocated
   Track array instead of using malloc */
#define STATIC_TRACKS

typedef struct {
  int is_audio;
  int start, end, len;
} Track;

extern Track tracks[99];

------------------------------------------------------------------ Added
#define BCD_VERSION 0x0103

   /* uncomment this line to force BCD to use a statically allocated
	  Track array instead of using malloc */
#define STATIC_TRACKS

struct Track
{
    int is_audio;
    int start, end, len;
};

extern struct Track tracks[99];

struct LHTrk    /* lowest, Highest Track */
{
    int lowest_track;
    int highest_track;
};
extern struct LHTrk TrkOrder;

and changed the lowest_track and highest_track ints to TrkOrder.lowest_track and TrkOrdee.highest_track.

 

Now the externally declared variables work with the library.

 

Das ist die v1.43 (Die bei Source Forge nur als mac os version gibt)

Doom Legacy  143 (DJ205, GCC 3.41) (Asm and CD Audio Fix)

 

[Marty2Doom]

My next step is to verify the next versions of GCC in combination with the Source Forge Commits. So i can Report bugs at the later Versions. in my current version are a few lvalue deprcated warnings....

 

greetings

[taufan99]

Great effort there! Could you share the compiled source port files for curious DOS players alike to tinker on?

[Marty2Doom]

1 hour ago, InDOOMnesia said:

Great effort there! Could you share the compiled source port files for curious DOS players alike to tinker on?

 

See a post above :) But here again the link. Compiled version as well as complete development environment.

8 hours ago, Marty2Doom said:

 

Doom Legacy  143 (DJ205, GCC 3.41) (Asm and CD Audio Fix)

 

 

 

 

[SilverMiner]

1 hour ago, Marty2Doom said:

as well as complete development environment

Wow, it's cool to know that I no longer need to guess on "what compilers were used here" lol

[Marty2Doom]

2 hours ago, SilverMiner said:

Wow, it's cool to know that I no longer need to guess on "what compilers were used here" lol

 

May I help you :)

 

I can understand you. I was looking myself.

 

There are 60+ versions of the GCC Compiler. Not counting the Binutils and other stuff. Last week I downloaded all the stuff from deloroie and an x2ftp mirror. About 3000 files and then there were still files missing. So far found everything.

 

Then I hung around from year to year. That's why I'm usually also responsible for uploading the complete environment development archive. Especially if you still need the dependent libs.

 

But I think that as the commits progress with Doom Legacy, I have to update the GCC compiler. But keep up to date.

 

greetings :)

[taufan99]

3 hours ago, Marty2Doom said:

 

See a post above :) But here again the link. Compiled version as well as complete development environment.

 

Ah, sorry! Didn't see the link as the images are too large to scan through the post. You could try scaling them into a smaller size next time you post your images so as not to bury the text information between them.

[Marty2Doom]

@wesleyjohnson

 

Where is Legacy.dat 1.43 ? I found only 1.42 and 1.44 alpha1.?

[wesleyjohnson]

I believe that 1.43 was used to reconcile with macos and mach porting. 

I do have several versions of the source.

 

I am not sure which version is at SourceForge, but I suspect it is the original, without my patches.

https://sourceforge.net/projects/doomlegacy/files/Old versions/1.43/

 

I also have 1.44 source (90 versions), which is when many serious bugs got tracked down.

The last 1.44 source would be essentially 1.45.

 

The DoomLegacy site has full release history, including the 1.44 sources.

http://doomlegacy.sourceforge.net/

 

There are a number of versions numbers used for development, and some version numbers were skipped.

 

The latest version of the source has logs/ WDJlog.txt which has my entire revision history.

From that log file you can get the SVN number of every revision, and then can pull a copy of that source code at that point from the SVN at SourceForge.

https://sourceforge.net/p/doomlegacy/svn/HEAD/tree/legacy_one/

The legacy branch is actually Legacy2.

I recommend starting around SVN 595.

 

I started patching on 1.42/1.43 at SVN 544.

DoomLegacy 1.44 starts at SVN 565.

Doomlegacy 1.45 is  SVN 1103, which is quite a few patches since 1.42.

DoomLegacy 1.48.8 is SVN 1567.

 

[Marty2Doom]

Hello @wesleyjohnson

 

Big Thank for the Info. :)

 

I was able to update my version to r543. Compiled from and with the r543 now also with GCC 4.32. The 1.43 is MacOS only. I can not extract the *.sitx file. I found unar but this doesnt work beacause extract error with "Tag 1".

 

Edit: Definitely.

With the header files byteptr.h and m_swap.h and gcc432.zip in the revision https://sourceforge.net/p/doomlegacy/svn/543/tree/ with the comment "Compiles now GCC 4.3", Doom Legacy crashes at the the beginning of entering a Level (but not a Demo play) completely with a SIGFAULT...

 

I'll leave the two header files like that for now and keep checking ...

Edited January 9, 2021 by Marty2Doom

[Marty2Doom]

So ... was able to compile up to r554. For some of them, I had to fix the DOS version source without major changes to the actual sources.

 

With GCC 381. I have few warnings. With GCC 432 there are tons of warnings and crashes but not with GCC 381.

[AnotherGrunt]

On 1/6/2021 at 1:20 AM, Marty2Doom said:

I would like compile Doom Legacy to DOS.

 

Just out of curiosity, may I ask why exactly?

Edited January 11, 2021 by AnotherGrunt

[Marty2Doom]

1 hour ago, AnotherGrunt said:

 

Just out of curiosity, may I ask why exactly?

Because Doom Legacy still supports the DOS version. Just not checked. Because I think it's a shame that the code exists but can no longer be compiled and I would like it for Dosbox and at the same time want to see how it all works. Just hobby ..

[AnotherGrunt]

It was the first thing I've tried to compile in DOS few years back but I've deemed it to be too much broken. Just bug after bug preventing compilation. So I just simply gave up.

 

Are you aware there is already binary version just to grab, are you?

[Marty2Doom]

Just now, AnotherGrunt said:

It was the first thing I've tried to compile in DOS few years back but I've deemed it to be too much broken. Just bug after bug preventing compilation. So I just simply gave up.

 

Are you aware there is already binary version just to grab, are you?

Yes. I know the Binary. Its old. I compiled with GCC 3.81 r561 without Errors :). There was minimal Errors in Code in the Commit path to compile a DOS version and the CD Music works too. (I use a 35 Track Audio CD (CHD) )...

[wesleyjohnson]

Many of the patches that I have made over the years have been to make the code more compiler independent.

The 1.42 and 1.43 versions that I started with are sensitive to compiler interpretation.

The original code compiled with many warnings.

 

Over the years, each new GCC compiler would have more checks and give more warnings, that I would have to fix.

Will have to advance to SVN 590 to reduce most of those.

 

A major fix to memory allocation at SVN 593.

Some bad drawing code got fixed at SVN 595.

These would cause segfaults with some wads.

 

There also is the option of compiling a newer version and just turning the new features that you do not want to debug now.

Much of the non-standard stuff has an enable in doomdef.h.

 

Half of things that you are mentioning at not at all familiar to me.

 

I got the old Borland Turbo C++ installed to the XP.  It was on 5 floppy disks.

It has an IDE, and does compile.

Wrote a test program, that makes me suspect it is too different from POSIX to have much of a chance to compile DoomLegacy.

It seems to think that an int is 16 bits, at least the printf behaves that way.  I have to use declare ints as long, and use "%li" to print them out.

DoomLegacy pretty much requires that an int be 32 bits, and all printf of 32 bit values just uses "%i".

 

Currently working on linux_x problems.  Found the segfault cause is a video card buffer conflict.

 

 

[ETTiNGRiNDER]

52 minutes ago, wesleyjohnson said:

I got the old Borland Turbo C++ installed to the XP.  It was on 5 floppy disks.

It has an IDE, and does compile.

Wrote a test program, that makes me suspect it is too different from POSIX to have much of a chance to compile DoomLegacy.

It seems to think that an int is 16 bits, at least the printf behaves that way.  I have to use declare ints as long, and use "%li" to print them out.

DoomLegacy pretty much requires that an int be 32 bits, and all printf of 32 bit values just uses "%i".

I am almost certain that's because Borland compiles to real mode, not protected mode (which is what Doom uses).  To get Doom working properly in real mode would probably involve major restructuring and cutting it down to something like SNES Doom level due to memory restrictions and such.  Not sure if Borland supported any of the protected mode DOS extenders, DOS4GW was specifically a Watcom thing I believe (Watcom being the W in the name).

[Mr.Rocket]

Woah, Marty2Doom seems to be fixing history here.

[Marty2Doom]

Somehow something seems to have happened from r594 to r595. Since r595 and I'm now at r632 and Doom (Ultimate) (i test it permantly with these Games) freezes under DOS during gameplay. I can not fully understand now that this could be.

 

Edit: hmm.. does'nt happpend in Play/Time Demo Mode. Its running without Freeze.

Edited January 13, 2021 by Marty2Doom

[Mr.Rocket]

What new feature was introduced there?

Possibly the resource wad doom3.wad maybe or was it yet legacy.dat at that time had an update of sorts?

 

I use to follow Legacy back then but I'm not sure of its version history now.

Is there something in the way back machine of their site that might give a clue?

Is there a way to debug and step into other versions that may have something changed here?

 

[AnotherGrunt]

2 minutes ago, Mr.Rocket said:

Is there a way to debug

 

GDB.

[Marty2Doom]

2 hours ago, Mr.Rocket said:

What new feature was introduced there?

Possibly the resource wad doom3.wad maybe or was it yet legacy.dat at that time had an update of sorts?

 

I use to follow Legacy back then but I'm not sure of its version history now.

Is there something in the way back machine of their site that might give a clue?

Is there a way to debug and step into other versions that may have something changed here?

 

yep, doom3.wad was renamed to legacy.dat and then they decided to rename it to legacy.wad. Changes were made from 594 to 595 in r_draw8.c, r_plane.c, r_segs.c and r_things.c with the comment "Draw window clipping protection".