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.

this is deeply stupid but it appears to mostly work

THE MEMORY ADDRESSES ARE OVERLAPPING AGAIN

this isn't supposed to be possible but apparently it is

so the program has three main code segments, as it has approximately 111kb of code
The problem is that ghidra gets confused when the relative addresses are too big.

so the first one is at 1000:0000 and the second was at 1fb7:0009. I moved it to 5000:7000, and the second segment seems to be working fine now.

the problem is that I was only able to do that because the segment is only 82a7h long. the first segment, the 1000:0000 one, is FB79 long. So I can't just move it so it's in the middle of a segment, since it'll end up spanning into the next 64k chunk, which is where ghidra fucks up

I guess I could test it anyway. Move it to 9000:8000 and see what breaks. (like everything)

9000:8006 9a d7 05 b7 1f CALLF SUB_2000_0147

Hey ghidra I can read the machine code. That's CALL FAR 1fb7:05d7, not CALL FAR 2000:0147! WHY ARE YOU CONFUSED BY THIS?