Xref: news-dnh.mv.net comp.os.msdos.djgpp:246
Path: news-dnh.mv.net!mv!news.sprintlink.net!cs.utexas.edu!geraldo.cc.utexas.edu!not-for-mail
From: ddt AT npc DOT ece DOT utexas DOT edu (Dave Taylor)
Newsgroups: comp.os.msdos.djgpp
Subject: Please help authors of Doom!
Date: 8 Jun 1995 14:12:25 -0500
Organization: id
Lines: 46
Nntp-Posting-Host: npc.ece.utexas.edu
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

Hello, I'm one of the authors of Doom, and for a while we've been
developing our next game Quake using DJGPP V1.  Our plans are to
release the game as a series of .o files and source code so that
programmers can write their own modules and plug them in during the
setup program which actually performs the final link.  We will be
including DJGPP on our distribution CDROM to make this easier for
people.  Note that we won't be releasing all the source code, just
enough so that people can write their own low-level modules to support
new devices.

The end result will probably be that DJGPP will find itself in the
spotlight this winter.  I'm excited about this and have let DJ use our
T1 ftp site as a distribution base for the V2 beta.

However, I am having a problem I could use some help with.  I want to
upgrade to DJGPP V2, but I am cross-compiling DJGPP V2 to OSF/1 for the
Alpha.  I have never done this before or even mucked around with
compiling gcc.  I have been keeping notes on how to do it properly.  I
am really really close, and the cross-compiler works.  However, the
linker (ld from binutils 2.5.2) chokes with:

/usr/local/i386-msdos-go32/bin/ld:djgpp.lnk:1: parse error

djgpp.lnk is the version that comes with V2, 950603, with the ^M's stripped.
The top line is OUTPUT_FORMAT("coff-go32").  I have tried replacing this with
"i386-coff" and "coff-i386" to no effect.

If someone could help me with this last step, I will post a DJGPP V2
Cross Compiling FAQ, as I found the process rather painful as someone
new to building a gcc cross-compiler.

Thank you for your help.

By the way, we really enjoy working with DJGPP.  It's a great package.
However, we have similar beefs about the inability to get directly at
physical memory, and not through using another selector or wrapper
function.  I would like very much to see CWSDPMI support fn 0x508, an
optional DPMI v1.0 function, but a terribly useful one because it will
allow you to elegantly map physical memory into your data segment as
though you're malloc'ing memory.  This is the only thing keeping the
compiler from making real-time app programmers blissfully happy, and I
hear that it may go in soon.  Just wanted to encourage that to happen.
It's so close to perfect!

	=-ddt->