[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