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
Acmlm's Board - I2 Archive - - Posts by Parasyte
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
User Post
Parasyte

Bullet Bill
Level: 35

Posts: 362/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-14-05 06:12 AM, in Mega Man 6 debugging stuff! Link
There is text in MegaMan 7. But as far as I am aware, no one has ever hacked it. I looked into it briefly at one point, then got quite bored and moved on.
Parasyte

Bullet Bill
Level: 35

Posts: 363/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-14-05 03:25 PM, in Geiger's Snes9x Debugger Mark 9 Link
Download the full release: http://www.geigercount.net/crypt/Snes9X1.43.ep9r6.7z
Parasyte

Bullet Bill
Level: 35

Posts: 364/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-16-05 06:05 AM, in Rom ASM question Link
If you are referring to "filler" outside of the routines you write, just any byte will work fine. I usually use 0xFF, myself. Just so I can visually see where my free space is, if I ever need it. If you are referring to "filler" in code that actually gets executed... (though I can't figure out why you would do this, in such a situation) using NOP is the only real option.
Parasyte

Bullet Bill
Level: 35

Posts: 365/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-17-05 05:57 PM, in Geiger's Snes9x Debugger Mark 9 Link
Originally posted by MathOnNapkins
But I do have a comment, which I am not sure was raised earlier about breakpoints. Once I have set one breakpoint, and then disarm it, or edit it to another breakpoint, the code where it occurs does not show up for the second breakpoint, unless I first clear the screen. Small, but indeed a hassle.

For example I was looking at writes to $0E10. Once I was done I wanted to look at writes to $0E30. The debugger properly stopped execution at those writes, as I could tell from the hex editor, but the updates in the main text portion of the debugger failed to show me the information on the location of the code that caused the breakpoint. That is, until I hit 'clear text'.

edit: I have not been able to replicate this, but it occurred nonetheless. :\ irritating.


You must be using Windows 98? The 'output box' is a standard multi-line edit box, which has a maximum size of 65,535 bytes on Win98. (Each character is 1 byte, and each 'new line' consists of 2 bytes.) If you had large chunks of diassembly, that would explain the problem you experienced. (Try it, disassemble a few thousand lines, and press "Next Op" to see if it's pronted or not. It shouldn't be too difficult to overflow the text buffer on Win98.)


FloBo: After setting the breakpoint, press the Run button. If it breaks at the wrong address, press Run again. Just continue pressing Run until it breaks where you want it to. If you reset the game at any time, the breakpoints you have set will be DISABLED, and must be re-enabled manually. (This is an issue that was brought up earlier)
Step Into is used to step through code one instruction at a time. Use Run, instead.


(edited by Parasyte on 03-17-05 09:01 AM)
Parasyte

Bullet Bill
Level: 35

Posts: 366/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-18-05 08:06 PM, in Geiger's Snes9x Debugger Mark 9 Link
That makes no sense, to be honest. Provide use with a test case (name of the game, and a sample breakpoint, for starters) so that it may be looked into. The problem may be caused by a very nasty bug.

As for "breaking when a register has a certain value" I have added this functionality to FCEUXD a few weeks back in the form of conditionals. You are able to use a set of C-like [if] statements to cause a break only when a certain condition is met. The only operands currently supported (in the latest, incomplete build, which I haven't sent to anyone) are A, X, Y, PC, S, P, (memory) and immediate values. I could also do some pointer indirection logic (like (*(u8*)PC == 0xA9) to watch for LDA instructions, or (*PC == 0xA940) to watch for LDA #$40 only... ) As well as a whole slew of other syntax additions. It's pretty much what I have been wanting since FCEUd's inception. As you can probably tell, it's quite the powerful tool.
Parasyte

Bullet Bill
Level: 35

Posts: 367/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-19-05 03:39 PM, in I'm writing a new metroid hack Link
Yes, of course it's possible to make a such a change to the walljump hack. (It's pretty much possible to do anything, by the way.) Since the hack is open source, I wouldn't mind if other people were to make such changes. But I've filled this request in a matter of seconds, so here it is:

; This code allows for a wall-jump in Metroid (NES)
; Copyright 2002-2005 Parasyte
; http://parasyte.panicus.org/
;
; The above copyright notice may not be removed or changed.
;
;
; Notes:
; Simply overwrite the data at file address 0x01CAD4 (48 bytes, max)
; with this code. Then set the hook by patching 0x01CC34 to 0xC4,0xCA


.org $CAC4 ;assemble our code to run at this (CPU) address
.mem 8 ;setup accumulator and index regs for NES code
.index 8


;--constants
BtnRight = $01 ;Joypad button definitions.
BtnLeft = $02
BtnDown = $04
BtnUp = $08
BtnStart = $10
BtnSelect = $20
BtnB = $40
BtnA = $80

ItemBombs = $01 ;Item definitions
ItemHighJump = $02
ItemLongBeam = $04
ItemScrewAttack = $08
ItemMaruMari = $10
ItemVaria = $20
ItemWaveBeam = $40
ItemIceBeam = $80


;--pointers
JoypadDown = $12
Joypad = $14

JumpSpeed = $0308

ItemFlags = $6878 ;Items Samus has collected

DoJump = $CD40 ;Makes Samus Jump

WallToLeft = $E880 ;Checks for a wall to the left of Samus, returns result in C flag: Set = no, Clear = yes.
WallToRight = $E88B ;Checks for a wall to the right of Samus, returns result in C flag: Set = no, Clear = yes.




;--Entry Point
; Inputs: None
; Outputs: None
; Description: Checks if Samus is able to wall jump, performs action if possible.

lda ItemFlags ;Does Samus have High Jump Boots?
bit #ItemHighJump
beq exit ;No? Exit!

lda JoypadDown ;Is A button just pressed?
bpl exit

lda #BtnRight
bit Joypad ;D-Pad Right held?
beq +

;Check if able to wall jump to the right.
jsr WallToLeft
bcs exit
bcc ++

+ asl
bit Joypad ;D-Pad Left held?
beq exit

;Check if able to wall jump to the left.
jsr WallToRight
bcs exit

++ ldx JumpSpeed ;Is Samus in a slow decent?
beq +
dex
bne exit

+ jsr DoJump

exit:
jmp $CCC2 ;Bye-bye!



(edited by Parasyte on 03-19-05 06:40 AM)
Parasyte

Bullet Bill
Level: 35

Posts: 368/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-20-05 03:54 AM, in Geiger's Snes9x Debugger Mark 9 Link
I see. In the SNES memory map, 08:0000 does not exist; it's virtually mapped to 00:0000. (Which in turn is mapped to SNES RAM address 7E:0000, thus you get break hits on every instruction which accesses this address. It will certainly be a LOT -- this address is often used for input args and return values to/from many, many functions.)
I do not know what address you are actually attempting to watch, but "80000h" (08:0000) is definitely not correct. Perhaps it's 800000h (80:0000) that you want?


(edited by Parasyte on 03-19-05 06:58 PM)
Parasyte

Bullet Bill
Level: 35

Posts: 369/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-20-05 04:10 AM, in I'm writing a new metroid hack Link
I have not worked on my hack in quite a while. Last changes I made were to the CHR-loading code. With CHR-ROM (rather than -RAM) the size and speed of the code has become much better (smaller code/data sets, faster processing). I've only added a few CHR-ROM banks, however. Meaning that the title screen and [most] of Brinstar including sprites shows up correctly. Everything else looks like garbage.
In addition, I've also started working on the status bar handling code. It works "well enough" as it is, but because the original screen drawing algorithm is too slow, it causes the screen to "jump" every time the game loads up the next screen. The only solution will be HEAVY optimization. This means completely rewriting the routines and room data format. Not something I'm looking forward to. ;D
Parasyte

Bullet Bill
Level: 35

Posts: 370/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-20-05 04:25 PM, in Opening exe Files problem. Link
It is better to manually open a command prompt and run the program from there than just double clicking on the executable's icon in explorer. Most command line programs require passing input arguments on the command line. So you REALLY need to get used to using the command prompt for such programs. Using system("pause"); will just add an unneeded [EG. annoying] delay for people who actually do use the command prompt properly. So do avoid it.
Parasyte

Bullet Bill
Level: 35

Posts: 371/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-20-05 04:31 PM, in Allright. Im ready to learn ASM. Link
Just a note about what Black Lord said: It is possible to learn an assembly language in one day. The prerequisite is knowing at least one assembly language before hand. I was able to learn SH4 (as in Dreamcast) in a matter of two hours, and PowerPC (as in GameCube) in about the same range of time.
Once you understand the concepts of assembly programming, it is very easy to pick up another language. That first step is something of a killer though. It will take more than a few weeks for first-timers. Expect no less than a month to become familiar enough with the language to use and hack it efficiently.

Oh right. And here's my contribution to the thread: 6502 reference. It's only the best 6502 reference anywhere. (It explains in detail the operation and flags set/used by each instruction. Something that a lot of tutorials and other references will not get into. This info is critical.)


(edited by Parasyte on 03-20-05 07:33 AM)
Parasyte

Bullet Bill
Level: 35

Posts: 372/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-20-05 09:16 PM, in I'm writing a new metroid hack Link
Oh no, it is much too difficult for me to stay motivated on one project for any extended period. I jump around between projects to keep things fresh. Naturally, this means I have a ton of projects going at any one time. Too much to keep up with, but enough to keep from being bored all the time.
Parasyte

Bullet Bill
Level: 35

Posts: 373/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-20-05 09:46 PM, in Allright. Im ready to learn ASM. Link
The gory details are all explained within the reference I linked. The theoretical details (such as "what the hell are registers and addressing modes?") are for a tutorial. You may be able to get some of the information from a few tutorials, but few tutorials have all of the information. And that's why most tutorials are quite bad; if they aren't written by beginners, then they aren't written for beginners, either.

I'm sure if you take the time to look through the "Greek" 6502 reference, along side a debugger, you will begin to understand what's what and why. Jumping right in and learning from experience is the way to go. Even without much programming knowledge, most concepts have been learned in your early childhood; add, subtract, carry, borrow... And of course making decisions; true, false... If you can understand these concepts, and you have a nice, verbose debugger handy, you should be able to look at an instruction in said debugger, look it up in the reference, and read the description to understand what the instruction does. There's not much difficulty in that. You see, understanding an assembly language is one thing. Understanding what routines do at a higher level (for example, loading and displaying a sprite) is altogether different. No tutorial can teach these things. The best they can provide is an example of how one game may do something specific. Truth is, it is always very difficult to understand undocumented routines (especially when hacking) even for programmers and hackers with many years of experience. You just have to think a bit like the machine and put many pieces of a puzzle together.

So, what I'm saying is that tutorials can be good, but you need more than that. You need definitive resources. Whether those resources are low-level reference sheets, debuggers, or having friends with the knowledge you seek; use them all. Learning a high level language is by no means required. As long as you understand the three basics of programming; Arithmetic, Program Flow, and Data Load/Store.

And with that, I'll get back to hacking 'Lost Cheats'. (Maybe I should create an archive of these things...)


(edited by Parasyte on 03-21-05 08:39 PM)
Parasyte

Bullet Bill
Level: 35

Posts: 374/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-21-05 02:36 AM, in Allright. Im ready to learn ASM. Link
No. I am saying that all you will see is a bunch of senseless instructions. You'll see some adds, bitwise logic, loads, stores, and branches. But those will not tell you what part of the game they are handling.
There is little guess and checking involved; generally an experienced hacker can deduce what each routine does by memory references and plain old reverse engineering logic. Anything can be "edited and changed" but finding it can be difficult. And this is due to what I've explained above. You don't get any simple references such as function and variable names. It's just a lot of code, and it all looks exactly the same.

The most obvious choice for a debugger is the one in FCEUXD. It contains almost everything that is needed.
Parasyte

Bullet Bill
Level: 35

Posts: 375/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-21-05 08:29 PM, in Allright. Im ready to learn ASM. Link
I thin the idea is to get you familiar with code that makes no bloody sense. Because when hacking assembly, you will see a lot of it.
Parasyte

Bullet Bill
Level: 35

Posts: 376/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-22-05 04:14 PM, in How do you find level data within a rom? Link
dark ludwig, GBA contains an ARM7TDMI CPU, meaning the assembly used is: [two instruction sets] ARM7 and Thumb.


(edited by Parasyte on 03-22-05 07:18 AM)
Parasyte

Bullet Bill
Level: 35

Posts: 377/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-24-05 04:16 AM, in This is never going to get fixed!! Link
Visual Basic is slow, as it is. Reading files will make it invariably slower. Creating arrays with 12000 elements from parsing a file will be yet another speed hit. And as you can see, the method you are using will cause more problems, still.

I would suggest writing a seperate program to create the arrays and save them into (a single or multiple) binary file(s). Then rewrite this program to simply read the arrays from the binary. It will be quite a bit faster to do this. Alternatively, you could just move your txt parsing code into an "init" routine that runs only once, each time the program is started, and uses the aforementioned binary files. But from what I can tell, this is what you want to avoid?

Another option would be rewriting the txt format to help optimize the load time. Yet another option would be rewriting the txt format and using a more viable language. (Though each of these suggestions depend on the possibilities that you may not be able to do so. For example, a school project for a Visual Basic class.)
Parasyte

Bullet Bill
Level: 35

Posts: 378/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-24-05 04:24 AM, in How do you find level data within a rom? Link
What? If it's compressed, you'll also pull up the decompression routine in addition to the location of the compressed level data...
Parasyte

Bullet Bill
Level: 35

Posts: 379/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-24-05 06:40 PM, in What helps you code? Link
Silence. Dead silence.
Parasyte

Bullet Bill
Level: 35

Posts: 380/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-24-05 06:44 PM, in Best Emulators for use in hacking Link
Originally posted by Heran_Bago
Kega Fusion is awesome, but it doesn't have some of the nifty features.


... Yet.
Parasyte

Bullet Bill
Level: 35

Posts: 381/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 03-26-05 10:45 PM, in A GC Homebrew hacker has created a program that makes any GC game go online Link
I wish people would stop posting about this.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Acmlm's Board - I2 Archive - - Posts by Parasyte


ABII


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



Page rendered in 0.018 seconds.