It most likely needs dynamic core (there is an experimental patch for that somewhere) and a much faster cpu I guess 😉
Other than that HOW does dosbox fail to run it? There are many different ways 😉

"patch somewhere"... not helpful.
About "much faster cpu": I expect the game to be runnable, not necessarily playable.

It fails on loading game: (looking inside DOSbox window)
KB_Startup: Keyboard Started
Compiling: 'GAME.CON'.
Including: 'DEFS.CON'
[nothing]
...
stuck

Well, instead of me searching here, I expect you to search here, I don't keep track of patches. But look in the patches subforum it might be there.

Are you sure duke uses the same mountings as on the pc?

The ARM dynamic core has recently been updated in the DOSBox SVN tree (in fact exactly one month earlier), and it takes advantage of ARMv7 instructions now. So it may be good to try and construct an SVN build: http://sourceforge.net/p/dosbox/code-0/

Well, I was wrong.
The game started, but after many minutes (at least 20+ minutes).
So the problem is not emulation correctness but rather performance on ARM, which is very slow.

Better get a native duke 3d port

Compiled DOSbox SVN. Same performance as 0.7.4 (using "auto" core).

Try setting core to dynamic. But nothing is really gonna help with games like DN3D except a fast processor. Late Dosgames need a lot of power in emulation.

FenixNBK wrote:

Compiled DOSbox SVN. Same performance as 0.7.4 (using "auto" core).

The arm dynamic core is not autodetected in compilation - it has to be enabled manually.
After running ./configure (before running make), edit config.h and change following definitions:

1#define C_DYNREC 1
2#define C_TARGETCPU ARMV7LE
3#define C_UNALIGNED_MEMORY 1

But even with dynamic code, dosbox might not be fast enough to run DN3D.
You could try a native port, for instance EDuke32 - http://eduke32.com/