hmm, reading a buffer and then summing all the values of the bytes in it.

suspicious behavior.

okay I think it has a very simple 1-byte CRC check on the chunks, which are optionally not run.
I can't make the math work but I'm reasonably sure that's what it is

okay they're using a blit that's UI-aware, so it starts the coordinate system at (1,13). Fun!

looking into the blitting code I managed to steal the world map out of RAM

ugh. TODO for my eventual Good DOS Debugger:
Instant Video display.
I don't know exactly how DOSBox-X is doing it, but while single-stepping the debugger, the display never updates. I can dump the ram at A000:0000 and see what updated, but not on the screen in DOSBox

found a suspicious array, which goes:
[
(-1,0),
(-1,1),
(0,1),
(1,1),
(1,0),
(1,-1),
(0, -1),
(-1,-1),
(0,0)
]

POP QUIZ: why does the font renderer need this array? how are they being "lazy" with this array?

there's also this code in the for-loop that steps through this array:

if index==8:
color=white
else:
color=black

@dividuum got it:

they're drawing the font 9 times, offset in each of the 8 directions, and in black. then they draw it in white, with no offset.

It's a pixel-outliner! By drawing their pixel font offset in each direction, they get a black outline on their font.

The Answer to the DRM questions for Where in the world is Carmen Sandiego? Enhanced (DOS, 1990) are, in no particular order:

23
Kent
dragon
calcium
1796
Warren
revenue
1792
Willard
1937
Crater
Tanzania
Hartford
Duluth
London
Gem
Silent
squeaker

if ((0x80 >> ((byte)local_4 & 7) &
(int)(char)*(byte *)((int)((int *)param_1 + 1) + (local_4 >> 3))) != 0) {

COULD YOU USE SOME MORE CASTS MAYBE?

oh it's because ghidra's near/far pointer support is shit.

I had param2 defined as a byte*32 and it was casting it to a byte* before using it

if I define it as byte* and let the calling convention implicitly define it as 32bit, it doesn't do the cast

well I found the decompression method.

as always, I hate it. decompression routines are probably my least favorite thing to reverse engineer

I think this compression is specifically designed for ASCII text, which is annoying because they've also got compressed images... which probably use a DIFFERENT COMPRESSION!

it looks like this chunk has length 256, which means 253 usable bytes, and it expands to 374 bytes.

Not the greatest compression. a little better than just doing 6-bit ASCII.

it's some kind of shifting bit mask but it starts at encoding values in 4 bits, then it can increase (or decrease, I guess) based on the input stream.

then it has an output filter, where if the number specified wasn't 8 bits, it's actually an index into a predefined text table

the predefined table starts with NUL, space, then:
aetonisrdlhugfcwypbmk,vSA.T'PMxBCIRGDWHqE-zNFKL0j:51YJ8\U?73Q;2!469
\r\nOVXZ()*+"#$%&<=>/@[]^_`

given that the most comment symbols are near the beginning, this is presumably a sort of lazy huffman coding

but I've got the predefined table, an input file, an output file, and now I need to write some python code to replicate this, hopefully without crying

"vs ses oa is isgit's tc eital and largest t u anhtA ttggh os nnotosnhrdsmarosogdn ss drte tishoth's isdhsceohtsnthminder of isgit's t nuorhdhtpast\x00 geru is slightltsn oaller than ndhd na and is o nnsgtgstbtst oa dotlalssaaolootbiaoht Sal gh, sonuhvia and sl ghh\x00isgit, ontvdn ss nhsiaalgarsnadlfnaatawlarst oadrlhrs i is a rugged land dooousr'casrbhe nrdsgs fountainsnht iah"