They initialized the SoundBlaster DSP backwards.
You're supposed to send a 0 to the reset port, wait 3 microseconds, send a 1, then wait up to 100 microseconds for an 0xAA to show up on the data port.

They instead send a 1, then a 0, then immediately start trying to read the data port.

they read from the ports instead of measuring time, because that'll take a certain amount of time on x86. I'm too tired to confirm if their timing logic is sound. It's possible they're just assuming the PC is slow enough that it'll wait long enough

I bet broderbund bought this sound code. It feels completely different: This was either compiled on a different compiler or was written in assembly.

yeah a compiler doesn't just start using CF to return bools instead of AX. This is assembly.

they're passing single bytes to functions! C widens integer parameters to a word, so on a 16bit system, they're passed in 16-bit registers.

they're sending a... internal soundblaster test command?
(DSP 0xF0)

I dunno why this code is like this.

I suspect there may be an issue here: I identified a variable as containing the Soundblaster IO port, right? and I'm assuming everything that uses it is Soundblaster code.

But it may just be "soundcard IO port" and there's other sound device code mixed in here. So that's why some of it doesn't make sense as soundblaster, it's actually tandy 3voice or something

I just found a function (inside another function!) that's a fixed delay. How long is it?
it's a loop that runs 256 times!

that's so cute that this code considers "256 instructions" to be a meaningful length of time.

there's code in here specifically to detect if it's running on an IBM PS/1 by looking at the CMOS area?

WHAT THE

the menu system limits menus to having a maximum of 32 items.

which is weird because ONLY 17 WILL FIT ON SCREEN

I did some experimenting with MSVC 5.1, and it's weird. I get the same strings in the exe as carmen.exe has, but the code itself looks completely different.

either I set up my compiler wrong, or this game is full of assembly even for very simple functions

I don't know exactly what this function does (I know it sets some flags based on something in the graphics context) but I DO know one important thing about it:

they included it in the final binary FOUR TIMES.

byte-identical.

this is a compiler & linker from 1988, it doesn't understand how to merge identical copies of functions apparently

I found another function which has 4 copies.

I'm starting to suspect this program originally had 4 C source files and the linker wasn't optimizing this

wait I bet it's drivers!
like, one version of this function is called by VGA_DrawFuncUnknown and nothing else.
Another one? CGA/Hercules.
the third? EGA
The last? Tandy.

They compiled the 4 video drivers separately, and then linked them into the EXE, with no deduplication across compile units

yeah. Found another: VGAMalloc is the same as CGAMalloc (and Hercules doesn't have it's own HerculesMalloc, because it's in the same code unit as CGA: So it just uses CGAMalloc)
Tandy has TandyMalloc.

But not EGAMalloc. That one is completely different.

the DrawLine API is weird.
To draw the horizontal underline for the hotkeys in the menu, it calls DrawLine(0, -width).

It's DrawLine(int y, int x), and yeah you pass negative numbers

it's also off by one.
because 0,0 is silly, you're always drawing at least one pixel. So DrawLine(0, -5) draws a six pixel wide horizontal line to the left

PUSH BX
PUSH ES
PUSH SI
CALL StartPlayingSound
POP BX
POP ES
POP SI

since when has the x86 stack been FIFO instead of LIFO?