It's just funny because this is, like, technically wrong?. These aren't PC disks, but the difference doesn't matter, so why not?

It probably saved them a decent amount of money because of bulk discounts and inventory simplicity.

also after all this wondering about "how many disks does Carmen Sandiego Enhanced (1990, DOS) come on?" is even sillier because I ALREADY KNEW THE ANSWER, I JUST FORGOT I KNEW IT

I am currently, as in this very thread, reverse engineering Carmen Sandiego Enhanced (1990, DOS)!

I've seen the code that asks for you to put in the other disk! And it only asks for DISK1 and DISK2!

just looking at the files, not the code (and not having seen original disk images yet that I can recall), I bet the answer is that they put CITIES.DAT on DISK2.
the whole game - cities.dat is ~300kb, with cities.dat being 168kb.

They could do the whole game - carmen.dat and cities.dat in only 200kb, which'd give them 160kb (luxury!) for a fancy installer.

This game autodetects everything (video and audio modes) and you can install it by just doing "copy A:*.* C:\CARMEN" on each disk, so I don't think they would have needed a fancy installer.

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