It is currently Sun Jun 07, 2020 5:24 am

All times are UTC

Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Thu Jan 07, 2016 1:43 pm 
User avatar

Joined: Wed Jan 06, 2016 9:24 am
Posts: 15
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.


PostPosted: Thu Jan 07, 2016 7:04 pm 
User avatar

Joined: Thu Dec 16, 2004 6:42 pm
Posts: 1122
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.

00001000                             7          ORG    $1000
00001000= 54 68 69 73 20 69 ...      8  label1  DC.B    'This is at address $1000'
00001100                             9          ORG     $1100
00001100= 54 68 69 73 20 69 ...     10  label2  DC.B    'This is at address $1100'
00001118                            11         
00002000                            12          ORG     $2000
00002000  4E71                      13  START   NOP             ; this instruction is a address $2000
00002002  4E71                      14          NOP
00002004  FFFF FFFF                 15          SIMHALT
00002008                            16 
00002008                            17          END    START    ; last line of source

Prof. Kelly

PostPosted: Thu Jan 07, 2016 11:16 pm 
User avatar

Joined: Wed Jan 06, 2016 9:24 am
Posts: 15
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.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group