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.

Topics - Ragna

Pages: [1] 2
It's a question I've always made myself but could never find an answer for, since first of all I see there's no flag for that in the attack data.
But then if you look at (for example) a Guard Hound's AI it's clear that it chooses between two attack IDs (one displays the name, the other not) and then performs the same AI command: dispatch the attack by ID.

So... do you think that could be hardcoded in the attack's animation script?

My bet is that (according to the PS1 data) it's there somewhere in the attack files inside the MAGIC folder. These seem to contain some code, geometry, and textures, all mixed up.

Do you have any info on this little mystery? Did I overlook something?

I summon you, NFITC1!!! (but help from anyone else is apreciated too  :-P)

This is an idea I've had the past recent years, but lately given more thought.
As an outcome from this other topic...

When did the "Videogaming Fall" begin for Konami? It seems the same it happened to other Japanese videogame companies.
They somehow needed to expand themselves on to other markets to survive the future (now) Japanese videogaming crisis.
Reminds me too of the arcade games crisis on Japan everywhere.

Japanese game companies (most except Nintendo and 1 or 2 more) have reduced so much the quantity and quality of the content they try to sell... :-\

The talent, time, and money costs needed to make games now is so extremely huge...
I never saw it coming at the time, so nowadays it makes me both sad & angry.
Not only that, but western companies are probably beginning to face it too, and surely will 5 years from now...

Did any of you see it coming 10/15 years ago?
Do any of you feel the same way about this?

What's more, do you think it is possible a new Videogame Crash happens?

You think it is possible? Can this mix of ingredients destroy the trust and make a new bomb?
  • Rise of costs (talent, time, money).
  • Rise of price on each new generation of consoles.
  • Relaxation on the indie game barriers (specially through platforms like Steam and PSN).
  • Short yet expensive inflated price games.
  • Bugs everywhere. Everywhere.
  • Abusive DLCs, instead of reasonable expansions.
  • Smaller quantity and lower quality of games every new generation.
  • Mobile/Tablet/Smartphone games exploiting much of the above points and getting more focus from companies than dedicated gaming handhelds.
At least Nintendo still avoids most of those points. They could end up being clever once again in the end?

What's more...
...Would it be bad or good, to have a new crash, in the long term?

Now, it is confirmed, Konami is "D.E.A.D." ...
Now you can continue the drama brought up in this topic.

Will they bring up other old IPs, to then cancel such hyped up projects?
(please Konami, don't do this with Gensou Suikoden or Akumajou Dracula >:(, though Suikoden staff and Castlevania's Koji Igarashi are out... :cry:)
or... Will they create new IPs, pay the media to create hype, and then releasing some s***t and run away with the money?
or... Will they continue milking MGS, except this time without Hideo Kojima?
or... Will they try continue milking the outdated (since PS2) soccer PES game series every year?
(instead of upgrading the game/graphical engine and releasing a Master Version updateable through small/reasonable price DLC for new soccer seasons or free middle season updates)
or... Will they end up as Sega, or be bought by Square Enix Holdings?

Please, place your bets right here.

I think they will try all I've written above.

Q-Gears / How about moving to UNREAL 4.X?
« on: 2015-03-25 01:45:18 »
What the title says. Now that it is completely free for non commercial creations...
Would it be too difficult to recreate the PSOne era FF engines on it? Is it worth the trouble?

I think such an advanced yet seemingly simple to use and well supported tool would benefit the advancement in Q-Gears.

Q-Gears / FF7 asm
« on: 2013-01-02 17:07:55 »
Hi, I've seen there's some info on the asm source for FF7 in this project's
"reversing" section, but from what version of the game is it: JP, JPi, US, EU?

Solved Problems / SOLVED: FF7 bugs/glitches, fixed?
« on: 2013-01-02 16:45:25 »
Has it been ever fixed the W-Item glitch?
Has it been ever fixed the incorrectly called "Aerith Ghost" field glitch?

For the latter it would be just removing a line of the field event code, which sets the initial position of the child to 0,0,0.

I'm translating FF1 to Spanish, however I have 2 problems right now.

1. I can unpack the package files (DPK, PCK, NPK).
Thanks to some Japanese guy (see this).
However, I cannot pack them again.
The package format seems simple, though I've never
wrote such kind of program and don't know where to start...

2. Each text file uses its own table and font image.
   The font image file: SAVE_CLEAR.GIM (PSP common image format)
   Text file: SAVE_CLEAR.MSG (same format as FFs ADVANCE & CTDS)
   Font information file: SAVE_CLEAR.FIF (unknown format, always 108bytes header?)

There comes the problem. The FIF file contains information about
the font, such as width, and probably tile information and shadow
relation between each letter. The font image contains letters in
the first rows, then in the latter rows are the shadows for each.
Sorry I should provide an image of it, but I'm not on my PC. >.<


Any clue on those formats? I'd like to know if someone ever
tried something with this game. SE made things really weird
with FF1 and 2 on the PSP...

If you are willing to help me I can provide you with some file examples.
This work could help others to translate this game to other languages.

Thank you!

Troubleshooting / FF7 Spanish 1.02 EXE
« on: 2009-09-25 18:34:11 »
Where can I get this patch?
The links in "The Great FF7 FAQ" are dead.

I've searched the net, but found only the English version.
I need it to test something with the file... >.<

Two quick questions so that I can terminate my project in the PSX version  :x:

1. Which kind of compression is used for code in .MNU files?


2. Which files store sector allocation tables for game data?

I've been told that FIELD.TBL, YAMADA.BIN, and a part of KERNEL.BIN
(probably the 'Initialization' section) store that info, but there could be
more files. I need to know exactly which files, and if possible, give me
an idea on how to edit its data. I've heard that Cyberman was working
on that long long ago, but I could not find anything about it.  :cry:

Thank you!

Completely Unrelated / Ten worst captchas!! lol
« on: 2008-03-20 11:00:36 »
See this. xD

Any info on how are they displayed?

I couldn't find anything in the forum nor the wiki...

General Discussion / FFIV DS voices.
« on: 2008-02-05 17:59:36 »
I've extracted and encoded in *.WAV* all of the voice files within the FFIV DS ROM.
It has also the 'Theme of Love' song (it was with the voice files together).

Just for fun, it took me 15 minutes. xD
Now, if you are such a freak like me, download it.

P.D.: The original files were in Nintendo DS *.AHX* sound format.

Completely Unrelated / Pixel Art with HTML... O_o
« on: 2008-01-21 11:31:26 »

That is just... AWESOME!!! O_o

(Sorry for the video quality).

Answered question, please read my last post. >_<

That is what I mean.

The only thing I did was replacing the Japanese window.bin file with the European one in a Japanese FFVII.

Any info on that? .___.U

I never saw Japanese texts in window.bin @_@

Or maybe I'm completely wrong or something, I feel a little confused... xD

1- Is there any info on how the menu's in the game are structured?
I mean about the windows and all of that stuff.

2- How can I set a dialog to have a transparent window or not window at all?

3- Any news/info on color palettes for menu graphics etc.?

Thank you so much! ^_^

Well, it's me again!! xD

Someone knows exactly what files of FF7 use the XA format?

I guess that almost every file from MOVIE and SOUND folders use the XA format,
but is there any other file in FF7 wich use XA or something related to it?

Well, I made a list with all of the paths for every file of FF7 and I thought it would be useful for someone, maybe.

As I can't put more than 40000 characters in a post, here you have it.

Scripting and Reverse Engineering / PSX TIM Converter??
« on: 2007-10-10 21:46:51 »
Is there any program/tool to convert PSX TIM files into BMP and from BMP to TIM?

I've searched a lot, and didn't found nothing in the forums, and all programs/tools that
I have found by googling just don't read the PSX TIM files, don't know why (even if they are supposed to read them).

Thank you so much!!
Please, someone!! >_<U

Yeah, maybe all of you already knows that info, but, I found it useful.

So, here is it:

Code: [Select]
The PlayStation hacking doc Version 2
Written by Cless
Email: psxdoc AT tales-cless DOT org

Well, the old version of my doc is pretty much useless now. It's been needing
an update for years. I hope this one is satisfactory enough...

As before, this is mostly catered to ROM hackers who have experience. If you're
a complete newbie to the subject of game hacking, go play with some NES games or
something first.

   Table of Contents

1)  What's New
2)  To readers of the first release
3)  An introduction
4)  Getting started (file downloads)
5)  Main Method 1 - Inserting modified files back into a disc image (easy)
6)  Main Method 2 - Compiling an image from extracted files (annoying)
7)  Main Method 3 - CD-Tool (introduction, very hard)
8)  Graphics
9)  Text pointers
10) PSX Assembly language
11) Memory card tag
12) Savestate hacking is your friend

         1) What's New

V2.0 (12/5/2005) Holy crap. It's been almost 4 years. Complete rewrite.
                 Info and methods were severely out of date.

V0.7 (1/11/2001) First Release.

         2) To readers of the first release...

This section's irrelevant if you've never read the original document. Just a few
things I'd like to get off my chest regarding the previous release.

Let's face it. PSX2HD was a never-ending headache. On data I collected, it was
found to not work with NT-based Windows. On Windows 9x, it would constantly get
run-time errors. Sometimes it'd work on 9x, though.

The main use of PSX2HD was to correctly pull the mode2/XA data off the game disc
(used for non-CDDA streamed audio, often used in conjunction with and included
inside of video files).

Also, as a convenience to the user, PSX2HD would generate a "CTI" file, which
was a sheet with a directory structure for the files for the BUILDCD utility.
A huge problem I found was that PSX2HD did not use the original file/directory
order on the disc. So if you tried to make a PPF patch based on modifications
of the PSX2HD generated structure, you'd probably end up with a patch larger
than the disc image itself! The only solution was to analyze the original disc
and find the order of files, and modify the CTI file to put them in proper

Another utility that did not work under NT-based Windows was StripISO (although
I could've sworn it worked on earlier service packs of 2000). Windows XP was
out of the question. Murphy ( created a
replacement called Revenge of StripISO, which is a perfect clone of the original
program that works under 2000 and XP.

Adding a license was entirely incorrect. Anyone who followed the old version
exactly would find that the resulting ISO would not boot on a real modded
console (when I made that version, I had no access to a real modded console.
I had a plug mod which allowed me to directly select the EXE from the disc so
I was unaware of problems).

There was a lot of ranting about DAEMON-Tools. It was still in development
stage back then and has become a fantastic utility, which is still being
updated to this day.

I came up with ways around all the shortcomings but never updated this document
with them. This time, I'm doing that and adding a couple of other methods.

         3) An introduction

An old misconception of hacking CD games is that you'd need to hack an entire
multi-megabyte disc image to get anywhere. Not only would that be a pain in the
ass, but it is simply not true. The real way to do it is to modify the files on
the disc itself, and put them back in. However, it's not really so obvious how
to go about putting modified files back in.

This guide illustrates or at least introduces you to methods where you can
either replace files in the disc image, compile a working PSX disc image from
a directory of files on your hard drive, or use in-depth CD manipulating

Outside of the CD-ROM "barrier" hacking PlayStation games is pretty much the
same as any old regular ROM hacking. If you're doing a translation, you find the
font, bytes that represent text, etc, etc. Perhaps the biggest difference is
that you've got more bytes to look through. Though in some cases, the files are
appropriately named so finding some stuff might be pretty easy.

Compression is still used in some cases. Though it tends to be used for entire
files rather than just text and stuff. Well, I'm not too familiar with how
compression is used in cartridge-based ROMs so I'm just kind of assuming there.

Some games are quite evil. Valkyrie Profile's data is known to be encrypted.
Chrono Cross and Xenogears don't use a traditional CD file system for their
data, which prevents you from seeing the files on the disc entirely (aside from
the system.cnf file and the main executable). You'll certainly need to do some
disassembling to figure these ones out.

The Tales Series games like using their own file systems too, but they're not
that bad. They usually have big files that contain a whole bunch of other files.
There are other files that contain pointer tables that tell the starting offset
of each file inside of it. A little bit of programming can easily extract and
rebuild them.

         4) Getting started (file downloads)

The various methods mentioned here require different things. Here, I am listing
the common ones...

    WHAT YOU'LL NEED (minimum):

 1) A PC running Windows
 2) An optical disc drive capable of reading CD-ROM
 3) Utility to extract a disc image from a CD such as IsoBuster
 4) An emulator such as ePSXe ( You will need a BIOS ROM
    image to use it. As its legality is questionable I won't provide it directly
    Google for "scph1001.bin" or "scph7502.bin".


 1) An optical disc drive capable of burning CD-R media (required if emulators
    cannot play the game you're hacking).
 2) A mod chipped PlayStation or PlayStation 2 system. You can also use swap
    disc or plug in solutions (may not apply to PS2). There's always the fuzzy
    feeling of seeing your work running off of real hardware. Also required if
    emulators cannot play the game you're hacking.
 3) DAEMON-Tools ( Optical disc drive emulator.
    Useful for PSX emulators which do not have a built-in ISO load function.
 4) Tools ( This archive contains
    many PSX development utilities, and some should certainly be relevant to
    hacking as well. I was given this archive years ago. Some of it may not
    work and some of it may be quite out of date. There's also a ton of
    technical documents which may contain a wealth of information. Extract with
    7zip or a modern version of WinRAR.

    NOTE: The best kind of CD-R media for console use is manufactured by
    TAIYO YUDEN. The best place I know of in the US to get it is from
    Verbatim DataLifePLUS is another acceptable type of media.

         5) Main Method 1 - Inserting modified files back into a disc image

This is by far the simplest method. If you have no intention of making files
larger, adding files, or modifying any files with XA format streamed audio, this
is the definite method for you. It should work great paired with the PPF patch

    You will need the following additional utility for this:

    CDMage beta ( Can insert files back
    into your disc image.


Put the game disc into a disc drive and load up IsoBuster. In the drop down
in the upper left hand corner of the application, select the drive you put it
in. In the tree below the drop down, right-click "CD" and you'll get a menu.
Choose "Extract CD <Image>" -> "RAW (*.bin, *.iso)". Then just save wherever
you want the disc image to be.


Run the CDMage beta. Under the File menu, select the .cue file to the disc
image. If you don't have a cue or decide to just select the image, CDMage
will prompt you to select the image type. PSX discs fall under "M2/2352 track".
Select the data track and find the file you want to insert. Right click and
select "Import file". Select the file, and wait for it to insert. That's all
there is to it!

         6) Main Method 2 - Compiling an image from extracted files

This is much more annoying, long and tedious process with tons of steps. This is
essentially an updated version of the method used in the old version of this
doc. This method is not efficient for patching, but allows you to use files that
are larger than the originals (if necessary) or add new ones. If you're actually
thinking of making a patch for public distribution that requires these things, I
suggest using Main Method 3.

For those of you familiar with the old version's methodology, this mostly
replaces the PSX2HD step and adds a new step for licensing.

You will need the following additional files/utilities for this:

     1) CDRWIN ( Needed for XA file extraction.
     2) BuildCD ( With a CTI sheet,
        creates a proprietary disc image out of defined files.
     3) Revenge of StripISO and MakeCTI (both found in a zip in the forum post
        at Revenge of StripISO converts BuildCD-
        generated CD images into the standard ISO format. MakeCTI is a
        convenience tool that generates a CTI file based on folder, for use with
     4) License files (


To get started, make a directory on your hard drive which will act as a mirror
of the game disc's contents. Now, copy every non-XA file to that directory,
preserving the original directory tree. XA files tend to to have an .XA
extension, are often included in movie .STR files, or have XA somewhere in the
file name. Some isolated cases may have a naming convention that isn't so

It would seem that many optical disc drives can not read files that contain XA
data, so if you unknowingly try copying over a file containing it, you'll likely
get an error instead. And even if your drive can copy XA data like any other
file, it will NOT be doing it correctly.


Okay, this is going to be annoying to explain. PSX2HD used to do this for you,
but since that doesn't work anymore, there's only one other way that I know of
that will do it right-- RAW sector extraction using CDRWIN. This is a
painstaking process that is done manually and takes a lot more time to do.

So, you're going to need the sector range to extract this stuff. How do you get
it? This is where IsoBuster is going to come in handy. With your CD open in
IsoBuster, check out the files. There's a column that says LBA. That is the
first sector for the file. To learn what the final sector is, look for the file
with the next highest starting sector. Subtract one from that number and you get
the final sector to the file you want to extract. Example:

NAME      |  LBA
FILE1.XA  |  3423
FILE2.XA  | 35709
FILE3.DAT | 63935

FILE1.XA's first sector is 3423. FILE2.XA's first sector 35709. Subtract 1, and
FILE1.XA's final sector is 35708. Likewise, since FILE3.DAT begins at 63935,
FILE2.XA's final sector will be 63934.

So, write the file name and its sector range down. Repeat that until you cover
all XA files on the disc.

Directories on the discs tend to be orderly, so you if you sort the file view
in IsoBuster by LBA, the next file should be the true up of the one you noted.

If an XA file happens to be the last one in a directory, look around on the disc
for a file (or folder! Don't forget to check the folder LBAs too) that succeeds
it. If the XA file turns out to be the last file on the disc, go over to the
tree on the left, right click the Track, and select properties. Size (Blocks)
will give you the final sector of the disc. Use that exact number as the final
sector number.

With the filenames and sector ranges recorded, it's time to extract with CDRWIN.
Once in CDRWIN, go to the extract menu (the upper middle button). Do this:

   1) Set Extract Mode to "Select Sectors".
   2) In the Sector Selection part, set the Datatype to "Data Mode2 Mixed(2336)"
   3) Under the Start Box, input the first sector for the file, and the final
      sector in the end box.
   4) Put the name of the file in the "Image Filename" box.

Press the START button at the bottom of the menu. It'll start extracting the
sectors into a file. You can check the file with PSMPlay
(located at If it plays in that,
then the file is definitely good.

Repeat as necessary for all the XA files. Note: These files should be around 15%
larger than they appear on the disc. THIS IS NORMAL, so don't worry about it.

Now, just copy the files to the appropriate locations in your CD mirror

There, you should have a perfect mirror of the game disc on your hard drive.


Time to make a CTI file for BuildCD. But since I'm going to be a lazy ass, I'm
going to have to ask you to read the documentation to MakeCTI and make your CTI
file that way. CTIs are plain text files.

If you want to make it by hand, I've included the one I used to use for ToP PSX
in as an example. You'll just need to adapt it to your game. It'll
be pretty easy to do if you pay attention to how mine is put together.
MOVIE.BIN, XAS.BIN and XAM.BIN in ToP are XA files, so pay careful attention to
the differences in how they're represented in my CTI file to the others.

When your CTI file is done put it in the same directory as Revenge of StripISO
(Murphy's stripiso.exe) and BuildCD. Use the command line and use the following
(or make a batch file containing):

buildcd -i<filename>.img <filename>.cti

<filename> for whatever you have/want them named. Remember the -i! If BuildCD
spits out CTI file errors, fix them and try again. When it hits 100%. You will
have compiled the contents of the CTI file into a non-standard image format. Now
it's time to use Revenge of StripISO. Enter this into the command line (or
again, batch file it):

stripiso 2352 <filename>.img <filename>.iso

This will convert the BuildCD's nonstandard image into a standard 2352 byte per
sector ISO file. But, we're not done yet. The image is not licensed, so you will
have difficulty running it on modded original hardware or even some emulators.
Grab a license from the I'll use usalice.dat. Put it in the same
directory as the newly generated ISO, and run this command at the command line:

copy /b usalice.dat+<filename>.iso <newfilename>.iso

Wait a few minutes for it and when it's done, you should have a perfect working

(although it doesn't really matter, if you'd like to use the original license
data that's on the game's original disc instead of the ones included, dump an
ISO of the game, and copy the first 0x9300 (37632) bytes of it into a separate
file. That'll be the game's original license data)

When I used to use this method, I just created a batch file that did everything.
You'll still have to press escape after BuildCD finishes, but here's how it
looked for Tales of Phantasia PSX:

buildcd -itemp.img top.cti
stripiso 2352 temp.img temp.iso
del temp.img
copy /b toplice.dat+temp.bin ToPPSX.iso
del temp.bin

It saves a bit of time and deletes the temporary files when they're no longer

You may find it useful to make a cue file. Make a text file that includes the
following, minus the snip lines (and replace FILENAME.ISO with your generated
ISO's name):

------snip this line------
  TRACK 01 MODE2/2352
  INDEX 01 00:00:00
POSTGAP 00:02:00
------snip this line------


I'm (still) not too familiar in dealing with games that have CD Audio. I'm sure
it'd at least have something to do with ripping the audio tracks to .WAV and
modifying the cue sheet, but I can't detail a precise method for doing so. Maybe
in another update...

I do know of a couple games (Tobal No.1, Tales of Destiny) that use some weird
method of having a file on the data track that also represents a CD Audio track.
I have no clue how you're to get around that with this method... (the files have
a .DA extension).

         7) Main Method 3 - CD-Tool

One word: COMPLICATED! I honestly don't understand how to use this efficiently
myself. But nevertheless, I feel it should be mentioned here. It's a very
capable CD image manipulating utility controlled by scripting.

It's supposed to be capable of doing things such as inserting enlarged files,
adding files to the image, and even adding subtitles to video files (without
re-encoding and degrading the video stream!), all while retaining a modest
patch size.

It may be easier for you to understand if you're into programming, at least.

CD-Tool can be found at and has Windows,
Linux, and Mac OSX versions.

         8) Graphics

PSX has a standard, generic 2D graphic file format called "TIM". It's very
similar to a standard windows BMP file, and I've seen it used in nearly every
game I've ever looked at.

A TIM Photoshop plugin exists but might not work on some TIM files in newer
games. This plugin can be found in the PSX Tools that I put under optional, at It doesn't seem to work on some TIM
files (perhaps ones that use an updated standard?). There might be an updated
plugin somewhere that works with them, but I don't know where it might be.

Klarth wrote a utility that extracts TIMs from files and reinserts them. That
could make your life a lot easier if you deal with a game that has lots of TIM
files archived into one big file. You can get it at

If you deal with a TIM file that can't be opened via the Photoshop plugin, you
might have better luck with a traditional tile editor such as Tile Molester

Klarth also wrote a document on the PSX TIM format, though it may be out of
date. Grab it at his site at

         9) Text pointers

The ones I've encountered haven't been all that much different from typical ROM
hacking. A helpful difference is that you have no bank or lo/hi ROM type crap to
deal with.

So far I've only encountered 16-bit linear pointers. The pointer tables that
I've encountered tend to be right above the text. Some pointer values are
relative to the file offset, some are not. Others I've encountered are simply
relative to where the block of text begins-- the first byte the text block would
simply have a pointer value of 00 00.  (ToP sometimes likes to waste a byte by
starting the text at 01 00, for some unknown reason)

The dialogue pointers in Tales of Phantasia PSX are embedded within the event
script (evil as hell!) and not within a traditional pointer table. But the
pointer values are also calculated relative to the dialogue block. First byte in
the dialogue block would have a pointer value of 00 00.

In the case of ToP PSX, I find pointers relative to the start of the text data
far more commonly than pointers relative to the file offset. It could be quite
different with other games, but I haven't messed with any PSX games as much as

At any rate, the PSX text pointers I've encountered are nothing terribly
advanced or strange. Good 'ol Atlas
( will take care of
them with ease.

         10) PSX Assembly language

No, you're not going to find a complete tutorial or anything here. The PSX runs
on a RISC processor known as the MIPS R3000a. It's almost identical to the
processor in the Nintendo 64 except it's clocked slower and perhaps has fewer
instructions and maybe registers (not concrete info). Any disassembler meant
specifically for the N64 should be 100% backward compatible with the PSX. The
N64 uses a MIPS R4000 processor.

The disassembler I like to use for PSX is LemAsm
( To use, File>Open ROM image, set to all files
and select the PSX file you want to disassemble. Under View select "MIPS
disassembly". Then under Tools, do both Byteswap and Wordswap once each. To show
the proper register names, go under View again and select "Show reg names".

Well, there's also IDA Pro if you can get your hands on it with the PSX plugin.
It's a lot more complicated than LemAsm but surely has a lot more functionality.
But it also commands an insane price tag.

You can find a MIPS R2000/R3000 instruction set here:

There is also this old document with a LOT of technical info:

Klarth wrote a modified version of the PCSX emulator with a code tracing
function. Grab PCSXTrace at
My P4/Windows XP box doesn't seem to like it when you run unfiltered traces.
Instead of tracing PCSXTrace locks up. Filtered traces work for me, but for some
reason there seems to be a bug where the instruction after a JAL (or a JR, can't
remember) doesn't get logged.

I hear there's a debugger out there, but I'm unsure where it is...

And finally, Skeud wrote a little document on some PSX ASM stuff. Some of the
methodology might require some stuff out of your reach but you may still find
value in it.


Okay, I am by no means an ASM guru, but the PSX is a pixel-based console. Most
of the consoles that precede it are tile-based. You can do a lot of little cool
things with just a tiny pinch of easy ASM knowledge and a tracer. I was able to
make a ton of cosmetic hacks in ToP PSX's menus with this and they came out
great. I moved things around to make room for text, and was even able to add 7
letter naming to the game (which was made easy by the fact that the RAM already
had room for a 7th letter). You can also do things such as change the fixed
width of a font. Check out the "hacking save states" section of this document
for some more info on how to hack like this.

         11) Memory card tag

When you check out the memory card manager, you'll see text data relating to the
game save you've highlighted at the bottom of the screen.

This text is stored in Japanese Shift-JIS, and you should be able to find it in
the main EXE. Quite often, variables are also stored in it. If you translate
a game title from Japanese (Without abbreviating or turning the title into an
acronym), it may spill over into the variables. The only way to fix it is to
adjust their positions via ASM hacking.

         12) Savestate hacking is your friend

Due to the fact that the PSX uses CD-ROMs, things work a little differently. RAM
is not only used for storing variables. It's also used to store entire data
files from the disc. Generally, the main EXE is always loaded, and what other
files are loaded in memory can vary depend on the position of the game.

If you want to play with something that occurs at a certain point in a game, but
don't want to go through the hassle of having to insert a modified file back
into an ISO, or rebuild the ISO every time, you can hack the contents of RAM via
a savestate. It's as quick and simple as hacking any old console ROM. It's great
for testing things quickly. When everything's good, you can just copy and paste
the data back into the original file to "hardcode" it into the game.

ePSXe and PCSX savestates are compressed with Gzip. Rename them with .gz added
and extract them with winzip, winrar, or just about any other decompression
utility. ePSXe can load decompressed savestates as long as long as
the savestates have the same filename as the original compressed save state
(minus the .gz extension, of course). I don't know if PCSX supports loading of
decompressed savestates.

RAM begins in an (uncompressed) ePSXe savestate at offset 1BA.

As an added tip, getting to know what files are generally in RAM all the time
can be very valuable knowledge. For example, in ToP PSX, the dialogue font is
ALWAYS in RAM, at the same offset. Considering it's a Japanese font, it's a 50KB
file with all the kanji. But since the kanji is useless for English, you can use
all that space for just about anything you might need extra RAM space for (such
as code). Getting rid of all the kanji freed up over 40KB! We now use it for ASM
hacks, DTE table, width table data for variable width fonts, and just about
everything else we add to the game.


So... announced in the Assembly section, I talked about easy tricks to do
cosmetic hacking. Testing and such goes hand in hand with savestate hacking so I
thought that would be best explained here.

You will need the following to do this:

    1) PCSXTrace and PSXAddress (both located at
    2) ePSXe (
    3) Hex Workshop ( My favorite general purpose hex
       editor, by far.
    4) UltraEdit32 ( Simply the best simple text
       editor out there. Notepad doesn't handle large files very well.

For this method to work, you will absolutely NEED to be capable of taking pixel-
accurate screenshots. So turn off all your fancy filtering and whatever. All
the NTSC games I've seen use either 256x240, 320x240, or 640x480. Sometimes the
resolution can vary in different parts of a game. 320x240 is the most common
res I've seen used in general.

Alright. So let's say we want to move something such as text over 10 pixels to
the right. If we took a screenshot as the text is in its original position, we
find that it is 160 pixels from the far left of the screen.

Let's make an ePSXe savestate on the screen where this text is, then decompress
it as stated earlier.

Now, let's run PCSXTrace. Configure it to do filtered traces. Now run the game.
Get to a screen just before when this text we want to move is to appear on the
screen. Hit F11 to start tracing, and quickly do whatever needs to be done to
get to the screen that has this text. When you get to that screen, quickly hit
F11 again to stop tracing and exit the emulator. There should now be a text file
in the PCSXTrace directory called trace.log, it should be at least around 400KB
or far more. Open it in UltraEdit.

If you're unfamiliar with PSX ASM, this is simply going to look like a huge mess
of nonsense. To keep things simple, we're just going to search the file for the
position of the text we want to move over. Remember? The text is 160 pixels from
the far left, so the value for the position of the text will be the same! Search
the text file for "00A0 (160)" (minus quotes). You might find a few matches.

Here's where PSXAddress becomes useful. The 80XXXXXX number on the left is the
memory address where the instruction was read. Put this number in PSXAddress'
RAM column, and it will give you the offset of the instruction in the ePSXe

Open the savestate in Hex Workshop and go to the offset. If you did everything
correctly the byte at the address should be A0 00. Change it to AA 00. Save the
savestate, run the emulator, and load the savestate. If the text moves over 10
pixels, you found it! If it doesn't, try the other results in the trace log.

If none of the results work, there are several possibilities:

1) The positions are not controlled via ASM, but possibly data.
2) The co-ordinate is wrong. Sometimes there may be transparent pixels to the
   left of the text or object. These count! Try doing searches in the trace
   log by subtracting from the theoretic position.
3) There may be an odd algorithm that determines the position (beyond the reach
   of this guide).
4) PCSXTrace has a bug where where the instruction after a JAL or JR doesn't get
   logged. I have seen instances where the co-ordinate instruction I'm looking
   for gets eaten by this!

Things that may help (slightly more advanced). Positions are usually controlled
with an ADDIU instruction. In my experience, at least with ToP, co-ordinates use
the registers a0, a1, a2, and maybe a3. Typically, an instruction that controls
the vertical position will also be very very close (if it's not right before or
after it)

Find out what file the code is stored in on the disc and make the necessary
change to hard code it. To make it easier to find, use hex workshop to copy a
large string of hex code around the instruction you're changing, and then do a
hex search on the CD files to find it. If you can't find it for some reason, it
may be compressed or (even worse) encrypted.

Well, I hope some of this made sense at least. The same type of thinking could
apply to anything. 16 pixel fixed width font? Start a trace before the font
starts drawing. Search the trace log for "0010 (16)", and try changing the
results to 08 00 and you could change the font to 8x16 as simply as that. To
get 7 letter naming in ToP, all I did was change a bunch of 06 values to 07 (and
in one case, a 05 to a 06).

Once you get the procedure down, it's all down hill from there. As I've shown,
you can do a lot of nifty things with this.


Well, I guess that just about wraps it up.

If you think something isn't explained well and you have relatively good
comprehension skills, let me know. I'm not always confident in explaining things
clearly, and my own comprehension skills aren't that great. Send mail to
psxdoc AT tales-cless DOT org (format into a real email).

Scripting and Reverse Engineering / FF7 PSX Extractor??
« on: 2007-10-03 16:57:45 »
Is there any program for extracting/replacing files in the PSX version of FF7?

I mean something like the Lasyan tools (very good ones, really).

Oh, and, someone have a version of Hack7 (program made by Lasyan) with the event editor feature?

The last versions stopped on having that feature, don't know why. @_@

Thank you in advance, I'm really interested in tweak some things in the PSX version
(though, I know I can't do much in that version u.uU ..for now.. hee hee!! ..ahem! xDDD)


Yeah, I don't even know where to post this, but well, nevermind.

This is the "trouble":
I open a folder containing the 1280*1024 & 1280*960 patches,
then my 'Norton Internet Security Center 2006' just removes the second patch cause it "thinks" its dangerous.

So, my questions are:
WTF is going on with the patch/with Norton???!!!
And, why it "thinks" the 1280*960 patch its dangerous??!!
And even, why 1280*960 yes but the other no??!!

I'm using the 1280*1024, but I just need to know what is going on with the things!! Grrr!!

Thank you ^^U

Yey, Im from Spain and Im currently working in a PC-FF7-related project. Im doing a forums for that.
I need all possible help from Spanish/"ppl who talk Spanish" programmers so please if you guys are Spanish
or you just know Spanish please, please contact me, okay? (See my MSN account..)

Thank you for reading and join me in my project please.

P.D.: I will tell you about my project by MSN, or if you want I can write it here, but in Spanish,
cause there are a lot of things to say and I dont know very well how to say it in English^^U so sorry.

Archive / kernel.bin decompile?
« on: 2007-04-13 16:10:46 »
Hey, I wonder how can I decompile the kernel.bin file,
I have Gzip, but I dont know how to decompile the kernel.bin^^U

Can you help me?
Thank you in advance^^

Archive / Editing scenes.bin
« on: 2007-04-12 16:26:13 »
Well, Im doing it well with Scenester but I have two questions..
How can I include more monsters in a formation in the scene?
How can I edit the effects that a monster attack have? (like status changes and that stuff)

I hope you can help me^^Thank you for reading!

PD: If i have to do that things with another program not scenester tell it to me please^^U

Troubleshooting / FF7 Main Menu Glitch?
« on: 2007-04-11 17:04:33 »
Well, I was retranslating the Main Menu and I found in the Status submenu somehting like a glitch, I mean, in the Status submenu, you press Accept button and it display a new status screen, taht is for elemental (fire, ice, etc) parameters of the character, and if you press Accept button again you see the status screen, then, i will explain, In Elemental Screen you can see on the top the word: Elemental List, or something like that (i dont really know how is it in the english version^^U) and in status screen you can see that the last status is Elemental List. Then if you try to translate it it changes the two words in the two screens, and I was wondering if Elemental is a battle status or soemthing, I gess my explainment was bad..¬¬ but well, I hope you undestand me^^U

Sorry if i explained bad. But, can someone explain to me how work that thing? I think is a glitch or something..
Thank you for reading even if I didnt explain it too well^^U

Pages: [1] 2