I should just check. I'm sure disk images can be tracked down in places.

the video and audio detection seems to be excellent, by the way. it just silently figures it out, without asking questions or requiring special arguments or configuration.
Perfect for a game aimed at the little childrens.

I found two different copies of the disk images, in different places.

both are imaged off a 3.5" disk version, which of course comes on only one (double density, 720kb) disk!

That version has no installer. Just the usual files (and a "DESKTOPD.CFG" file that I don't understand)

I did not realize they implemented a file browser in this program! I only found it by hiding all the DAT files from the EXE, to see if it'd ask me to put in floppies in.

So I've got code at 17DA:08AA, which is E8 5D F7. DOSBox decodes that as CALL 000A.

Manually decoding it myself, it should be a relative jump, and it's a jump to $-0x8a3. following the jump it ends up at 17DA:000A.

BUT GHIDRA thinks this code is at 1fb7:08aa, and it decodes it as call SUB_2000_fb7a, which doesn't exist.

I'm not sure how (0x08aa+3)-0x8a3 = 2000:fb7a. Something weird is going on. Why is the number BIGGER?

the +3 is because E8 5D F7 is 3 bytes, and it goes off the address of the next instruction

Ghidra even recognizes there's a function at 1fb7:000A! It's called VideoDetect

eww. They're using the NEAR version of CALL to call a FAR procedure.

You might say "wait, won't that break when it tries to do RETF?" and yes, it would, unless they manually do PUSH CS before they call it!

I think this saves one byte?
a call FAR absolute would be 5 bytes for the call, whereas push CS + call NEAR is 3+1 bytes

I might have to make a NASM test case. This could be Ghidra fucking up at decoding this one instruction

similar things in the test.com file. I moved stuff around in the memory map and it's not erroring now. I've probably created endless glitches elsewhere though

Anyway it seems it doesn't have a VideoDetect function, it's a DriverDetect function, since it's used for sound too.

First it goes through the video drivers in the following order:
VGA, TGA, EGA, HGA, HERC, and CGA.
Then it goes into the audio drivers:

stdsnd, adlib, covox, gblast, ibmg, sblast, tandy.

stdsnd is pc speaker,
adlib is adlib, covox is the speech thing, gblast is game blaster, most likely, ibmg is... I'm not sure. The PS-1 Audio card?

sblash is soundblaster and tandy is tandy 3-voice

I'm an idiot, this isn't a driver check... it's an argv check!

you can pass "ega" or "vga" or whatever to carmen.exe to select those types.

the other argument you can pass is ROSTER=$FILENAME

This lets you reset which file it uses for the list of registered players, setting it to something other than the default ACME.DAT

Not mentioned in the manual, but I can see how that might be useful for schools and such

I would say "especially if they're on a network!" but... this program is from 1990. Not many schools had networks in '90.

looks like GameBlaster (GBLAST) has extra options, so you can do like GBLAST260 to set the IO addr

stdsnd can also be written as stdsnd! which does something different. What? I have no idea.

ugh. I pulled the thread to try and remap the memory to avoid ghidra disassembling it wrong, and it keeps getting worse. this is a mess.

okay I reverted back to my old mapping, then created a new memory mapping: I made up some bytes at 2000:xxxx where it incorrectly thinks it's going, and set up a JMP $CORRECT_ADDRESS there by editing the bytes, then telling Ghidra it's a thunk.