Hey folks,

I've been using Easy68K for about a month now and thought I'd post up a little bit about my project in case it is of interest to anyone.

My main goal is to create an annotated and understood disassembly of the brilliant Sega Megadrive game Toejam and Earl which you can follow the progress of on my website: http://www.mybrillgamesite.com/projects/?id=86

As a sub goal I am aiming to create an Easy68K compatible source code that will recreate the original ROM binary at compile time. This will thus allow people with sufficient know how to edit the game dynamics and create their own versions, hopefully leading to some exciting new Toejam and Earl experiences!

Progress is going pretty well so far with around 5% of the ROM annotated however large chunks of this are just identified areas of game data rather than instructions.

In terms of getting the re-compliable version working it to is progressing well. The main difficulty here is that the disassembly I'm working from obviously loses all labels so just has raw addresses and the code tends to jump around the ROM a lot so there may be for example a routine that is called at position $0001FFFF but is currently at my ROM in $00003FDA because I don't have all the items in between in place yet. This means I'll always be behind in what I can actually compile and run compared to what I've got annotated and understood. To over come this I think I could either use labels or pad the missing areas with FF to get everything in the same position but I haven't explored these options yet.

Obviously Easy68K doesn't emulate all the processors in the Megadrive (There is also the Z80, VDP, PSG and FM chips) but these are all controlled through the 68K anyway so between Easy68K for coding and compiling and the GENS suite of emulators for debugging I should be ok. What I may do down the line is have some other Easy68K projects set up for testing subsections of code and routines and just simulate the responses I expect at certain locations (for example reading joypad input) but I'll cross that bridge when I come to it.

In terms of issues I haven't came across anything huge so far. Here are the 2 current queries but I haven't looked into them in depth by any means so please don't feel obligated to post large answers (although if you know the answer a quick reply would be appreciated!):

[*] The ORG command doesn't appear to be respected. Putting it at the top of the code with ORG $000000202 doesn't make the code execution start at offset 202, and since 200 is an infinite loop this is pretty annoying!
[*] I noticed using a label on a BRA instruction outputs a different opcode from using an explicit address (i.e. BRA gameStart and BRA $000000290 produce different sized output). I'm assuming BRA gameStart is using BRA.w and BRA $000000290 is using BRA.b but I need to check this. Note the address here is off the top of my head, I know 290 won't fit in a BRA.b command!

So that's where I'm at and what I'm up to.

I'll post back now and then with my progress so be sure to come back as well and please feel free to ask questions and I'll answer where I can.

Cheers

ORG $address sets the address of the next instruction or data. It does not set the execution address. If you want to locate code at a particular address then precede it with ORG $address.

_________________
Prof. Kelly

Thank you for approving the post and for the reply Professor Kelly.

Once I got home I figured out the BRA command, it was indeed because I was missing the .s (not .b) off of the end of the BRA command and it was defaulting to a BRA.w. Now that it is adjusted it is outputting the expected opcode.

The ORG command sounds pretty interesting, so I could almost simulate the code being in the correct place using ORG commands instead of padding it out. Of course this would only work in the Easy68K debugging but could still be useful. However I think labels are the way to go, as I progress through the disassembly they will naturally progress their original memory address and the code will work throughout as it moves about.