________ 27-January-98 / \ ___________ .\_ _ \......./ \............. : / / \ \ \_____ __/[J3d!] : :/ / / / \ \ /¯¯¯¯\ : / / / //¯¯¯¯¯\ / // \ /¯¯¯¯¯¯¯¯\ /¯ ¯¯¯ // _ \ ___/ // /\ \ / ____ \ \__________// // // // / \ \\ \ / / : \ \\ / \_____/ \ ¯¯¯¯\ \\ \/ / : \ ¯¯¯¯\ \______/\__/ \ \__/ :...........\______/.......................\ \ [s N E S r O M t R A N S L A T I O N S] \__/ Search Relative v2.10 ===================== Introductory Information ------------------------ Every computer ever made has had some method of displaying and encoding text. A computer doesn't recognize the letter 'A' in its microprocessor; everything within the computer is dealt with using hexadecimal bytes like 00, F1, and AC. In order for the computer to be able to translate these hexadecimal numbers into letters and numbers that you and I read, a conversion table is used. There will usually be 255 possible entries within a table since bytes only go up to FF (255 in decimal numbers). But, usually only about 1/2 of them are used, since alphabets hardly take up 255 slots. For IBM compatible computers, the table standard has been known as 'ASCII'. Within the ASCII table, hexadecimal number $41 (hexadecimal numbers are usually denoted with a $ in front of them) represents the letter 'A'. From then on, $42 stands for 'B', $43 for 'C', etc... up to 'Z'. The lower case letters start at $61 ($61 for 'a'). Also, the characters '0..9' are represented by $30 to $39. The other bytes consist of less common characters such as the 1/2 symbol (½), the copyright symbol (©), and the asterisk (*). Also, some of them are used for control codes like $07, which is reserved for the system beep you hear when you turn on your computer. Not all computers use the ASCII standard. The Macintosh does not use the ASCII standard, and neither do gaming consoles. this is where consoles are such a pain in the ass - almost none of them use the ASCII standard for their lettering and to make it worse, there is no standard amongst console systems. I could be editing CastleVania today and Final Fantasy tomorrow and I'd have to find out separate tables for both of them. What does it do? ---------------- If you had to visualize what SearchR does, imagine it like this: the table is the top most row with the numbers on it. let's pretend it stetches all the way from $00 to $FF. What SearchR will do is take your string and match it to all 255 possible combinations of alphabets. in a sense, it'll slide the alphabet along the entire 255 possibilities and report the matches. [00 01 02 03 04 05 06 07 08 09 0A 0B .. F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF] [A  B  C  .. X  Y  Z]    [A  B  C  .. X  Y  Z]       [A  B  C  .. X  Y  Z]          [A  B  C  .. X  Y  Z]             [A  B  C  .. X  Y  Z]                [A  B  C  .. X  Y  Z]                   [A  B  C  .. X  Y  Z]                      [A  B  C  .. X  Y  Z]                         [A  B  C  .. X  Y  Z]                            [A  B  C  .. X  Y  Z]                               [A  B  C  .. X  Y  Z]                                  [A  B  C  .. X  Y  Z]                                     [A  B  C  .. X  Y  Z]                                        [A  B  C  .. X  Y  Z]                                           [A  B  C  .. X  Y  Z]                                              [A  B  C  .. X  Y  Z]                                                 [A  B  C  .. X  Y  Z]                                                    [A  B  C  .. X  Y  Z]                                                       [A  B  C  .. X  Y  Z] What SearchR does is it will take a word you give it that you know is going to appear somewhere in your file or ROM, and search all 255 possible combinations of that word until it finds some matches.  It searches by assuming that if the letter A is for example entry $00, then B must be entry $01, and so on. it does this all relatively with variables; first it assumes letter a is $00 and searches the file for your word using that table index, reports the matches, and then moves on to assume letter A is entry 01 and letter B is entry 02. SearchR will do this repeatedly all the way up until letter A is all the way up at the end of the table index. so simply put, you have searched the file using all possible table combinations. Sample SearchR output: File: xmen.smc (Spiderman and the X-men) String: FOLLIN 019E9C: 10 19 16 16 13 18 00 00 [........] a=?? A=0B 1=?? [FOLLIN..] 019FF0: 10 19 16 16 13 18 FE 00 [........] a=?? A=0B 1=?? [FOLLIN..] 019FFE: 10 19 16 16 13 18 FE FF [........] a=?? A=0B 1=?? [FOLLIN..] File: mana1.smc (Secret of Mana) String: Mana Sword 0908A3: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] 092EB0: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] 092EDE: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] 093391: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] The way you'll know if you've hit a correct table is if you see a matched word you were looking for, and it's followed by another word you knew you'd see right after it. For example, in the game Secret of Mana for SNES, the word 'Mana' is often followed by the word 'Sword', since it's a key item in the game. sure, you might see 'Mana' here and there if it happened to turn up somewhere in the code by coincidence, but when you see 'Mana' followed by 'Sword', the chances of coincidence get increasingly smaller. thus, you know you've found your font out of narrowing down the evidence. This is the extent of SearchR's function. once you've gotten your table, it's up to you to edit your rom based upon the table you now have. many rom editors have popped up in the past months, nakely X-Late and ROMedit. or, if you prefer straight editing, use a hexeditor. *NOTE* be careful of your capitalization, since as you can see here we searched for 'Mana'; not 'mana', and definitely not 'MaNa'. Each of these searches would have brought up different results. What does SearchR's output mean? -------------------------------- Column1       Column2            Column3     Column4       Column5 0963C0: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] 096446: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] 0967B3: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] 0994BA: A7 81 8E 81 80 AD 97 8F [........] a=81 A=9B 1=?? [Mana.Swo] - Column 1: The location of the matched phrase in the file, in hexadecimal offset numbering. - Column 2: These are the hex bytes as they appear in the file itself. - Column 3: This is what Column 2's bytes look like through the ASCII standardized table. in other words, it's what you'd see if you looked at it through a normal hexeditor's text window. - Column 4: This tells you where the ROM's table begins. here, A=9B, so B=9C, C=9D, etc. - Column 5: This is the text as it appears through searchR's table parser. you can see the following text as well as the text you entered, so you'll have a little better idea if you know if that particular string is the one you're looking for or not. *NOTE* all period marks are used to signify any byte that's not part of the normal alphabet. For instance, the space bar doesn't produce any letter or number, therefore it's denoted by a period. Other nice little things ------------------------ There's a wildcard option in searchR, used with the "?" key. for those of you who don't know what a wildcard is, read on. let's say you wanted to look up a word but you weren't sure of a letter in the middle of it, for example, a_nS (with _ representing some letter you couldn't recognize). By entering your string as a?nS, you bypass that letter altogether and tell searchR just to search for the three surrounding characters. then, once you've found what you're looking for, you can see what that character really is. There are many, many other uses for the wildcard. you can check whether a word was capitalized or not, or you can wildcard an entire word to check surrounding words for cross-checking. The Hex View Option ------------------- Ok, this is a very quick example to show you what the new hex view feature is used for (text by [J3d!]): 1) Select the file to search. Probably some console game. (Click on the 'Change File' icon or press 'f', use the file selector that appears). 2) Enter the text to search for (move the cursor over the black area next to 'SearchText:', use the keyboard to edit the textbox). 3) Click on 'SearchR' or press 'r' to search the file. 4) Check the results that appear in the list (if none appear, try a different search string). 5) Highlight one of the results using the left mouse button. 6) Click on Hex View (or press 'h'). You will now see the file displayed as both hex bytes and relative text characters (ie. the same format as most hex editors, but with relative text instead of plain ASCII). 7) While in this view, you can scroll around the file using the scroll bar and the keyboard. The following keyboard buttons are available: Up Arrow - Up 1 line Down Arrow - Down 1 line Page up - Up 25 lines Page Down - Down 25 lines Ctrl+Home - Top of file Ctrl+End - End of file The view jumps to the location of whatever result you had selected and uses the relative font table found by that result (I guess the next step is to add a full font table editor or something?). 8) When you are bored, click on Back (or press 'b'). You will return to the list of results and the main menu. For Japanese ROMS (RPG), replace the font(s) so that the name select screen appears with English chars (ie. A..Z and/or a..z). Start a new game and name your character. Save the game as soon as you can, then search the saveram (.srm) file for the character's chosen name. (As .srm files are max. 32k, this method works well) File: dragon3e.srm (Dragon Quest 3 Remix translation, saveram file) String: Jedi 000EE8: 15 29 28 2D AC 00 00 00 [.)(-....] a=25 A=0C 1=?? [Jedi....] The Gfx Viewer -------------- The gfx viewer is designed to support many of the common gfx formats used in console/arcade roms. I added it as I did not have anything to view Genesis gfx with. It supports other formats as well now, although it's better for some formats than others... You can use Up and Down to move up/down a row of gfx tiles, Page Up and Page Down to move up/down a screen of tiles and Left and Right to move up/down by Just one byte. Use the mode button to select the different gfx modes. The n-plane modes use n-bits from n-bytes to determine the pixel colour. The n-bpp modes use n consecutive bits to determine the pixel colour, the next n-bits for the next pixel etc... For each mode, you can choose to view 8x8, 8x16, 16x8 or 16x16 sized tiles. You can also switch between 'snes mode' and 'normal mode'. This is just a hack for the snes modes... Below are the best modes to use for various types of rom: GameBoy: - 2 colour (1plane) - 4 colour (2planes) GameGear: - 16 colour (4planes) Genesis: - 16 colour (4bpp) MasterSystem: - 16 colour (4planes) MSX: - 2 colour (1bpp) - 16 colour (4bpp) * MSX uses disk images, most gfx appear messed up. NeoGeo: - 16 colour (4bpp) * Only tested with Puzzle Bobble roms. NES: - 2 colour (1plane) * Not very well supported. Super NES: - 2 colour (1plane), Snes mode. - 4 colour (2planes), Snes mode. - 16 colour (4planes), Snes mode. * Not as good as NaGA. Many arcade roms can be viewed too... Oh, 8bpp mode is implemented, but 8plane mode is not... If you want to view/edit snes gfx, you are better off getting NaGA, as it supports all common snes modes and allows you to edit the tiles... Oh, NaGA is disturbingly fast too :). Credits ------- Richard Bush/[J3d!] (rbush@firenet.net) - SearchR coding Demi (demi@frognet.net) - Improved Documentation * Demi has very kindly rewritten most of the documentation above, it should make things a lot clearer for most people :). If you see a bit you don't understand, I ([J3d!]) probably added it... * The interface uses a 640x480 8bpp screen mode, Allegro is supposed to autodetect the best mode to use (VESA1/VESA2 etc..), and it works for many people. If it does not, get Scitech Display Doctor and you should be fine. If you still can't get it to work, sorry, but I don't know why. I can only test it under Win95 dosbox and the version of dos that comes with Win95 :(. What's New ---------- v2.10 - Detects and DeInterleaves .SMD format Genesis ROMs. - Gfx Viewer supporting 1,2,4 and 8 bitplanes in chunky and planar formats, plus tile sizes of 8x8, 8x16, 16x8 and 16x16. v2.08 - View the whole file using the search results. - Last file/search string saved to a settings file (SearchR2.ini). - SearchR routine warns if the search string is too general (eg. 3 or more searchable characters). - Compiled using Allegro v3.0 instead of v2.2. v2.01 (unreleased) - Documentation completely overhauled by Demi. v2.00 - Added a primitive GUI, using the Allegro Library - SearchR algorithm now makes use for the following   characters: 'A'..'Z', 'a'..'z' and '1'..'9'. Also,   you can mix them in the search strings now. - More detailed search results. v0.01 - First Release - Only good for lower or upper case search, not   both together... * Do not spread this about without permission, if you * did not get it from the address below, tell me!                                                 _/\__                                                /   \/_ ,-----------[Richard Bush [J3d!] ]--------O---(O O  \/_----. |                                           o (___/  \/_   | |  ICQ: 2365132  Email: rbush@firenet.net     (^^'\_/ \/_  | |                                             <__________> | |  WWW: http://www.geocities.com/TimesSquare/Castle/6195/  | `----------------------------------------------------------'