it has been 0 days since foone has foolishly tried to hack a decompression algorithm.

well my "ignore the problem" solution of using bochscpu to embed a 16bit x86 emulator has failed. it's somehow broken and it's broken in the rust library or C core, not the python, and I really don't want to have to deal with debugging this.

time to switch to a completely different x86 emulator? PROBABLY!

unicorn has great documentation.

at least I assume it would be great, if it existed

x86 16bit segmentation and regular expressions:

BECAUSE FUCK IT

I'm implementing unicorn as an x86 emulator to do the decompression, but I'm single-stepping the processor and I'm aiding debugging by showing what instruction I'm on.

but instead of having to set up an x86 disassembly engine, I'm just parsing a plain text ghidra dump of the disassembly. I'm parsing it with regexes

it's too bad python's ctypes doesn't support 16-bit x86. it'd be handy right now

my latest bad idea: DUMBPATCH.

to avoid the complexity of generating functions and mapping them into the address space of the emulated PC, I instead designed a simple syntax:

a 16bit segmented address plus a number. that function is emulated as if it returned that number in AX. There are no other options. I suspect I'll be able to emulate up to 80% of complex subfunctions with this one bit of functionality

I need this because the decompression routine I'm emulating isn't entirely standalone: it calls malloc() at the beginning and free() at the end

so I'm replacing malloc() with a static value and free() with a return value no one will check

ideally I should be able to patch arbitrary python in there and do some kind of interop to return values to python

but that's hard. and way easier unflexible thing this is 80% of what I need that for

I forgot about callee cleanup. fucking stdcall is callee cleanup. I can't have a generic int blah(){return 0x1234;} function because it needs to know how many words of arguments were pushed.

RELOCATIONS!!!! *shakes fist at sky*

I took a look at the 1985 version to see if it had any other graphics command line options (it doesn't), but I did discover in passing that it uses a different pronoun system than the 1990 Enhanced version!

It uses @0 for "He/She", @1 for "he/she", and @2 for "his/her".

hacking a computer system by changing my pronouns to they/them so that it'll use up more memory composing strings referring to me and overflow the buffer

Where in the World is Carmen Sandiego? (1985) has an invert-y-axis option for the joystick, just in case you want to use flight simulator controls to navigate a menu

back on hacking Enhanced, DOS, 1990.

My best guess is that this game has between 4-6 compression algorithms, depending on how you count them. Possibly more are hidden in the bowels of this program.

that may be only the IMAGE compression algorithms, and they use a separate different compression algorithm for text.

everything is going WONDERFULLY

this is not the game to do it with, but I really wanna try swapping out the drawing routines for one of these games once. go into a VESA mode where I can run at 1024x768 or something, and just make the drawing write to that buffer instead. Could I make BIGSCREEN DOS GAMES?

maybe I'll try it with railroad tycoon sometime. that game has loadable graphics modules. if I figure out enough of how it works, I could write my own driver for VESA Railroads