News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: [SOLVED] PSX/No$ Debug, Syntax Diff., Address Won't Break  (Read 1562 times)

ShadyRounds

  • Jr. Member
  • **
  • Posts: 40
  • Apathetic, yet Helpful.
    • View Profile
[SOLVED] PSX/No$ Debug, Syntax Diff., Address Won't Break
« on: October 14, 2017, 02:40:31 pm »
*Skip to End for Question:
Background: I am a Megaman Legends fan. I want to create content for the kinsmen of my fandom to enjoy, and extend the content-hours of my beloved game series, and possibly by the deadline of the Dec. 19th 20-year anniversary of Megaman Legends.

Goal: I have ideas in mind to implement, endgoal being a variety of patches for gameplay, including item shuffling, restoring some japanese-only functionality like kicking-paprika, the music track "another sun" which exists in eng-rom but isn't hooked to play, and restoring functionality of the developer ingame-debug-menu... but to run, you must first walk, and to walk, you must first crawl, but before you do that, you must learn how to breathe upon entering the world for the first time. I have my work step-by-step laid out, but in order to make yuge things, I must first learn how to do very stupid basic things with the game code.

Progress: 1) I had started this project with a loose association with the LegendsStation community, and a few of it's members that had pioneered ram-hacks for the game. 2) I found a massive amount of documentation on romhacking, a lot from this site so I already owe this place a place in my credits txt. So I began with documentation on Zelda OOT and felt that Megaman64 was a crummy port but by far the best chance I had at compiling a romhack. As I progressed, I found an actual romhack hosted here for Megaman Legends PS1, originally created more than six years ago! It has more than enough documentation to know how to modify text and pack ips patches, so now I'm working with intent to romhack the PS1 version. Gathered as many hex editors, debuggers, and assembly code programs as I could. So far I'm using LemAsm for rom assembly, PSX1.13 and No$PSX for debugging, HxD for hex editing and searching, Transhextion for thingy-tables to read and handle in-game text, FrHed for comparing differences, and am working with MegamanLegends (eng) and RockmanDASH (jap) disc files.

Progress (Cont.): 3) I have found the location of various text in rom (inside of ST00 bins for location-specific, in rockneo.exe for always-loaded assets like menus and items). The LegendsStation chums have some time in the last 11 years found things ranging from Health, Ammo, Morality (easy values), to the HUD, Camera Control, Stand and Walk when In Mid Air, Which Location a Door Takes You (Tau, Megaman Legends Abridged), to things like NPC Health/Script/Spawn for all 16 npcs that the game can load for one area (Trege). I'm trying to both bridge these ram-hacks into physical rom-hacks, which is apparently a new angle to the current crew at LegendsStation, but it's becoming an idea respected at an equal level to work that members have been working on for years (which is exciting and appreciated).

Problems: Something I figured was a really simple test of "doing something profound", was changing the value of the "starting morality" in the rom. This is the value that the game tracks in-game, that loads darker texture for armor, loads different dialogue variants of how townsfolk depict Megaman, and this value starts at 128 (x80) at game start and increases naturally but decreases when doing "bad" things like kicking trash at the baker or vandalizing vending machines or keeping money from a bank robbery or shooting a civilian news airship.

To find the value, I scanned for it, kicked vending machine, scanned for decreasing value, kicked vendi... wash rinse repeat until I got it. The ram value is located at 0C1B70 (fun fact Trege discovered, the ePSXe1.9.25 retains the same memory location every time it loads a game, it doesn't shift around unlike other versions, so it's useful when using CheatEngine where morality's value is always B4D210). Well, monitoring the value on CE, I found that toward the end of the black "loading..." screen at game startup, the address byte fills to 80 (the value one starts with). I figured I could trace this, search nearby byte strings, ect, to find it in ram... and have ran into problems with this seemginly soft-test.

Problem1) When starting, PCSXTrace was considered a top-tier tracer, and PCSX1.5 w Amego was another highly rated program. After much trouble getting the right old-plugins to get them to work, it turns out they're very crash-happy, but specifically do not run MegamanLegends for neither love nor money (or RockmanDASH or any prototype builds). Does anyone here know how to make them run... better?

Problem2&3)
-When using No$PSX, the debugger says "huh?" every time I do anything, and even though I eventually get it to work it also doesn't use the same opcode syntax (mov instead of lui and stuff). Why do they call the same operations different things?
-So I use PSX1.13 r3000 debugger, to create a break on the loading-screen that fills the value at start. It breaks, but the emulator cannot resume from that point once it breaks, you can read the debugger but the emulator will crash upon refocus so it's a restart from there. Is that even normal for PSX1.13 to crash every time it performs a debugger break?
-The PSX1,13 break specifies a certain instruction from 664BC, and I go to it in rom. It's blank, 00 not 80. I reload the game, turns out that value is also filled to 80 during the load. It was supposed to be a simple read from rom, wth Capcom?
-Well, I create a break for 664BC now, but it won't break on either debugger on write. It writes from 00 to 80, while the break is watching it, and never breaks. Am I missing something?

 :woot!: Thanks for any replies, sorry for all text catching up to where I'm at, and if this makes any breakthroughs I could ask a few more things about other problems too.
« Last Edit: October 18, 2017, 07:47:32 am by ShadyRounds »
Apathetic, yet Helpful. :beer:
Project: Megaman Legends Remix

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 7086
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: PSX/No$ Debug Same Opcodes Different Abbrev. (& Won't Break)
« Reply #1 on: October 15, 2017, 12:30:20 pm »
I think no$ developer uses X86 opcode mnemonics be default for all his emulators.
There might be an option somewhere in the options to change it.

That is as I recall as I had to use his SNES emulator before as it is, to my knowledge, the only emulator (at least with debugging features) to emulate a feature I needed (TurboFile).

I have only done little progress on a single PS1 translation, but as I understand you can't directly read from CDs (the "ROM") as you can do with cartridge (although even N64 I have heard doesn't run directly from cart ROM for technical reasons probably). The data has to be read from the CD into the RAM before it can be used/executed.
"My watch says 30 chickens" Google, 2018

STARWIN

  • Sr. Member
  • ****
  • Posts: 454
    • View Profile
Re: PSX/No$ Debug Same Opcodes Different Abbrev. (& Won't Break)
« Reply #2 on: October 15, 2017, 03:48:58 pm »
Well, monitoring the value on CE, I found that toward the end of the black "loading..." screen at game startup, the address byte fills to 80 (the value one starts with). I figured I could trace this, search nearby byte strings, ect, to find it in ram... and have ran into problems with this seemginly soft-test.

Tracing can be a nice extra feature. no$ also allows tracing in window->TTY Debug Messages. I'm not sure if it is ever really needed though. So, if I got the situation right, you should use a write breakpoint to figure out where the 0x80 comes from. If it is just from code, that code will break and you can then go to the address of that code in the memory view to get the bytes that you can search to find the spot in the cd image (if you redo checksums) or preferably in an extracted file that you insert back after modifying it..

-When using No$PSX, the debugger says "huh?" every time I do anything, and even though I eventually get it to work it also doesn't use the same opcode syntax (mov instead of lui and stuff). Why do they call the same operations different things?

Yeah, it likes to huh. The internal logic is a bit unclear.. I probably figured it out once or twice but forgot as well. The naming scheme can be changed in the options. http://problemkaputt.de/psx-spx.htm#cpuspecifications shows both namings. For the most part I like reading the nocash syntax more.. what matters in the end is that the system they represent is the same.

-Well, I create a break for 664BC now, but it won't break on either debugger on write. It writes from 00 to 80, while the break is watching it, and never breaks. Am I missing something?

What I have seen, the upmost bit is always set in all (standard) ps1 addresses. So try 800664BC.
« Last Edit: October 15, 2017, 03:57:56 pm by STARWIN »

ShadyRounds

  • Jr. Member
  • **
  • Posts: 40
  • Apathetic, yet Helpful.
    • View Profile
Re: PSX/No$ Debug Same Opcodes Different Abbrev. (& Won\'t Break)
« Reply #3 on: October 15, 2017, 06:16:39 pm »
I appreciate all the quick replies. I'll try a few things when I get home, may make a video of the problem to see if it's obvious, but I know about the upper byte address of 80 already, that kept me from getting this far once upon a time but it's my fault not reading no$ help screen.

October 16, 2017, 04:19:54 am - (Auto Merged - Double Posts are not allowed before 7 days.)
I discovered something that isn't particularly new to me, in the sense that Christopher Columbus discovered America... and that is that I... am completely f**king stupid.

So, I was thinking, it isn't that Rom can't be scanned until it's Ram, it's that it has to be traced to where it's fist loaded as Ram and then it's identical. I then realized, it's probably not same address. I scanned Rom for different address, same 12-bytes all nearby it, and found a match at legends.img hex-address 0C6684. Changed it, and...

...well I'll be damned. It works. Literally. Start as Dark Megaman, from begining of New Game, straight from Rom. Well damn guys, it's very mundane, but boy isn't this a good start! I'm so excited, and again, thanks for all of your help. I hope I don't need it going into my next stepping-stone goal, but I'm glad I started a forum presence just in case, because my money is on I'll more likely need it than not. Thanks so much. (EDIT: Excellent news, the values of npcs/chests can also be found in rom this way. I can really make my project a reality now and I am so happy, seriously, thanks so much!)

P.S.: So I take it, this means the answer to my original question was: The debugger cannot break on a value that's being loaded in for the very first time from the disc. What is it supposed to break at? The playstation's own instruction that's moving 0x0500000 of bytes to even initially load? I know, that should have been pretty obvious huh? I'm just glad I eventually solved that for my own sake of progression.
« Last Edit: October 16, 2017, 07:47:28 am by ShadyRounds »
Apathetic, yet Helpful. :beer:
Project: Megaman Legends Remix