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?

well, if nothing else, I think this has caused it to stop thinking there's jumps into the middle of functions.
so now I can just manually thunk every cross-segment call, by creating the 2000:0000 segment that ghidra is imagining exists

I'll have to write some code to find all the CALL 2000:xxxxs and set up matching thunks

I have discovered the bellhop island of stability

I was extracting the portraits of the people you talk to, and it turns out they're number 1-36. naturally I checked all 256 possible options.

but it turns out every thing above 37 either:
1. crashes
2. shows nothing
3. shows pixel gibberish.

EXCEPT 238. 238 renders a bellhop perfectly, just like 5 does

All 36 people you can talk to in Where in the World is Carmen Sandiego? (enhanced, DOS, 1990)

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;