1

Script Help and Language Discussion / Re: kanji recognition

« on: December 25, 2014, 01:17:07 pm »

Chunk it out and use an OCR program.  There are several available for free, and Google used to have one (online) that worked pretty well.  Chances are that will only get you 95% of the characters at best, but you're probably more likely to find help for 5-6 unknowns than a whole sheet.

2

Newcomer's Board / Re: Adding files to PSX ISO?

« on: December 02, 2014, 12:12:52 am »

Whoops, forgot I asked here.

I extracted the ISO to a directory, created the file, then created a new ISO from that. I figured that whatever sort of copy protection would stop that from working on an actual Playstation wouldn't trigger with an emulator.

That may or may not work depending on how you built the disc image.  If the whole thing was built in strictly Mode 1 or something, a good bit of the data will probably be trash from the hardware's or emulator's perspective.  If you're looking at this as a learning experience, I suggest using the opportunity to learn how to use PSX CD-Tool, or the LUA Interface kit that grew out of it.  Using those, it's fairly easy to extract the contents of the entire disc, and rebuild it while maintaining correct formats, and inserting files however you wish and in whatever order you like.

Would this LBA/Size list be in TITLE.EXE, or am I misunderstanding what "main executable" refers to?

Typically the main executable is named with the Sony-issued serial number, e.g., SLUS_000.00 in the root of the disc.  However, open up SYSTEM.CNF in a hex or text editor.  That will tell you what executable loads when the PSX starts up the game.  If there are multiple executables, that may not be the "main" one, though.  For instance, TITLE.EXE may load immediately to display company logos and such, and then it hands off to the main executable when you press start or choose an option from the title menu.

That said, any PSX executable file will most likely have the file listing inside it, assuming one exists, and it may be in other files.  In order for the game to function, you will probably have to apply any required corrections to all copies anyway.  So find it once, and then search for it elsewhere.  One game I've worked with has hundreds of files that contain executable code (but only one proper EXE), and something like 60-70 of them contain an LBA+size listing for the entire disc.  Every time I rebuild an image of it with new changes, the listing must be updated in all of them.

3

Newcomer's Board / Re: Adding files to PSX ISO?

« on: October 28, 2014, 08:16:13 pm »

Well, they provide very little detail about how the file actually needs to be inserted.  Did your tool update the table of contents when you added the file?  Where did you add the file in the BIN directory?

If the tool you used to insert the file keeps the table of contents up to date, there are a couple of possibilities I can think of:

• The intent is that DEBUG.BIN be the last file on the disc.  Looking at the ISO, it appears that the BIN directory is fairly early, so you might have to manipulate the tool a bit to get a file inserted at the tail-end of the image.
• The usual reason for the ISO not working is that the game looks up files using a listing stored in the executable(s) somewhere.  Adding a file will force everything out of agreement with the listing.  You can probably find it by search the main executable for the LBA of one or two files from the original.  In the cases I have seen, the listing is a 32-bit LBA followed by a 32-bit file size.  The pattern repeats for each file, but not necessarily in perfect ascending order.  I mention this because you may be able to narrow the search a bit by looking for two contiguous files, but if you get no results it might only mean that the listing is in some wonky order.

Hopefully the first one isn't what you already tried.  If it is, the instructions on TCRF probably omit a few annoying steps.

4

Newcomer's Board / Re: Having palette issues. Need some help.

« on: September 25, 2014, 11:55:10 am »

Yeah, in the VRAM viewer you're using 4-bit grey, which doesn't bother with CLUT values.  Hit the 9 key to switch to 4-bit/CLUT and then the arrow keys will let you select the right palette from the bottom left.

In Suikoden II the sprite sheets, portraits, and so on are stored, compressed, in the various module files.  Locating the image data varies from file to file, and I've by no means dug up all of it, but it's typically stored as 4-byte size, followed by a 1 byte flag (which IIRC just indicates if the data is compressed or not) and then <size> bytes of data.  If the data is compressed, it can be decompressed as shown here:
http://suikodenbugfixes.wikispaces.com/Suikoden+II+Data+Compression

CLUT data is stored separately from the pixel data, and there are sometimes multiple tables to choose from.  Konami opted for having code everywhere, so the data is somewhat unstructured, and it's often easiest to just try the available color tables until one looks right.  You'll just go mad trying to find some way the data indicates what to use.

5

ROM Hacking Discussion / Re: FF7-PSX. Trying to fix w-item's glitch

« on: August 05, 2013, 07:50:04 pm »

There's not a lot you can get from that code that could be translated into something to search for in a PSX executable.  Most of it is clearing registers and establishing the address of the quantity.  Assuming it is what you say it is, which looks likely.

All you can really tell from this is that the quantity is a byte, and you can expect to see a load byte, followed by an addi(u) of 1 to that value farther down, and then a store byte followed by a check on the value's upper limit (99).  You'll probably get faster results just searching for immediate operands of 0x63 in IDA, and using a GameShark or PEC or whatever to see if you're changing the right operation.  It sounds like the guy you got this from is removing the store operation, so you can go that route, and see if you can replicate his results.

Honestly, you probably guessed all of that yourself.

6

ROM Hacking Discussion / Re: Extract .xa, .str and rebuild PSOne image from .bin .cue

« on: March 25, 2013, 12:57:10 am »

The usual method is to just dump the raw sector data with a tool that can handle that.  I'm not sure if ISO Buster fits the bill, but if I remember right, it always shows the file sizes as though the sectors are Mode 1 (Windows Explorer will do the same when you mount the image, or read a CD).  XA and STR data aren't Mode 1, and the sectors store more data.  If you do a raw extraction, you're also getting the sector header and whatever else that sector has besides the user data, so it'll show up larger on your hard disc.

This guide might be a little outdated, but it covers the basics:  http://www.tales-cless.org/docs/thepsxdoc2.txt.

Personally, I use CD-Tool, but it botches the CD-XA data on the game I needed it for unless I have it pull Mode 2 data by raw sectors, and write it back the same way.  Mostly because the company did a poor job of mastering their disc, and I don't think CD-Tool could keep up with their blundering.  You can probably just copy the data normally using a simple call for MODE2.  The URL in the document above doesn't exist any more, so here's one place you can find it:

http://suikodenbugfixes.wikispaces.com/Tools

7

Programming / Re: Emulate 16-bit ADC on a modern system

« on: December 27, 2012, 12:03:22 pm »

Edit:  actually, I misread the code there.

8

Programming / Re: RPG games made in either batch or c++ on youtube

« on: December 15, 2012, 05:29:52 pm »

It looks like whoever coded that last game knows your secret of using a second variable to test for critical hits.  You should probably seek counsel from an IP lawyer.

9

Programming / Re: Algorithm for returning a turn.

« on: December 12, 2012, 11:06:38 pm »

I think what you're ignoring is that your snippets are exceedingly simple, and not interesting or novel to anybody who comments regularly here.  I don't mean that to be an insult, it's just that I don't understand why you keep posting them.  Unless you have a question, they're not worth discussing.  If you had declared player MyPlayer and then attempted to set the agi property by MyPlayer->agi and wondered why it wouldn't compile, there might be some value to this thread.

You keep comparing yourself to some less experienced friend too, which is kind of weird.  He can't be more than a few months behind you, unless you have an extensive background in Easytrieve or something.

10

ROM Hacking Discussion / Re: bad coding in roms

« on: December 11, 2012, 06:52:53 pm »

It's two operations created by the compiler to enforce type; they're not slowing anything down.  Without more code, it's not even apparent that $a0 is unsigned, but even if it is, there can be any of number of reasons for casting it as signed.

11

Programming / Re: [rusty asm] Call a routine from a routine

« on: December 06, 2012, 10:42:50 pm »

Personally, I just assumed it was another add-on operation like the supposedly EE-specific op codes for the PS2, until I thought about how many unused bits that would leave JALR with, and double-checked the instruction set.

In fact, I modify an existing game and am affected by size issues, so enlarging the stack, storing ra then getting back its value and decreasing the stack would necessite more op.

jalr link, adress is not an option (although it's interesting and I did not know about that) because both routines are in the game and end both by jr ra.

Thanks for all these enlightenments

What is it that you're doing?  It sounds like you're trying to add JALs to a routine that doesn't already have them, and it therefore doesn't bother saving $ra.  There are ways around that, but just how depends on whether you're doing run-time modification or patching the ELF.

12

Programming / Re: [rusty asm] Call a routine from a routine

« on: December 06, 2012, 10:59:38 am »

JALR still uses $RA to store the return address (PC+8).  It just lets you specify the address to jump to on a register instead encoding it into the OP.  If you're going to use any variant of JAL on a PS2, you need to ensure that $RA's value will be restored.  How you accomplish that depends on what you're doing.  If you're just writing code from scratch to assemble and run, you should follow the general rules and preserve on the stack.  If you're doing something like making cheat codes, or modifying the game by inserting code into the ELF somehow, you can get away with other tricks (I've stuffed it onto $S* registers that are saved by target routines before to save operations).  Although, if what you're doing is complex in any way, you'll probably be better off following the usual etiquette regardless of your goals.

Edit: I take that back.  There is a rarely used option in the JALR op-code that lets you specify the link register ("JALR link, target" as opposed to just "JALR target" with $RA being implied as the link register).  I've never even seen it in a game ELF.  It seems like doing that would just make things confusing.

13

ROM Hacking Discussion / Re: bad coding in roms

« on: November 27, 2012, 10:26:51 am »

Yeah, I know what R0 is.  That's why I asked for clarification, because I wasn't sure how far the rabbit hole went.  I assumed they'd have to write that code directly in assembler to do what it sort of sounded like you were saying.  I'd like to think even the N64 SDKs would see something that essentially means if (1 == 0) and just throw it away.

14

ROM Hacking Discussion / Re: bad coding in roms

« on: November 27, 2012, 08:32:32 am »

...if some of these routines weren't dedicated to testing for this error code.

What does this mean? After they store at 0(R0), they load it back sometime later to test it?  From your description of the oddity, it sounds like a few instructions later you're seeing them explicitly stick 1 on V0 and then test that against R0.

15

ROM Hacking Discussion / Re: PSX hacking finding the value digits of a codes address

« on: November 19, 2012, 07:27:02 am »

Some code-hacking goes on here, but it's not really the point of this forum.  The short answer is that it can be anything you want or need it to be, and there's not necessarily one correct value that you just pluck from somewhere.  For the most part, what you're really asking here is "how do I hack codes?" (unless there's a language barrier issue), and there are already dozens of guides on that.

Try this guide for a start:  http://gamehacking.org/faqs/hackv500c.html

16

ROM Hacking Discussion / Re: bad coding in roms

« on: November 18, 2012, 11:31:39 am »

Yeah, nobody usually cares about the return value from memset, but NOPing the call probably wouldn't be a good idea.

Suikoden II on the PSX is just loaded down with debug code.  The game is done in hundreds of modules that load at fixed addresses, and the modules will call various functions from the main executable via JALR register jumps.  I guess they solved the issue of dealing with common code via a ton of extern function pointers or something.  Regardless, every time one of these calls is done, you see:

Code: [Select]

la $trace_reg, ModuleTrace
sw $call_reg, $trace_regSince it uses these functions pretty regularly, there's probably about half a KB or more of wasted instructions in a lot of the modules.  These instructions are pretty trivial, so it hardly matters, and every time it happens I have 3 more op codes I can add without taking anything away.  I can take back more if I change all the JALRs to straight JALs.  All the debug prints they left in are slightly less trivial.

One really weird thing they did was having two sets of code for battles.  One runs during the first round of a fight, and the second set runs during the second round onward.  It's not that there's an "if" statement or something.  They actually overlay the code from FST.BIN with code from SEC.BIN while the battle animations run.  About 90% of the code is identical, so I guess they were worried a couple of overloaded or extra functions would overflow the 200 or so KB they allocated to hold the code.

17

Personal Projects / Re: Suikoden II Bug Fixes (PSX)

« on: November 15, 2012, 08:36:07 am »

• If you mean higher quantities than expected, like "Angry Blow x8" or "Medicine x9", that's not a bug.  Any item that comes in sets like that can have as many as 9 copies.  The developers just elected to have some people join up with sets that you can't otherwise get, or that are only dropped very rarely by certain enemies.
• I'll keep an eye out, but I can't promise much will happen without more details and specific information.  There's supposedly a bug in Tinto that pops up when you do certain events in unexpected sequences.  I've actually seen video of it happening, but I can't get it to trigger for me at all.  This sounds like it might be a similar thing.  Also, does it happen when she's really dead or fake dead, or both?

18

Programming / Re: Organized Battle System.

« on: November 13, 2012, 06:10:37 am »

No, it is not "depending on the algorithm", it is guaranteed (by the c and c++ standards even) that the same seed will always result in the same sequence.

I didn't intend to speak only for C/C++, and their standard algorithms.  I probably should have, though.

19

Programming / Re: Organized Battle System.

« on: November 12, 2012, 06:08:01 pm »

For the most part, seeding is initializing the random number generator's state.  Depending on the algorithm, seeding every time you generate a number can mean you just get the same number every time.  Even if that's not the case, there's no reason to keep seeding like that.

20

Personal Projects / Re: Suikoden II Bug Fixes (PSX)

« on: November 12, 2012, 08:38:14 am »

well, this project made me start a replay on Suikoden II I've been checking the bug fixes and wow, I have to admit some of the bugs went totally unnoticed the first time I played this game. now with my mind set (slightly) into finding weird stuff, I've noticed what seems to be another bug found in the European (Spanish) version:

if you have a full inventory and receive an item after a battle, you get the choice of dropping it or put it in your "bag", dropping another item instead. selecting the latter option will pop up an inventory window to let you choose the item to drop. when you set the cursor over an item that hasn't still been appraised (i.e. ? vase), the description shown is the one of the appraised item (instead of "not appraised object").

seeing how you've managed to fix a similar issue (the scroll shop), I hope this won't be difficult. keep up the good work!

Thanks.  As far as I know, that bug has never been reported, so good catch.  It should be an easy fix.  They have a function that retrieves descriptions, and one that wraps around it and outputs defaults for unidentified stuff.  A couple of people didn't get the memo on which one to use, I guess.

I'm guessing the Gaiden translations would be going fairly normally, if not for everything taking such a long time.  I'd kind of expect a project like that, using a mix of people experienced and inexperienced in doing fan translations of games, to see a huge burst early, then settle into doldrums while the translators work up a first draft, and then the technical workers play catch-up and solve any problems they didn't foresee in order to wedge the draft into the game.  Then it's just a matter of review and refinement.  Or so I assume.  It seems like the delays have led to more delays because of lost expertise and so forth.  It also seems like this is a first or second translation project for most of the people involved, so some stumbling is to be expected.

I'm with you on the Suikoden II script.  Given the parameters of the project and the issues they faced, the translators did a phenomenal job.  Like I said, I want to put together tools that make it easier to review and modify the text.  I'd might as well make it support the Japanese character set while I'm at it, so if anybody wants to clean up, re-translate, or translate one version to a new language, it'll be possible.

I don't know how the scripts and such were presented to the original translators, but in the compiled data things are really weird and disjointed.  You have arrays of dialogue pointers and arrays of pointers to them, and none of them have any counts or bounds associated with them.  Everything is referenced by relative indices.  If you want someone to say line 0 in array 0, that's all you tell it, which is fine.  Where it gets confusing is that each area, say Ryube, has a list of every actor/element that can be on the screen, and this is then referenced by multiple arrays that define what is in the room at given times.  I've taken to calling them "taxonomies" and "ecosystems" to keep them straight in my head.  At any given time, an ecosystem might have 1 of a particular NPC or creature, or twenty, but the taxonomy only holds them once.  Anyway, the scripts reference items by their index into the ecosystem, so looking at any given file, it's difficult to tell if character 9 is say Eilie or some random NPC, or a treasure chest, because it depends on which ecosystem is in effect.  There are two script handlers, and one can pass data into the second, so you might see dialogue as a reference to the ecosystem "character 8 says array 1, line 2", or the first script handler will determine that character 8 is being interacted with, and the second handler will do something like "current object says array 1, line 2".  Additionally, your party always takes up the first 8 slots in the ecosystem (6 in the battle party + 2 in the entourage/convoy).  I've not yet worked out how you determine which character is speaking when it summons dialogue for your party.  I don't know if the game forces required members into specific positions, or if it has to search, or if they just bypass the need to worry about it somehow.  I'm pretty sure it's the forced positions, because the hero is always referenced as index 0 in the scripts I've reviewed.  If they were handed these scripts in any form that required them to decipher all that, it's a miracle we didn't get horrible Engrish with people just calling each other "mister" half the time.