 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by DarkPhoenix |
| Pages: 1 2 |
| User | Post | ||
DarkPhoenix Octorok Level: 9 Posts: 1/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Brilliant work, Geiger. I haven't run into any new bugs myself, but I have some suggestions for future releases -The ability to scroll through RAM while the game is running. This is more an issue of the fact that SNES9X pauses execution whenever you click on another window, but it'd be nice to be able to scroll through and see at a glance, for example, what parts of RAM are still updating while the game is sitting idle, rather than having to switch back and forth between the game and the hex viewer to scroll and see what's being modified. -A more visual way of looking at the usage map. Perhaps a way to view the hex highlighted as values are used as code or data and such. -and of course,along the same lines, as mentioned before by jman, something to look at the PPU of course, I'm not suggesting anything so complex as this - http://acg.media.mit.edu/people/fry/deconstructulator/ , that specific example is likely beyond the scope of the program, but maybe something simple, so at least things being accessed/modified will stick out a little better. On a side note, I can vouch for the joystick support not working. Not a terrible flaw, but an inconvenience. Granted, it shouldn't be your job to clean up the SNES9x code. |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 2/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| oh, something I liked from FCEUXD - the CDL dialogue box gives percentages of what's been interpreted as code and as data. Might be a nice touch to the SNES9x debugger...always nice to know when you're making progress. I love the usage maps (partially because I was trying to do a lot of it more...manually before), and any added functionality to it is much appreciated. | |||
|
DarkPhoenix Octorok Level: 9 Posts: 3/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| The PSP seems to allow for games to be run off of the memory stick Duo (that is, if you go to the Games, menu, there is a memory stick menu item). Does anyone know anything about how to program an application to run off of the memory stick? (edited by DarkPhoenix on 04-01-05 03:39 PM) |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 4/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Personally, I'd say it'd probably be easiest to get a book on something like x86 assembly first, and/or possibly take a class in assembly programming. As was mentioned before, it's pretty easy to pick up on a new assembly language once you're familiar with the concepts behind assembly programming, so my suggestion is to learn an assembly language that's well documented first, and then move onto 6502, followed by 65816, if that's your goal. x86 (which is used by the pentium processors) is particularly well documented as it's still used, at the very least for inline assembly with higher level languages. Additionally, it's pretty easy to find a good assembler for x86 (NASM, MASM, or the GNU assembler) As far as whether to pick up a book or get into a class or something, that depends on how you learn. If you know you're not gonna be able to beat yourself into reading through a programming book on your own, then take a class somewhere, to give you some structure while you get a good foundation...but you're gonna need to beat yourself into reading through a lot of technical material eventually. Once you've finally learned an assembly language, then move onto learning the instruction set for whichever console you like, and get to know the intricacies of that particular system. Aside from that, I think R2H2's code could use some line by line explaination, if for nothing else but curiosity: LDA $0DBF ;This means LoaD the value at $0DBF into the Accumulator ; As he mentioned, this is where the number of coins you ; currently have is stored. In short, he's going to check how many ; coins you have BEQ x ;Branch if EQual to the line labeled x - basically, he's going to go ; somewhere else in the program if the value now in the ; accumulator is zero. JSR $00F5B7 ;if that value wasn't zero, the program didn't jump, so if that's the ; case, he's going to Jump to the SubRoutine at $00F5B7 ; the subroutine at this location, as he mentioned, kills Mario x: RTS ;this line is labelled x, where that BEQ line jumps to. The ; on this line simply tells the SNES to ReTurn from the Subroutine ; basically, go back to what it was doing before it ran this ; whole segment of code to check the coins. Note that this line ; may or may not be executed if there were coins, depending upon ; where the subroutine at 00F5B7 sends you. If it returns you here ; it will be executed, but it might send you somewhere else, like ; a gameover screen. You'd have to look at that subroutine's code ; to find out My sincerest apologies for taking so much space to say so little. And for the sake of education, please, correct me if I'm wrong. |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 5/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| As far as learning assembly, the aforementioned NES ASM tutorial seems good, but if it's a bit more than you can chew, you might want to start at one of these: PC Assembly Language by Paul Carter, downloadable at http://www.drpaulcarter.com/pcasm/index.php Art of Assembly Language Programming by Randall Hyde, http://webster.cs.ucr.edu/ Assembler, Inside and Out by Harley Hahn. Microsoft Press, c.1992. ISBN 0-07-881842-7 They're more x86 oriented, but they're a bit more geared toward people who haven't programmed before. I particularly recommend the last one, since it's what I learned assembly from (but it might be a touch hard to find now), but the DOS version of the Art of Assembly one is pretty good, too. They both start out simple, with number systems, like Hex, and deal primarily with 16 bit registers and 24-bit addressing (if I'm remembering correctly) like the SNES. Art of Assembly's particularly nice, because you can buy the book, or look at it in HTML or download the PDF or a Zip file. The first one's more 32-bit processor oriented, and only in PDF format, but good if you need another source, if something gets confusing. Also, if anyone needs a guide in french or portuguese, the first site is the way to go. As far as more NES relevant sources, The NESDEV tutorial listed at Zophar.net I think is the best for beginners, and the 6502 reference Parasyte mentioned is far and away the best reference for the instruction set. For the SNES, the near equivalent references (though harder to navigate) are 65816info.txt and the 65816 docs, both here. Most of the assembly stuff for the SNES requires a background in 6502, or at least some background in assembly. So again, I recommend the x86 stuff first, since it's more geared toward those with no prior experience in assembly, and since it's easier to find stuff that's more complete, as well as revised and edited a few times over. (edited by DarkPhoenix on 04-26-05 02:29 AM) (edited by DarkPhoenix on 04-26-05 02:43 AM) |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 6/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Possibly found a little bug, or I might just be looking at this the wrong way, but it has to do with the skip instruction. Nothing major, just some confusing output. I'm running Zelda 3, I break execution at $008888, I step in a few times until it starts looping a CMP and a BNE. On the BNE instruction ($008894), if I look at next op, it just lists the BNE again. If I skip the instruction, it again, lists the BNE, and then proceeds to execute the LDA at $008898...that is, it seems to skip the SEP instruction at $008896. It certainly seems to be executing the instruction (as the M flag is now set), but I would've expected that the both the next op and skip commands would list the SEP instruction, rather than repeating the BNE. | |||
|
DarkPhoenix Octorok Level: 9 Posts: 7/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
I don't think getting a good conceptual foundation is anywhere as strange an idea as asking a person to learn something completely irrelevant to his ultimate goals (C++), or for that matter, as cruel as telling them to jump headfirst into material that college CS students often have trouble with, with only amatuer tutorials and reference manuals, regardless of which is theoretically faster (jumping headlong into 6502) or which would provide for the most theoretical background (C++).  Ideally one would go straight to 6502, but I've yet to see a 6502 document that's anywhere near as thorough, or for that matter comprehensible as a book on x86. Sure, it's another language, and it's not exactly like the 6502, but the concepts are the same, and there's some good professionally written material on it that's more appropriate for those with no prior programming experience. I think learning x86 strikes a rather happy medium between learning C++ first, and going in with no prior experience at all, and I think the time spent learning x86 would only be replacing time wasted with confusion from incoherent, deficient, or otherwise incomprehensible material. So in short, I think a person starting with x86 would be less prone to giving up. |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 8/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
 Thanks Parasyte, for the clarification, though I'd figured out that much, if I'm reading your right. I figured it stops it before the instruction, as if the address that the break is at were a label, sort of like how the GNU debugger stops at a label - before the instruction on that line is executed...but I still don't think that accounts for the problem I noticed...I'll reiterate the problem, hopefully a little more clearly1) on the BNE statement, it thinks both the current and future instructions are the BNE, and 2) when I step over the BNE, it doesn't update what it displays as the current instruction to be the SEP statement, so it still tells you that it's on the BNE, even though it's actually properly moved execution forward to the SEP statement or maybe this is easier to understand 1)I break at 8894 (BNE) 2)I display current intsruction and next instruction, they both display as BNE (I believe it should be BNE and SEP, respectively) 3)I skip over 8894 to 8896 (SEP) 4)I display current next instruction, they display as BNE and LDA, respectively (it should be, I believe SEP and LDA, respectively) 5)I step to 8898 (LDA) - note that it does properly execute the SEP It just doesn't display it 6)I display current instruction, it properly displays as LDA |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 9/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Any of you with more experience in 65816 than I might be able to answer this... Note: I'm running on the pretty safe assumption that game binaries are originally written in a high level language, and then compiled into 65816. When you compile a function call in a high level language into x86, there are always certain registers pushed onto the stack, among other things, during a function call. (though of course they could be different depending on the compiler). Because these are generated by the compiler, if you can identify that series of statements, I'd imagine you could more easily identify the beginning of a function. Well, my question is, has anyone seen anything like this (particularly things like a group of registers that are always pushed) in SNES binaries that would make the beginning of a new function more easily identifiable, or would I have to trace all of the branch and jump statements manually if I wanted to try to get an idea of the general layout of the code? Or, perhaps an even more important question...does anyone know of a tracer/disassembler for SNES that disassembles correctly and would let me output to a file? All the ones I've tried don't seem to properly follow the size of the registers, or have some other weird problem (like Tracer, which seems to interpret opcode 00 as BRK, rather than NOP, which throws off the rest of the disassembly) |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 10/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Thanks for the correction...looked up the opcodes, and yeah, it is BRK...I think maybe those 00's were being read as instructions because I hadn't set it to follow the accumulator size properly...my bad. As far as the JSR/JSL, I'd imagine that the address is pushed before the jump instruction...well, of course, before the instruction pointer is updated...which isn't as helpful, since then I might as well just go off the jump statement itself. As for disasemblers, I think I'll give Tracer another swing, since it seems I was just misinterpreting the problem. Should be able to fix it with a switch, I hope. Thanks again |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 11/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Regardless of how old the thread is, it'd be nice if the pictures still worked, for inspiration and ideas and the like, Particularly since this was a rather image intensive thread...anyone have any of the pictures on hand? | |||
|
DarkPhoenix Octorok Level: 9 Posts: 12/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| hey, I did not notice that...thanks. | |||
|
DarkPhoenix Octorok Level: 9 Posts: 13/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| I like the Intel stack frames ...but that's probably more because I haven't worked with anything else...[EBP]+8 and all that... If it isn't clear enough yet, I'm a touch new to disassembling stuff. What I was trying to accomplish is just to get a general overview of the code. It would be a bit time consuming, to say the least, to go through the entire disassembly...with Eclipse, (www.Eclipse.org ...not that I have too much experience with it) you can generate a diagram of a C program in terms of which functions call eachother...like a UML sequence diagram. I'm wondering if there would be a quick way to get something like that, of course with offsets instead of function names, so that when I go in and look at actual functions, I have a diagram of where exactly they stand in the program, and can eventually map out how the whole program works. Might just be the wrong way of looking at the problem, but I figured it makes dissecting C source code easier, so it might make the binary not so much a mess. In short, I'm trying to objectify it into a sequence of smaller bits of code. |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 14/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| A little off topic, I guess, but I'm not sure where else to post it, and I'd rather not PM, since I'd like the idea to be out in the open, but...that offset listing for Chrono Trigger, have you ever considered making a wiki out of it, for people to add to as they find new stuff in the ROM? I've not seen any Wikis on ROM hacking, either generally about the topic or about a specific game or aspect of it. It surprises me a bit, since it seems that a lot of people have something to add in regards to things like tutorials on ROM hacking, and it seems that a bunch of people have information on specific ROMs, but not a lot of it gets shared (like, for example, I'm sure a lot of people would kill to have the list of offsets used to make Lunar or Hyrule Magic, rather than have to either start from scratch or use the program). Well, back on topic. Your program kicks ass, but even better that you're sharing the information used to make it. Better than open source. Keep up the good work. |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 15/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
Those mapouts have their usages, particularly when browsing through a lot of unfamiliar sourcecode. With this, I figured if I could get a mapout, it'd just make it easier to go through and mark off what each function does, as I dissect the code, so I know where to find things later...Just a little more visual than throwing a ton of offsets into a txt file or a spreadsheet. Plus a little more helpful if I'm looking for something, and don't find it in the function I expect it to be in - I could trace my way back up the tree. Might save me some time...Mostly I'm operating on the idea that it might be easier to get through the code if it more closely resembled something of a higher level, so I figured breaking it all up into functions would be the first step to that end. Also, more along the same lines as the program you're working on, if you know the beginning and end of each subroutine, then you have a pretty good idea of where the code is and where the data is, at least for the large chunks of each. Again, my overall idea here was a more abstract interpretation of the file (I've been having mixed success with the usage maps in Geiger's debugger). I get the idea you think it's kind of a waste of time, though, so perhaps my time would be better spent just tearing into the code  |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 16/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| A small request, just to make things a little easier... For instructions in absolute, and possibly even indirect addressing modes, you quite conveniently provide the full address in the output, but, if it's not too much trouble, could you also provide the value stored in that address? for example, with 0D/F102 D9 F9 F9 CMP $F9F9,y [$0D:F9FB] A:0062 X:0000 Y:0002 could you also include the value stored in $0D:F9FB? I know the debug console's getting a little cluttered with all the information, but it'd save a whole lot of scrolling through RAM, which would make it much easier to figure out exactly what a subroutine is working with, particularly if it's working with data from all ends of memory. Also, just a suggestion, but to clean up the debug console, you might want to consider using a list view control to display the output...harder to implement, but it'd save you some trouble with formatting at least, and then we could just shrink and expand things as we need them. It'd make the app a lot more friendly with lower resolutions, and get rid of problems like that one with the "skip" output printing offscreen. (edited by DarkPhoenix on 05-01-05 07:08 AM) |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 17/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Hey, been posting for about a week now, and managed not to introduce myself yet. I've been reading from this site and following emulation development for quite a while, but never really dove into it until recently. My experience is primarily with x86 and C++, only just recently reading up on 6502 and 65816. More specifically, my experience is quite limited to MFC / WinAPI and 32-bit console applications for DOS and Linux. As far as Rom Hacking goes, I'm focusing on Zelda 3. I however, likely won't release much of anything (in terms of a patch) for quite a while, as I'm a perfectionist, and most of my ideas are rather complex. As much as I've just started, I'll try to lend a hand with any questions about it on the Rom Hacking board, since there's apparently a lack of completed hacks for it. But I warn those with questions, I know little of the inner workings of Hyrule Magic, as I prefer to reinvent the wheel sometimes. Though I do have the ROM addresses for a decent chunk of the data that it operates on. So, that's about it. I'll probably mostly just be hanging around the Rom Hacking board  |
|||
|
DarkPhoenix Octorok Level: 9 Posts: 18/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| Well, I just mean complex in that it'll involve a lot of work in different areas, not necessarily that it'll be tricky. Though I do like to dive into the more esoteric stuff first, like disassembling and rewriting subroutines, and save things like level design and graphics editing for last. This way, if I come up with something clever, even if I don't finish a hack, I can at least post some assembly tricks, and let someone else have the fun with things like level design. But more likely, I probably won't release anything until I have a solid patch with a little bit of everything changed. | |||
|
DarkPhoenix Octorok Level: 9 Posts: 19/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| That's true...didn't really think of that...List Control's out, then, but I think the DataGrid control has native clipboard support. I've never used DataGrid myself, though, so I'm not 100% sure, and I don't know how easy it is to implement | |||
|
DarkPhoenix Octorok Level: 9 Posts: 20/31 EXP: 2669 For next: 493 Since: 03-08-05 Since last post: 23 days Last activity: 16 hours |
| ||
| The editor for Zelda 3 that you're thinking of is Hyrule Magic. It's not quite Lunar Magic, and it's got some issues (dungeon doors...), but it's certainly a good start. It's on http://www.Zophar.net , somewhere amongst the hacking utilities. As for Sonic 2, mm...well, a lot of the good sonic hacking sites I knew of are dead...but http://ssg.g4m3r.net/ might have some useful stuff for you. Aside from that, good luck. Edit: More sonic stuff at http://ssrg.shadowsoft-games.com/ and http://www.hacking-cult.org/s2hack/index.htm (edited by DarkPhoenix on 05-03-05 03:14 AM) |
| Pages: 1 2 |
| Acmlm's Board - I2 Archive - - Posts by DarkPhoenix |
