Probably worth mentioning on the DJGPP mailinglist so unmangled DAT files can be uploaded in their place.

Turns out that the Allegro 4.2.2 sources hosted by DJGPP at v2tk/allegro/all422s.zip have mangled .dat resource files for SETUP and DEMO. Which was really a spanner in the works considering I was trying to test the sound card selection options and use the allegro.cfg it generates with the demo game!

If you download Allegro sources recommended by DJGPP’s Zip Picker and use ‘fix djgpp’ ‘make all’, it’ll stop when it gets to the dat2s stage of make (which converts the setup.dat containing the background and font graphics for the SETUP sound card selection program) into a .s const block of data for inclusion in the final setup.exe).

The sources for Allegro 4.2.3 from allegro.cc work nicely and have the correct .dats. (Though they don’t have the sb.c patch for SoundBlaster 1.0 which I need to apply.)

The SIGSEGV was (probably) due to a correctly compiled dat2s.exe not handling a malformed .dat gracefully. I initially thought it was a bug in the .dat code as any of the example programs that used a .dat resource file blew up, or some strange effect due to VirtualBox, but since the dat code was the same in .2+.3, I checked both source trees for weirdness and found that it was DJGPP’s version of all the included .dat files – they were all truncated and invalid (either accidentally or deliberately if the DJ maintainers didn’t want to distribute the resources due to size or licensing?)

It’s more so that the assembler supports them, not that it’s actually detected at runtime. It’s a horrible system in retrospect.

At the same time I’ve been using these toolchains to build Quake/QuakeWorld/Quake II for MS-DOS, and those I use native, and I’d want the higher level CPU support as I expected it running on a P4 or higher.

But great that it’s all done then!

I think it was the generated asmcapa.h falsely indicating that MMX and SSE were supported that was causing all my frustrating SIGSEGVs all along. After editing that file like you suggest I can compile Allegro libraries and examples fine in VirtualBox now.

The TESTS\TEST.EXE Allegro program reports ‘686 (GeniuneIntel) / cpuid / FPU / cmov / SSE / SSE2 / SSE3 / MMX / MMX+’ in VirtualBox, and ‘486 (GeniuneIntel) / cpuid / FPU’ in Dosbox.

I don’t know how Dosbox would end up with MMX and SSE showing up in its asmcapa.h from that… it’s possible that Allegro’s make process is misdetecting it since nobody tested it on real DOS 🙂 (I’ve got allegro compiling under Dosbox again now since I want to see what the generated asmcapa.h looks like. It’ll take a while though.)

This doesn’t explain why VirtualBox’s exes crashed before. I haven’t told VirtualBox to hide any capabilities of my processor (if that’s possible) so it ought to have MMX and SSE available to the guest. Maybe Allegro uses those instructions in such a way that isn’t compatible with how csdpmi sets up the processor/memory state? I don’t know much about this and I’m totally guessing.

As part of ‘make all’ in VirtualBox, makedoc.exe is crashing when handling allegro._tx but I suspect that’s an out-of-memory error or something like that if the help file is big, and it’s not important.

I’ll leave it there for now. Thanks again for the help.

It’s one of those things, that sometimes newer isn’t better. Just as compiling stuff to plain 80386 sometimes is better as the instruction set is probably emulated better when it comes to edge cases.

Great that you were able to get your build working for you!

Aha! This is great! I can compile and run both the DEMO and the SETUP just fine now, using Allegro 4.2.3 with those tips you gave. Thank you!

You can reproduce the Soundblaster bug yourself if you use SETUP in Dosbox and set the card to a SoundBlaster 1.0, Vol 200, Channels 8 and use Test. The default SB16 card in Dosbox autodetected by Allegro isn’t affected so most folks wouldn’t notice. I noticed this bug on my Yamaha Audician 32 Plus hardware first before I tried it in Dosbox, so I know it’s an Allegro fault. (Plus you can see the allegro.cc thread I linked to on twitter as well.)

If you want a really bad experience, use SETUP to select a SB 1.0 and then save the config. Then copy the allegro.cfg file the setup generates into the demo directory and run DEMO. The default Allegro behaviour is to read the allegro.cfg file in the working directory and use that to select the sound driver to use – this will let you play the demo shooter with the SB 1.0 driver, and it’s not very nice. 🙂

Aha! That’s amazing – will have to check this out asap. The demo is supposed to come with a pretty large datafile. It seems like all422s is the anomaly in that it has a weird stub instead of the full thing; I assumed that it would be built as part of the allegro library building process, but in all4310s and all423s there’s a 390k~ demo.dat that has the voice clips, graphics and intro fanfare etc. Try copying that into the same dir as your demo.exe.

(That’s actually how I got interested in this mess. When I tried Allegro on real DOS for the first time (I was around for the WinXP Allegro era mostly 🙂 ), I immediately hit upon the SB1.0 regression I recorded here https://twitter.com/SkullKidUK/status/1120242885960568832 and wanted to make myself a fixed Allegro that’d work on my real comp.)

I didn’t know that MMX was so late.

remember most MS-DOS based emulation stuff isnt going to do SSE or MMX….

type obj\djgpp\asmcapa.h
#define ALLEGRO_GENERATED_BY_MAKEFILE_TST

You want that to be pretty bare bones.

Anyways in Makefile.tst you can make it use ‘unix’ mode for echo to work right

# testing capabilities.
UNIX_TOOLS = 1

And when it comes to MMX:

test-mmx:
false
# as --defsym ASMCAPA_MMX_TEST=1 -o $(PLATFORM_DIR_U)/asmcapa$(OBJ) src/misc/asmcapa.s

likewise for SSE:
test-sse:
false
# as --defsym ASMCAPA_SSE_TEST=1 -o $(PLATFORM_DIR_U)/asmcapa$(OBJ) src/misc/asmcapa.s

I use the MS-DOS Player> to run the MS-DOS asmdef/dat2s parts. At it’s high end it’s basically restricted to 486 opcodes… so dont get fancy! 🙂

makefile.dj: msdos tools/dat2s.exe -p setup -o obj/djgpp/setupdat.s setup/setup.dat
makefile.dj: msdos obj/djgpp/asmdef.exe obj/djgpp/asmdef.inc

the ‘demo’ crashes on the line:

data = load_datafile(buf2);

I found that just by moving an exit(0) around the code… Not sure what is up with that, but there u go.

Anyways ex12bit, test program, playfli. So it’s not totally broken.

There is some weird stuff with the way it constructs the mmx test I recall doing it manually… Although it would say I don’t have it as my binutils is too old (and I don’t care, under full emulation why bother with mmx?)

Usually it crashes from stack and runtime mismatches.

I’ll have to try it later on if I can.

Same result with the 346 archive.

https://imgur.com/a/kukbMj3

This is the same error I get compiling allegro in VirtualBox or DOSBOX (with the latest DJGPP or the djdev gcc and binutils from 2007), or with either of your Windows djgpp compilers. I’m starting to think that I’m missing something else…