[Coco] Help with algorithm in assembly...
Mark
mark at mcdougall.family
Mon Nov 14 19:44:52 EST 2022
On 4/11/2022 12:08 am, Lee via Coco wrote:
> I don't really need to render all the tiles
> every game cycle, probably only ½ that many tiles at max and only about 10
> or so on most levels. So I think it's going to work out great.
Sounds like you're on top of it, nice!
> I'm taking a break from the CoCo coding and working on diving into the DOS
> game's EXE and tracing through it with DosBox-X's debugger to try and
> reveal some of the game's logic. That's a painstaking grueling tedious
> experience, but it's already revealing some good information.
I've done a number of reverse-engineering projects with subsequent
transcodes (ports) to the Coco3 and/or other systems. I'm actually in
the middle of one now; a Z80-based arcade game being transcoded to 68K
assembler. The RE is 97% done and the transcode is about 20% done (most
of the hardware emulation is complete). Sadly the Coco3 wouldn't be up
to the task of running this one...
My weapon of choice for RE is IDAPro disassembler; can't beat it
although it does cost money. I think there may be a free version for X86?
The other option is Ghidra (open source), which works very similarly. I
had some showstopper issues with Z80 when I tried it, so I gave up on it
and returned to IDAPro, but I believe the X86 stuff is a lot more stable.
I'd strongly urge you to look into this avenue for your RE work. Used in
conjunction with a debugger (Ghidra has one integrated), your
productivity will be much higher, your work will be permanently
documented, and it'll be much easier to replicate and/or port the logic
when it's done.
Regards,
--
Mark McDougall
<http://retroports.blogspot.com.au>
More information about the Coco
mailing list