Author
|
Topic: Xkas. How in the world do I begin to use it? (Read 869 times)
|
DarknessSavior
Guest
|
 |
« on: September 17, 2007, 08:29:09 am » |
|
I was given a few ideas for my first few ASM hacks, and I wanted to start with the simplest of them, which would be to disable the dakuten/handakuten code in two games (FF:MQ and Demon's Blazon), effectively speeding up the CPU and enabling me to move the tilemap index a bit so I can have more space for dialogue (I don't know if this is exactly a "double line hack" or not, but it kinda sounds like it). However, not much instruction is provided with Xkas. So I'm kinda confused as to how to go about doing what I want to do. In this case, this code is from FF:MQ. I haven't looked for the Demon's Blazon one yet, but I imagine it'd be pretty similar to this one. Basically what I want to do is to take the following instruction, and change it to not look for the values with dakuten/handakuten. $00/9E73 C9 7E 00 CMP #$007E A:0088 X:0000 Y:001C D:0000 DB:00 S:1FE4 P:envmxdizC Any value from $4B-7D has dakuten or handakuten. So comparing A to $007E is seeing whether or not it needs those characters, right? Now, would I be changing the CMP here, or the Branch afterwards? I ask this because the carry flag is already set by a previous CMP (which checks to see if the character is within the DTE/Dictionary section). Can anyone give me a general idea of what I'd want to do? Edit: I decided to look for the nigori code in Demon's Blazon, and I can't even get the breakpoint to snap. -_- The address for the first bit of dialogue is 1F73D0, Lunar Address gives me BEF3D0 (since it's LoROM, second type). I set a read breakpoint for that, and got to the first screen before the battle, made a savestate in Geiger, then walked into the battle. Nothing. Is there a reason why? Edit#2: Nevermind. For some reason I forgot about the header. The interesting thing is that I wrote down the string addresses BEFORE removing the header. When I checked the address in WinHex, it was the same. But the breakpoint didn't work. Subtracting $200 for the header made it work. Go figure. ~DS |
|
|
|
« Last Edit: September 17, 2007, 09:25:50 am by DarknessSavior »
|
|
|
|
Kejardon
Guest
|
|
« Reply #1 on: September 17, 2007, 09:25:49 am » |
|
Xkas *does* have an html help file. But I'll explain how to set it up anyways, and hopefully include anything you might need to know. Although, first off, you'll want to know if the game is hi-rom or lo-rom. You'll need to make an assembly file, and preferably have everything in the same folder. At the top of the assembly file put 'hirom' or 'lorom'. Below that put main () {
} There's probably a way to use it in a more C like manner, but I just leave it like that and put all my code inside of it. Anyways, inside there put 'org $C09E73' (or 'org $809E73' for lorom). This tells the assembler where to start writing. Then on the next line put the new command - it sounds like you want CMP #$004B. After that, open up a command prompt and type cd\\Folders\\To\\Xkas\\ (replace with actual folders, or leave as cd\\ if in the root directory) Type 'xkas assemblefile.ext romfile.ext' and xkas will assemble the file and write it to the romfile you specify. It'll only give output if there's an error (or if you use certain commands in xkas) - no response means it worked fine. ::edit:: Oh yeah, and if you have a header, make sure you type 'header' on the first few lines. header ;If you don't type this, xkas assumes 'noheader'
hirom ;or possibly 'lorom'
main () {
org $C09E73 ;Or if lorom, 'org $809E73'
CMP #$004B
}
|
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #2 on: September 17, 2007, 09:38:59 am » |
|
Simply changing the CMP from $007E to $004B would cause the nigori code to not work? O.o Also, there's already one of those exact same instructions, directly before it. That checks to see if it's a DTE/MTE code. So why put it in twice? Why not just get rid of it? And yeah, I know it does have an included html file, but it seemed like that was more to explain the features, not how to put a .asm file together. Then again, I did just skim it, I could be wrong. >.< Also, I found the Demon's Blazon version: $BE/DE02 A7 3B LDA [$3B] [$BE:F1D0] A:2003 X:00B0 Y:0050 P:envMxdizc
$BE/DE04 F0 48 BEQ $48 [$DE4E] A:20AC X:00B0 Y:0050 P:eNvMxdizc
$BE/DE06 C9 6A CMP #$6A A:20AC X:00B0 Y:0050 P:eNvMxdizc
$BE/DE08 D0 0B BNE $0B [$DE15] A:20AC X:00B0 Y:0050 P:envMxdizC
$BE/DE15 C9 02 CMP #$02 A:20AC X:00B0 Y:0050 P:envMxdizC
$BE/DE17 D0 11 BNE $11 [$DE2A] A:20AC X:00B0 Y:0050 P:eNvMxdizC
$BE/DE2A C9 FF CMP #$FF A:20AC X:00B0 Y:0050 P:eNvMxdizC
$BE/DE2C F0 04 BEQ $04 [$DE32] A:20AC X:00B0 Y:0050 P:eNvMxdizc
$BE/DE2E C9 FE CMP #$FE A:20AC X:00B0 Y:0050 P:eNvMxdizc
$BE/DE30 D0 08 BNE $08 [$DE3A] A:20AC X:00B0 Y:0050 P:eNvMxdizc
I'd guess that the way I'd get rid of the Nigori code would simply be to put everything exactly as it is, except get rid of the last four lines (the handakuten code is $FF and the dakuten code is $FE). Is that correct? I spent a while analyzing the code, to see if perhaps I was wrong on the above. I think I am, so I came up with an alternative. I think if one were to change the "BNE $11 [$DE2A]" so that instead of branching to $BEDE2A (where the nigori codes are) you just set it to branch to $BEDE3A (the instructions AFTER the nigori codes), that'd do it. But uh, how would I do that? >.< ~DS |
|
|
|
« Last Edit: September 17, 2007, 11:03:26 am by DarknessSavior »
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #3 on: September 17, 2007, 12:01:19 pm » |
|
There's no instructions because all you do is this: None of that C main() syntax mumbo jumbo is necessary. hirom ;hirom or lorom
header ;header or don't put this line in if there is none
org $24BITSNESADDRESSGOESHERE
ASSEMBLY CODE GOES HERE ;Stick your code here. Just write assembly code and it will be put where the org address tells it.
Simple as pie. What's not to get? You give it an address and give it some code to stick there. As for HOW to make the modification to the game, that's up to YOU. It has nothing to do with the assembler. Your interest is in the branch after the compare. You can either disable it altogether with NOPs or you can make it always branch to one of the locations. Whatever works. Jump right in and just start doing it. Use the debugger and step through the code after you've modified it to see what is going on now since no doubt you will most likely crash the game often until you get good at this sort of thing. That's all there is to it. You make changes, see what those changes do. See if they do what you expect. If not find out why. Fix it. Repeat. Fun stuff.  |
|
|
|
|
Kejardon
Guest
|
|
« Reply #4 on: September 17, 2007, 05:05:27 pm » |
|
None of that C main() syntax mumbo jumbo is necessary.
Figures. I forget why I started that, but for some reason I thought it was necessary. <_<""; I didn't have time to really look at what you're working on earlier, I was more trying to get a basic assembleable structure up. Now that I read more about it though, it sounds like you want to skip to DE3A if it ever reaches DE2A (org $BEDE2A : BRA $DE32). It depends on the surrounding code and exactly what you want to do though - I don't know how that game's text works and there's a good chance that I'm blindly wrong again. Though trial and error never hurts so long as you keep backups handy. |
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #5 on: September 18, 2007, 11:49:28 am » |
|
Yep, I guess I'm just gonna try what I think will work and if it doesn't, start over and try something else. =D
Thanks for the help, ^_^
~DS
|
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #6 on: September 18, 2007, 08:36:58 pm » |
|
If you need to add code that doesn't fit find and empty space and do this...
org $originalcodespot
JSL NewCode()
org $newcodespot
NewCode()
{
RTL ;jump back
}
keep in mind you could overwrite an instruction or two so make sure you're nop-ing any instruction or adding them to the new code. you can use jmp for this kind of thing as well.
|
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #7 on: September 19, 2007, 07:19:35 am » |
|
That's certainly an interesting idea, DMM. I'll keep that in mind.
I actually put together and fixed the code to get rid of the Nigori pretty quickly. It was only a single-instruction ASM hack, but still, it's my first, and it works. Nothing all that complex, but I'm quite happy to get a start. I'm gonna do that to FE too, and then work out a DTE for it, since RedComet said that working on NES ASM is a bit easier for beginners (though, I've heard many times that they're practically identical, when it comes to working with graphics and stuff, apparently that's easier on NES). Once I can figure out DTE on the NES, I should be able to easily get it to work on SNES too. =D
~DS
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #8 on: September 19, 2007, 09:19:51 am » |
|
You guys really like that C syntax don't you?
I prefer writing straight assembly when I'm writing you know.. assembly. I leave the C syntax for my C programming. I just don't see it adding much value to assembly. It just makes you type more! :laugh:
|
|
|
|
|
byuu
Guest
|
|
« Reply #9 on: September 19, 2007, 09:59:41 am » |
|
The benefit of the C-style syntax is with nesting. render_intro_screen() {
decompress_tiledata() {
...
}
write_tiledata() {
...
}
write_tilemap() {
...
}
write_palette() {
...
}
...
rts
} render_vwf() {
initialize() {
...
}
write_string() {
read_char() {
...
}
write_char() {
...
write_line() {
...
}
...
}
...
}
finalize() {
...
}
rts
} Of course, if you don't like that, then don't use it. It works great for me, so that's why I added it. But it is, after all, an option. |
|
|
|
|
DarknessSavior
Guest
|
|
« Reply #10 on: September 19, 2007, 04:21:42 pm » |
|
Yeah, seeing as ASM is the first programming language (if you can even call it that) that I'm learning, that makes NO sense to me. :huh:
~DS
|
|
|
|
|
YoshiRPG
Guest
|
|
« Reply #11 on: October 05, 2007, 06:50:41 pm » |
|
Which is ASM more similar to, C Script or Java,
I am working on learning Java as well as ASM, so where should I start to learn ASM.
What do I need to know first before I can write ASM?
|
|
|
|
|
MathOnNapkins
Guest
|
|
« Reply #12 on: October 05, 2007, 08:06:56 pm » |
|
Generally, it would help to know the basics of the hardware you're trying to code for. Look on this site for 65c816 (or 65816) documents. Those will tell you how all the individual instructions work, and should give you an idea of how the various registers and memory systems work. It's not easy at first, but the more you look at it the easier it gets. I'd also recommend picking up geiger's debugger as it allows you to step through games and see their code step by step.
|
|
|
|
|
YoshiRPG
Guest
|
|
« Reply #13 on: October 06, 2007, 12:32:35 pm » |
|
The system that I am working with is the SNES, and the Game is Zelda 3 Link to the Past SNES,
and is there a way that you can make it so that only certain Bosses in Zelda 3 Heart Containers , because in my Zelda 3 Hack I would like to have like some sub bosses in some of my levels but I do not want them to drop Heart Containers, because they are just sub Bosses.
|
|
|
|
|
Bobbias
Guest
|
|
« Reply #14 on: October 06, 2007, 12:56:53 pm » |
|
Which is ASM more similar to, C Script or Java,
I am working on learning Java as well as ASM, so where should I start to learn ASM.
What do I need to know first before I can write ASM?
ASM is nothing like either C or Java... Well, unless you know Java bytecode. Then it's closer to Java... ASM is really quite different than high level languages, such as C, Java, VB etc. because you have to do EVERYTHING yourself when coding it. |
|
|
|
|
|
