I don't know if I'm weird or if it's just normal to get random reverse engineering urges. like right now I have like 5 major RE tasks I'm halfway done with, I'm hacking a bunch of games (and more interesting things), but my brain is just like "you need to reverse engineer a game that uses a software 3D renderer"
@foone I like reverse-engineering stuff, but once someone gave me a job doing it, and I hated it. I only like reverse-engineering things I'm interested in, and not on a schedule.
@brouhaha yeah, same. I think I do way more RE on my own than I would if I had a full time job doing this.
that said, I still wouldn't turn down a job doing this, it's just impossible to find 1. a job 2. a RE job that doesn't make me want to die just looking at the industry
3D game ideas I might could hack on for just why not reasons: 1. MindTrap (it glitches on later windows, would be nice to fix it, even if no one but me cares) 2. Betrayal at Krondor: The overworlds are cool! 3. Abrams Battle Tank by Dynamix/EA ? 4. 688 Attack Sub
Echelon was technically the first video game I ever owned. Shortly after my family got our first PC (a Heavily Used Packard Bell 486), my dad picked up a copy at a thrift store or something. I never beat the game, especially because it only had a 50/50% chance of launching on my PC
okay so I set a interrupt breakpoint (bpint in the DOSBOX debugger) on AH=3D, and AH=0F. Those are the two main ways to open files on DOS, the early way (0F) and the later way (3D). Flew around until the game pauses, and it's trying to load A2.ARE
Each .ARE file is only 3 kilobytes so all 36 of them only use up 96 kilobytes, but this game was born on the c64, where that was more RAM than the whole system had
@grumpygamer well I did pirate this version of the game, since I'm too lazy to go find that 5.25" disk in my storage unit, so technically all these files are .ARR files!
it seems to only render the first half and then the rest is gibberish. I bet it's something to do with these files being multi-format, since they have to encode the image for VGA/CGA/Monochrome
CMP files seem to contain object info, since I see text in them.
the game supposedly has 240 objects on the map, which can be transported onto your ship when found. Some are useless, some are clues to The Main Puzzle, and some are instant death bombs
ahh. so it's got a string in the EXE that's A0.ARE. Then it has another string that's 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ. So when it wants to load area N, it indexes into the Nth item of the second string, then shoves it in over the 0 in A0.ARE and opens that file
Ghidra: I support disassembly of 16-bit DOS programs! also Ghidra: WHAT THE FUCK IS "DS"? all segment-relative poitners are aimed at segment 0000, right?
the calling code changes the data segment to one just used for your specific buffer, so you don't need a pointer, it's just in the implicit state of the processor. you just work from 2
okay I haven't checked against the actual output (since I haven't gotten the actual output yet) but I think this isn't huffman, it's not even regular RLE, it's Very Simple RLE: You can represent all bytes 00-7F normally, but if the high bit is set, it instead means "repeat this many zeros"
the files have a 2 byte header that's ignored and not checked, then a number of things. those things are 6-byte chunks that get copied into the buffer above 0x1427. No idea why yet.
It seems the way the function works that it's passed a buffer as DS, then it loads the file starting from address 0, and writes that into 0x2CEF and up That's 11k into the buffer, so well above any real file.
okay I'm following through the decompress loading A3.ARE. I can see in the data segment we've got the data in the file, but up at 2CEF? all zeros. now if I wait for this function to return, that should get filled out
NOPE I'm completely wrong. They've got ES and DS pointing at different segments. 2CEF is the start (I guess?) of the output buffer, in a different segment
so when the game launches it asks me what video mode I want (Hercules, CGA, Tandy/Amstrad, or VGA) and then asks me to insert the data disk. This is not fun, since I always give it the same answers. So let's fix that
anyway for now I can just skip the disk swap check by patching out CALL DiskSwapCheck, since it has no side-effects. The video mode check unfortunately does, so I gotta leave it in but hack it to think I said "VGA"
I think this was written with a macro assembler by someone who loved macros. Like there's a lot of times where the code would be like LEA EAX, SomeString CALL PRINTF
in a saner world, but instead there's a loop that uses global memory addresses and calls the BIOS TELETYPE OUTPUT call letter by letter. and that loop appears in every function that needs to do printf()
the way ghidra handles interrupts is profoundly broken and someone needs to fix it. someone might have already, I just haven't installed that incomplete dos loader
@indigoparadox Technically, yes, but it tries to hide that from you. As long as you don't need to debug into what the DPMI calls are doing, you can mostly pretend segments aren't real
@foone Does 32-bit DOS with a DPMI use segments and overlays? It feels like it would be overkill since the whole idea was to get a 32-bit flat address space, unless you start doing weird stuff like unreal mode. :thaenkin:
the RLE compression seems to only affect the first 256 bytes of the file (after the 6-byte chunks). fucking weird. But I wrote some code that does the same, and it matches.
@foone can you figure out what the bug was? I assume they intended to compress everything but some bug prevented it but they didn't pay too close attention. But what bug would that be? Is there an obvious if or mask in the "correct" implementation that would cause this?
I think the map format might be tile-based rather than wireframes. You see (on the map) how the rocks in the sector to the bottom-left are the same as the ones in the top-right? That'd make sense if it's just a single value selecting what set of 3D geometry to stuff in the square
okay I think that 6-byte-chunks thing at the top of the file is items. I went and sat on top of an item, then edited the file so instead of 5-chunks it had 0, then reloaded the area (by hyperspacing out and then back in ) and suddenly the item is gone
yeah I narrowed down the item I'm floating over to one specific chunk. I set the last short in the chunk to 4312 and the item changed Z coord to (approx) 4761.
The value was original 4615 and it was at Z coord 6794. ugh.
ahh. I think it's (effectively) using big endian numbers. See, the coordinates aren't linear X/Y, they're "which sector" and then (maybe) "where within the sector".
okay this is weird. Byte 3 is the x-position within the sector, and it can have (valid) positions between -19 and +19.
If you go above or below that range, it'll get placed into neighboring sectors, which fucks up the game's item detection. It only looks in the current sector for items, but it won't see an item that's one sector over but positioned at -50
so the game works by only having a 3x3 sector grid rendered, but those sectors are inside of Areas, and it can only have one area loaded at once. So if you're at B02, you have A01, A02, A03, B01,B02,B03, C01,C02,& C03 loaded.
but it can only have on area loaded. So when you're at A01, you should have parts of three other areas visible... it solves this in a silly but simple fashion:
when a sector isn't loaded it's rendered like it's there anyway, but empty.
So when you're at A05 and looking west, you should be seeing what's in B14. And you are... because B14 is empty. The stuff doesn't start to B13, which you can only see by traveling into B14 and loading that area instead
the program seems to do some kind of self-modifying code and then it ends up overwriting actual code with gibberish which obviously doesn't work and we end up in an infinite loop of invalid instructions
@old_angry_queer Keen 4 was my third game! It would have been the second, but I couldn't get it working. I had to wait a couple months for my grandma to visit and use her DOS SKILLZ to figure it out form e
@foone technically my first game was "Dracula" for the C64 (although i only got to play it once since i didn't have a C64), but my real first game was Keen IV (shareware from the grocery store) for my Leading Edge 486.
dude! I was just reading the Echelon manual and you can send off to Access software, for 5$ (plus 0.50$ shipping and handling) they'll send you a COMPLETE patrol zone map, with all areas filled in!
It's only been 37 years or whatever, you think that offer is still good?
ANYWAY I looked through all the echelon copies on eBay, none have the filled-out map (or if they do, the owner doesn't know, because they're still sealed)
I missed that there was a -l option to UNP for bigger memory blocks, which makes it "succeed" at decompressing. I say "succeed" because running the resulting EXE causes an immediate crash to IBM ROM BASIC NOT AVAILABLE
@foone@SDoleMelipone The C64 version shipped with the Lip Stick, though. This was sold as a sophisticated voice activated system that increased the game's immersion.
It was effectively a Clapper attached to the Joystick 2 fire button.
So, yeah, maybe you're right about the better port...
I recall sending Access a few dollars to get the filled out map, but they'd already gone out of business by then.
@foone@SDoleMelipone I wonder how it was implemented there. I don't know if I ever saw dual game ports on the PC. But then, by the time I was looking at PCs, I think it was a feature of sound cards.
@mdwyer@SDoleMelipone good point, I'm not sure how it worked. Possibly a joystick pass-thru? It'd be dead simple to implement, since there's no "protocol", just a wire you'd need to connect to 5v