I'm kinda surprised they're so dithered. with the support for EGA/MCGA/VGA monitors, they could have pulled something like sierra did and encoded the dithering into their compression. Then when they're displaying on higher-colordepth displays they could swap it out for an intermediate color.

that'd also help because then they wouldn't be compressing dithering

maybe they just mastered these at 16colors so they couldn't easily see what it'd look like

Would you like to visit the Sport Club, Marketplace, or THE ASCENDING TONE OF INFINITY?

it has been zero days since Ghidra has done something I can't understand and seems to be obviously wrong.

I've got B8 B0 26: this decodes to mov ax, 0x26b0. a 16bit immediate, moving into a 16bit register.

ghidra disassembles this as:
b8 b0 26 MOV uVar1 ,0x26b0

uVar is defined as a ushort: a 16bit type.

all makes sense, right? 16bit to 16bit!

so ghidra decompiles it as uVar1._0_1_ = 0xb0;

that's 8-bit to 8-bit! where did you get the idea this is 8bit, ghidra?

the most annoying thing?

this is picking between two strings to display, and those strings are "he" and "she".

EVEN IN 35 YEAR OLD COMPUTER GAMES I CANNOT ESCAPE GENDER PROBLEMS!

Since they devoted an entire word to gender, we can truthfully state that Where in the World is Carmen Sandiego? (enhanced, DOS, 1990) believes there are 65536 genders.

unfortunately due to an oversight it believes those 65536 genders are allocated as:

0: He/he/Him/him
1-65535: She/she/Her/her

I've made a note to fix this, of course.

BTW, my plan for expanding the program is simple: I'm gonna bypass a lot of code/data, by stuffing my own allocation into the memory space of carmen, which'll load extra data off the disk, in a CUSTOM.DAT file

this'll be (relatively) easy to do, since it turns out this program only needs 432 KB, since it targets a 512 KB RAM machine.
Since it's no longer 1990, I think I can safely bump that up a bit? I won't need more than another 64 KB, which means I'll just bump the game up to 496 KB memory required. Completely doable in any 640 KB or more machine!

my added code will just load the CUSTOM.DAT file off the disk, and then inject pointers to it in the rest of the program.

the applyPronouns function lets you adjust how it's encoded dynamically. Fancy!
So how it works is you do something like this:

applyPronouns("\80 was bald", 0x80, "he\0him")

and it'll return "he was bald", right? But it's more than just a simple find-replace...

Because you can do:

applyPronouns("I saw \81. \80 was bald!", 0x80, "he\0him")

and it'll return "I saw him. he was bald!".

See, you can specify multiple replacements at once, by using \x80, \x81, \x82 and so on.

The way it actually works is the game uses "He/he/Him/him" for the pronouns, so \x80 is uppercase "He", \x81 is lowercase, \x82 is uppercase "Him", and \x83 is lowercase.

trying to figure out how to properly decode the fonts in this game is REALLY reminding me why I constantly cheat with The Death Generator. Staring at a decompilation/disassembly and hex editor is no fun

it makes some sense that I'm having trouble with it. I think it's technically DOUBLECOMPRESSED