Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Rom Hacking: hukka | 2 guests
Acmlm's Board - I2 Archive - Rom Hacking - FF1 re-assemblable disassembly
  
User name:
Password:
Reply:
 

UserPost
Acmlm
Posts: 649/1173
I'm using EditPlus, and also got syntax highlighting for 6502 (although pretty basic, but I can improve it)

Looks like this for me

But this one is shareware
Gavin
Posts: 60/799
somewhat off-topic: tried both ConTEXT and TextPad.. .they are both excellent, but i happen to find i like TextPad's setup a little better. Besides, i just found a 6502.syn syntax file on some random website, so now i can do all my fun stuff in highlighted goodness
Ultima4701
Posts: 5/7
ConTEXT is a very good freeware text editor.
Parasyte
Posts: 23/514
I do not know if he uses it, but I suggest TextPad. It's what I use for C, PHP, HTML, assembly, text ... EVERYTHING!
HyperLamer
Posts: 831/8210
Hey, what text editor did you use for labelling anyway? I couldn't help noticing that even the smallest ROMs disassembled produce some very big ASM files, and Notepad sucks at big files.
Acmlm
Posts: 640/1173
Even the old assembler I use (DASM) supports this < and > ... I used it in my NSF code, for example:

doend
LDA #<silence
STA sq1_posL,X
LDA #>silence
STA sq1_posH,X
JMP read.end
...
silence
hex 7F 00 C0
dc.w silence

(part of the code for the "end of track" command in my NSF, makes the track position pointer jump to an infinite silence loop )

So if the "silence" label is at $95C2, you'll get LDA #$C2 and LDA #$95 ... quite useful ... and yep, omitting the # would make it LDA $C2 and LDA $95, zero page
NightHawk
Posts: 135/621
Originally posted by Parasyte
Labels can be used in this case. X816 syntax supports a few wonderful features just for code like this:

LDA STA $10
LDA >myLabel
STA $11
LDA ($10),Y

The use of RAM addresses isn't so important, but they could also be labeled, or otherwise symboled in the source.

EDIT: It may require "LDA #
Yes, it requires the #. If you don't have the #, you should get a warning from the assembler (without the #, it should be interpreted as zero-page addressing).
Parasyte
Posts: 19/514
Originally posted by Disch
Actually... some code still has to be padded with this source, unfortunately. I couldn't get the indirect addressed labels working... so whenever the game did something like

LDA pointer_low
STA $10
LDA pointer_high
STA $11
LDA ($10),Y


I will load from a fixed address (pointer_low and pointer_high). I didn't get those labelled... so if you position of that pointer, it will corrupt some things . I noticed this when removing code in the first half of either bank 1C or 1D... it messes up what graphics are used for the game cursor.

So yeah... some things still need to be padded if changed .


Labels can be used in this case. X816 syntax supports a few wonderful features just for code like this:

LDA <myLabel
STA $10
LDA >myLabel
STA $11
LDA ($10),Y

The use of RAM addresses isn't so important, but they could also be labeled, or otherwise symboled in the source.

EDIT: It may require "LDA #<myLabel" instead. I'm not certain, since I have not tried it. But the "get low byte\high byte" features are documented.
NightHawk
Posts: 133/621
Originally posted by Disch
Actually... some code still has to be padded with this source, unfortunately. I couldn't get the indirect addressed labels working... so whenever the game did something like

LDA pointer_low
STA $10
LDA pointer_high
STA $11
LDA ($10),Y


I will load from a fixed address (pointer_low and pointer_high). I didn't get those labelled... so if you position of that pointer, it will corrupt some things . I noticed this when removing code in the first half of either bank 1C or 1D... it messes up what graphics are used for the game cursor.

So yeah... some things still need to be padded if changed .
That's basically what I was saying... you were a bit clearer about it though.

Here's a few addresses that get loaded that way, for anyone that's interested (all in bank 1D):
$A011
[these next 3 are the "New Game"/"Continue"/"Response Rate" strings]
$A253
$A25C
$A265
$A8FB
$A977
$A97F
$AC9C

Those are all the ones I got around to changing in that bank.
Kefka
Posts: 2182/3392
Originally posted by Acmlm


Being able to do this with every ROM would be great


*cough*Hintage in bbit's post*cough
Dish
Posts: 72/596
Actually... some code still has to be padded with this source, unfortunately. I couldn't get the indirect addressed labels working... so whenever the game did something like

LDA pointer_low
STA $10
LDA pointer_high
STA $11
LDA ($10),Y


I will load from a fixed address (pointer_low and pointer_high). I didn't get those labelled... so if you position of that pointer, it will corrupt some things . I noticed this when removing code in the first half of either bank 1C or 1D... it messes up what graphics are used for the game cursor.

So yeah... some things still need to be padded if changed .
Ultima4701
Posts: 3/7
Labels are perhaps the most valuable part of the source lost in assembling; even moreso than comments. Having well-organized procedures usually allows for easy identification of what purpose any given piece of code does.

Labels can be "auto-regenerated" using numbers and generic names, but they lack the same usefulness.
Parasyte
Posts: 16/514
In "assembly source code" such as this, pointers are created using labels. They are not static numbers. Meaning the code is 100% relocatable. Adding or removing code is absolutely no problem. That is what differs this from any standard disassembly. It is the closest thing to the actual source code as you're ever likely to get.
NightHawk
Posts: 131/621
Originally posted by Acmlm
Yep, I tried it earlier today and it really works, the whole thing compiles into a working FF1 ROM This definitely makes ASM hacking a lot easier and more efficient (no more NOP+JSR'ing stuff and looking for unused bytes to put code in ), and also helps understanding how the game is coded ...
Hmmm?
Not exactly... the game loads pointers into memory that the debugger doesn't recognize (because it can only load 1 byte at a time, and pointers are 2 bytes), so you'll have to pay attention in some places to either have it load the addresses properly, or (the easier way if you're doing something "quick-n-dirty") you still have to pad things....

And as for understanding how it's coded... great, if you can figure out where the routine is for text in battle, let me know?
Acmlm
Posts: 629/1173
Yep, I tried it earlier today and it really works, the whole thing compiles into a working FF1 ROM This definitely makes ASM hacking a lot easier and more efficient (no more NOP+JSR'ing stuff and looking for unused bytes to put code in ), and also helps understanding how the game is coded ...

Being able to do this with every ROM would be great, I'd like a working SMB2 disassemble for example I've been working on a disassembled SMB2 NSF myself recently, so I can understand what every part does, and figure out how to replace it completely with my own music code in the ROM (which I've been able to do, just need to add the sound effects) ...
bbitmaster
Posts: 4/103
Yes, I realize what it would take, and I have it all figured out and currently working on it. I've got the code tracing "algorthim" finished(Dahrkdaiz and disch can testify as to how well it works - they're my beta testers). I just need to do a couple other things before I work on the disassembler.

I don't like to talk much publically about anything I'm doing while its still so early in devolpment. But trust me, if this thing works the way I have it planned, it'll turn the scene upside down.

I am going to have extremely little time to work on it, with college coming up, so it might be a while before it is finished. Please don't ask when.
Gavin
Posts: 58/799
Originally posted by HyperHacker
...You realize that you need to know where every bit of data is to do that, right? You might be able to separate it with a very complicated code-tracing algorithm, but you should know how stupid NES games' programming tends to be.


i'm fairly certain bbit knows what he's in for
HyperLamer
Posts: 780/8210
...You realize that you need to know where every bit of data is to do that, right? You might be able to separate it with a very complicated code-tracing algorithm, but you should know how stupid NES games' programming tends to be.
bbitmaster
Posts: 3/103
The ability to automatically do this for any rom is my ultimate goal for fceuxd....
Eternal Darkness
Posts: 11/16
Yes, it will help in my project as well . Thanks a million.
This is a long thread. Click here to view it.
Acmlm's Board - I2 Archive - Rom Hacking - FF1 re-assemblable disassembly


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.005 seconds.