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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - STARWIN

Pages: [1] 2 3 4 5 6 ... 20
ROM Hacking Discussion / Re: FF3/6 (SNES) 2P question.
« on: July 18, 2019, 01:43:28 pm »
You check how the keys are read and at low enough level OR P2 keystate to the existing P1 keystate in an asm modification. The hardest part is finding free space to put the extra asm bytes in, which isn't terribly hard either compared to what various folks here are doing in their projects.

But a design like that sounds messy to play. I would prefer the way I did it with FF3 NES / FF5 SNES, where you need to swap the main (shown) character, and that determines who controls.

The existing partial control sharing in battles wasn't quite perfect when I played FF6 coop last time, but was okay for the most part.

These two were on my radar for a long time, so appreciate seeing them translated. Nice going with the projects folks!

cheat engine targets the emulator, which runs on x86, which is why you see that x86 stuff there. i wouldn't do it that way. i'd use the debugger emulator to set breakpoints and stuff.

those addresses have nothing to do with the ps1 addresses.


consider most addresses as 80xxxxxx, so 8008C11D.

idk what you are using but no$psx is my main tool for ps1. armips for compiling asm to binary. cdmage b5 for extracting/inserting files from/to the cd image. hex editor for manually patching something minor in an extracted file.

Programming / Re: How do I skip an operation, or a section of code?
« on: April 06, 2019, 09:26:27 am »
If you don't like pSX, you can also try no$psx. The help files contain his documentation, but it is also available here:

You could check the CPU section there for an asm reference.

You generally want to find the code in question with the debugger. You didn't specify what you exactly want to change, but you could perhaps make it auto pick the first pick if it listens input at that point, or turn all the choices the same or try skipping the whole functionality, if you can see a way to do it without side-effects. These changes should be destructive in a way that lets you do your changes in-place, not having to search for free space (yay).

You can often find the original code spot in the ROM by searching for the machine code sequence from the CD ROM image. Although modifying the ROM should be done by extracting the file where the code is with cdmage, modifying it, and inserting it back, so either figure out the file from the ROM offset or search each file with a hex editor separately.

If you at some point need to turn your asm snippet into binary, try armips.

i was basically suggesting you to create multiple patches for those cases, but let the utility hide that from the end user.

perhaps disabling validation will work for your use cases, but i believe there is always the risk of one of the patches referring to a region that another patch alters.

ROM Hacking Discussion / Re: Something like xdelta that can stack patches?
« on: February 06, 2019, 04:12:18 pm »
how about a custom patcher that hides the complexity from the end users?

the difficulty of making a coop hack depends greatly on how much you need to change to make it happen (as with any hack). i did as a beginner, and it was doable because i only adjusted which controller is being read depending on the ingame state. i'm not familiar with paper mario games, so i can't comment more on that, although GC is certainly more complicated than NES.

I've used vbindiff, in case you need an alternative.

ROM Hacking Discussion / Re: Help patch codes to an ISO [PSX]
« on: November 08, 2018, 05:55:09 am »
for some types of read-only data and most code you can try searching the iso for the sequence you see in debugger ram in that spot in the gamestate where the code works.

for variable data you have to change how it varies instead, so the actual code you have may be useless other than for its location and format.

so it depends on what your code does.

Newcomer's Board / Re: How to find memory locations for scores / lives / etc
« on: September 26, 2018, 06:38:55 am »
A major external source for these are cheat codes, which often show the RAM location in the code. I don't know if this holds true for all systems and all cheat devices though.

For something primitive like NES, FCEUX already has a cheat search tool included that you can use in Tools -> Cheats. Check its documentation on how to use it. I would recommend avoiding the greater or less functions there, as values can be packed within bytes.

ROM Hacking Discussion / Re: Suikoden II Bugfixes
« on: September 01, 2018, 06:13:58 pm »
I remember the same person made something similar for the first Suikoden that fixed only a few bugs (escape talismans, bribe, and a couple of the rune spells doing nothing I think), and it was dedicated to the 1.0 version of the US disc.  If anyone should happen to know where on the internet it ended up, let me know!

if you put everything else in its place correctly and leave these spots empty, then this program will fill them for you. there's source code in there if you really want to see how.

ho-hum, if the cpu loads an address you already know what you want to follow backwards. this isn't usually a difficult task if i got the situation right..

if what determines it is in a register, you check the earlier executed asm until you see where it gets that value.

if it is hardcoded (instructions that generate the value, or values loaded from cd rom), then you found the spot.

otherwise it uses other values to create this value (like for example taking n:th value in a table, which combines the address of the table base and n). you can document the knowledge read to a text file and keep going backwards.

if it uses a temp value from ram (not something read from the cd rom) you can usually trace it backwards by having a save state slightly before this exact point in the game, set a write breakpoint on the desired location, load the earlier savestate and run. this works well unless it reuses the same spot many times earlier (if just a few times, run it until you see the familiar value), which often happens with stack locations and sometimes elsewhere (if the earlier savestate is too far away).

if it uses a value that is given as a parameter to the function you are reading (either via register or stack), you can often step out and check what was immediately sent that way before it was called. stepping out once or twice and making a breakpoint before the current call is also one way to get the earlier savestate.

edit: if you need to search the savestate for some reason, you can set them to "raw" format in no$psx file options.

(also please any suggestions regarding the code, maybe there's some abstractions I'm not aware of and it can be made easier to understand)

you can zero init the buffer with char buf[BUFFER_SIZE]={0};

if buf is declared at global level, it will be zero init even by itself and you don't have to pass the array parameter when calling push

i would always have the code block after if well defined with { } around, even single liners, and that second line with EOF may be broken btw

there is almost never a reason to use a short int instead of int

(you can declare i temporarily "for (int i=0;" in for instead of declaring i earlier, if you want)

if you want to reduce copying in push, you can have a globally declared "int start=0;" and use the following:

pull with =buf[(start+offset)%BUFFER_SIZE];

push with buf[start%BUFFER_SIZE]=c;start++;

(not tested)

(it would be good manners to set start to 0 when it grows big enough, but i doubt it matters here)

Dunno the answer but no$psx offers some logging capabilities under Window->TTY Debug Messages if that helps.

Personal Projects / Re: Romancing Saga 3 English re-translation [WIP]
« on: January 29, 2018, 08:56:41 am »
That could be a good choice when all miscellaneous text is translated, but I think it would chaotic right now. Just imagine hundred of emails reporting the same text with the same player, plus complaining about not all text completely translated into english.

Just noting that if the testers report to a common place, like this thread for example, it would reduce those duplicates and perhaps be easier to manage than individual emails.

Personal Projects / Re: Romancing Saga 3 English re-translation [WIP]
« on: January 28, 2018, 05:49:57 am »
Most of people aren't native english speakers, though I think we can still spot accidental spanish or out of box printing. :P

While I understand the idea of trying to spread different characters to dedicated testers to maximize coverage, I suspect that an open beta would be more efficient. Covering everything in a game with a lot of branches like this is hard anyway, and less organization/attention is needed if you just leave an open beta available and wait for reports. It worked pretty nicely for the RS1 project I think.

It would be easy for me to play the game because it is great, but I couldn't *guarantee* dedicated testing right now personally.

Programming / Re: Bsnes problem
« on: January 12, 2018, 04:00:24 am »
I would examine a bsnes-plus tracelog if I were you. That I imagine would be enough, but it is possible to make a tracelog in something like geiger's and compare the logs too.

Gaming Discussion / Re: How do i burn Bin Cue on Windows 7? ?
« on: January 09, 2018, 05:55:55 am »
Playstation CDs use non-basic modes, so they are not compatible with the ISO format, but some other CD based consoles are. Also, since some PS1 games from the PAL (Euro) region used a copy protection which stored vital game data in the subchannel data (aka LibCrypt), such games require a BIN-like format plus subchannel data.

If the PS1 game only contains 2048 sectors (no audio or m2f2) it can probably be mapped to an iso. This might work for emulators, but IIRC the first 16 sectors are messed up and you actually lose parts of a necessary pattern there (which cannot be regenerated from user data) so someone burning should prefer bin/cue or more.

Pages: [1] 2 3 4 5 6 ... 20