Natsumi wrote:I do not know if there is a disassembly of the game, however if not, I would suggest not to make one as a first programming practice. Simply because you cant just change one line to see what happens, unlike with pre-existing disassembly.
Not at all: simply build a ROM that includes the original and is large enough to hold the code that you write, re-checksum, patch the MD header and you are up and running, repeat each time or better still use a proper patching method that keeps the entries as mods to the ROM image - like an update database. I do this myself for reversing work.
Saying that, it boils down to how able you are with Assembly in general and 68K/Z80 in particular.
As natsumi said, it is necessary to keep the Sonic 1 Disassembly around as a reference particularly for standard things.
Natsumi wrote:
Instead, I'd suggest taking a look at the Sonic 1 disassemblies that exist already. They are a good way to practice programming and see what changes do what.
ROM-hacking I am told is the most involved but at the same time you get a LOT more knowledge in the practice so it may be worth it for some people but not for others. Remember that there is no better example of MD reference codewise than commercial ROMs - there were no books written, no tutorials written by people from back in the day so this is the best
document that we have but it is testament all the same.
OrangyTang wrote:Cheers guys, it's useful to have pointers like these.
I'd like to take a stab at a dissassembly since I find I don't really learn from poking around existing disassemblies - they're impressive but unless I'm doing the work myself the knowledge just bounces off again and I don't remember it long term.
I agree: get burned often, find things out and find out how your original ideas were wrong
The MD, like a lot of ancient hardware now is a machine to be fiddled with and experimented with and no, the emulator usually lies so you have to hack the real hardware to learn something I find most of the time but Emulators are useful too for some situations.
OrangyTang wrote:
Is there any particular tools that you'd recommend? I've been trying to use 68kd but that doesn't work on Win7 64bit, and doesn't seem to run in Doxbox either. IDA Pro with the Mida script seems to produce something sensible, but after saving the asm out, it's not actually compilable with AS:
Tools:
Assembler, Linker, etc: I have used ASM68K (old and a bit limited I find), VASM (decent and actively developed) and GNU-AS (been with us for years and you get the Binary-Utils for free - very flexible and will most likely be with us for decades). When I first got into the MD I used ASM68K but it is a bit shit I feel so I switched to AS and yes, it has some odd additions and departs slightly from standard 68K but this no longer is an issue for me as I can use both. The main advantage to VASM and AS is that they allow you to use Linker-Scripts and both are a lot easier when linking to C code than ASM68K would be.
UNIX: all the tools that I use that matter but I cannot remember them to list them here but all the usual stuff.
Hex Editor: you need at least one decent Hex Editor - I use HxD under Windows and Od under UNIX.
Diff: I use Beyond Compare and it rules - well worth the $.
MD Util: my own
Swiss-Army Knife tool for MD work for all the standard stuff, e.g. patching your MD ROM, compression/decompression, etc. - I will release it maybe this year publicly; had to get a site sorted out for support and then I need to have the time to support it but yes, something like that or your own tools are what you need.
UMDK: yes, THE tool for working with the MD Hardware that I use. I also have a couple of Everdrives but do not use them now that I have UMDK.
Emulator: I use GENSIDA by Dr Mefisto and it is very good. Exodus worked once then crashed and never worked again; I have asked Nemesis to tell me what is going on. All the same, it is a very decent Emu to use when developing MD apps.
Disassembler: you have a few options here.
Tools to get inside the MD; I used an RS232 based command-monitor before I got UMDK and that allowed me to patch the MD's memory directly without needing to reset the MD Hardware but UMDK can offer you a lot more. I am looking to add the RS232 monitor support to UMDK to allow you get inside the MD directly without going through GDB.
Also, some people used the old 68K ICEs to get inside the 68K too but they may be a bit old and not really easy to get up and running these days on PC hardware.
Lab Equipment: Logic-Analysers, port capturers (joypad, RS232) and an Oscilloscope help. Note that UMDK now also has a Logic-Analyser built in too but I still use my other LAs to sample what UMDK cannot as UMDK is limited in channels.
OrangyTang wrote:
Code: Select all
> > >Gunstar Heroes (E) [!] disassembled.asm(2343): warning #50: privileged instruction
> > > rte
> > >Gunstar Heroes (E) [!] disassembled.asm(2521): warning #50: privileged instruction
> > > move #$2700,sr
> > >Gunstar Heroes (E) [!] disassembled.asm(2567): error #1340: short addressing not allowed
> > > lea (unk_F400).w,a2
> > >Gunstar Heroes (E) [!] disassembled.asm(2567): error #1350: addressing mode not allowed here
> > > lea (unk_F400).w,a2
> > >Gunstar Heroes (E) [!] disassembled.asm(2662): warning #50: privileged instruction
> > > move (sp)+,sr
> > >Gunstar Heroes (E) [!] disassembled.asm(2734): error #1340: short addressing not allowed
> > > lea (unk_E300).w,a0
> > >Gunstar Heroes (E) [!] disassembled.asm(2734): error #1350: addressing mode not allowed here
> > > lea (unk_E300).w,a0
> > >Gunstar Heroes (E) [!] disassembled.asm(2735): error #1340: short addressing not allowed
Is that normal? I had expected the result would still compile, even if it was full of arbitrary lables and offsets.
Yes, that is normal, but why the LEAs twice? That makes no sense. Can you show me the Hex for that section of the ROM please? I want to see what the code is directly.
But what you care about is the machine
state - the Z80 and 68K's registers, the VDP's registers, etc.
What you do is you see what is referenced, what calls what, then try to work out what the code does vs. what you see the app/game doing in real time.
Good luck.