0000096: CE 5.5 Code finder identifies "funny" instructions

Notes
(0000208) Dark Byte (developer) 2009-02-01 19:03 edited on: 2009-02-01 19:04	Is shot2.png really like that or do you just hate me and removed the lines above and below the instruction with an editor just to spite me ? anyhow, in cases this happens it can be caused by a rep xxxx instruction (should be right after the jmp) because normally a breakpoint happens ce has to go one stap back to find the original called, but with a rep xxxx that isn't the case unless it was the last iteration If it's really like that I have no clue what causes it except a messed up dpi problem, but then I wonder why the middle one IS visible... Also, you mention it's running in dosbox, which means it's running under an emulator. finding what accesses an address will return the code of the emulator, not the game. (unless you play in real-mode emulation using ntvdm.exe)

(0000210) Csimbi (reporter) 2009-02-02 14:57 edited on: 2009-02-02 14:59	It's really like that, and it happens every time like that. Yes, DoxBox is an emulator. Your response about an emulator executing the instructions in the game makes sense, so I am happy to close this problem. It should be interesting to figure out why the rest of the code is not listed (the part you are missing from shot2). Edit: The game is available for download at abandon-ware sites, if you are interested to check it out for yourself, let me know and I will write down how I ended up with that screen shot.

(0000211) Csimbi (reporter) 2009-02-02 18:39	I found another one of these; Z: Steel Soldiers 1.41b. (See the SHOTS2.ZIP that I just attached above.) This is a windows game, so no emulator is involved.

(0000216) Dark Byte (developer) 2009-02-03 10:53	could be a disassembler bug and it can't properly calculate the 'previousopcode' address. Or perhaps you where looking for a stack address that was put there and the instruction to there was a call that pushed the return address on the location you where watching, or it's an unhandled event from a previous kernelmode debugger event (but then it'd most likely be the first)

(0000217) Csimbi (reporter) 2009-02-03 13:40	This second one was a floating point value (the resource count).

Issue History
Date Modified	Username	Field	Change
2009-02-01 17:55	Csimbi	New Issue
2009-02-01 17:55	Csimbi	File Added: SHOTS.ZIP
2009-02-01 17:56	Csimbi	Issue Monitored: Csimbi
2009-02-01 19:03	Dark Byte	Note Added: 0000208
2009-02-01 19:03	Dark Byte	Status	new => acknowledged
2009-02-01 19:04	Dark Byte	Note Edited: 0000208
2009-02-02 14:57	Csimbi	Note Added: 0000210
2009-02-02 14:59	Csimbi	Note Edited: 0000210
2009-02-02 18:37	Csimbi	File Added: SHOTS2.ZIP
2009-02-02 18:39	Csimbi	Note Added: 0000211
2009-02-03 10:53	Dark Byte	Note Added: 0000216
2009-02-03 13:40	Csimbi	Note Added: 0000217

Relationships