 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by Cellar Dweller |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
| User | Post | ||
Cellar Dweller Flurry !!! Level: 27  Posts: 223/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by Elric http://board.acmlm.org/thread.php?id=4250 |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 224/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| All of the compressed files in SM64 have the backreference list start on a dword boundary. The decompressor in the game may depend on that condition. If so, could that account for the reinsertation fKitten Yiffers? Could there be related data immedetly following the compresssed file? HyperHacker: Does your compressor pad the data map to a multiple of 4 bytes so that the backreferences start on a dword boundary? BGNG: I'd make that "Result = X * 255 / 31" so that integer only calculations do not round any value of X other than 31 down to 0. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 225/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by BMF54123 I'd say the latter. When I was able to mess up just a few polygons in the Bob-Omb battlefield by corruption, Mario moved as if nothing had changed. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 226/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Are you ready for another breakthrough?  BEHOLD!  I looks like my hunch about alignment is correct. I patched CaH4e3's compressor to pad the bit map to a multiple of four bytes. Add the following between lines 144 and 145 of mio0enc.c: /* Cellar Dewller: pad the bit map to a multiple of four bytes */ |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 227/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| OK Just what I was working on while you posted:  I don't have a DS or any DS ROMs. Sorry. (edited by Cellar Dweller on 06-19-05 10:31 AM) |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 228/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| After reading what VL-Tone posted about the geometry data, I did some reading of some documents and header files relating to the N64. The format of the data is the standard format of a N64 drawing command list as generated by Ultralib and used by the RSP and RDP. 0x03 - loads various stuff into the RSP. The 0x86 and 0x88 bytes indicate lighting data. 0x04 - loads vertex data into the RSP 0xBF - draw a triangle 0xFD and 0xF3 are texture related I would post links to the files that I refered to, but they fall into the same catagory as warez and ROMs.  I can post more information about the format of the data soon. HH: The texture is 32x32. I just filled most of it with zeros, which showed up as transparent areas. BTW, I did not erase the very top and bottom of the texture, so parts of the old fence texture are still visible. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 229/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| The format of these commands may vary from game to game based on the low level program loaded into the RSP(Reality Signal Processor, which performs the transform and lighting operations). Vertex cache load format: 04 B0 [00 C0] [07 00 BD 50] 0 : load vertex command 1 : number of vertices minus one in the high nibble and where in the vertex cache to load in the low nibble (eg 0xb+1= 0xc=12 vertices loaded into index 0) 2 - 3 : number of bytes of vertex data to load( 16(dec) for each vertex) (redundant?) 4 - 7 : memory address to load from It seems that the RSP has an internal memory buffer for vertex operations and this command loads vertex data into it. Vertex format: (08 EB,FE 5A,08 18) [00 00] (00 06,07 20) <00 7F 00> FF 0 - 5 : location (x,y,z) 6 - 7 : nothing 8 - B : texture coord (s,t) fixed point format C - E : color or normal vector for shading -- looks like a normal vector pointing in the positive y direction in this example F : alpha Triangle format: BF 00 00 00 00 [28 32 3C] 0 : triangle command 1 - 3 : mean nothing and are likely ignored 4 : vertex to get normal or color from for flat shading, if flat shading is used; seems to always be 0. 5 - 7 : vertex number times 10(dec) (as stated) There is more to decode from the docs and headers, but I need sleep.... (edited by Cellar Dweller on 06-21-05 11:26 AM) |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 230/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| The pointers to vertices/textures are 32 bits according to the files I have. I have also found out that the FD commands point to textures in thier last 32 bits. Looking at the decoded bob-omb battlefield file, I tried to find the texture images that the FD command pointed to. I found that if the high byte of the 32 bit pointer was 07, like the vertex pointers, a texture could be found in the same file at the location pointed to by the lower 24 bits of the pointer. I think that the high byte if the pointer indicates which of the loaded files contains the texture/vertices and the game code repoints them to the decoded location in RAM before sending the commands to the RCP. EDIT: FD 10 00 00 09 00 48 00 0 : FD = command to set the location and format of a texture image 1 : format/pixel size fffpp000 f = format RGBA = 000 (there are other options) p = storage size of 1 texel 16 bits = 10 (other options too) 0 = unused 2 - 3 : "width" minus one in the lower 12 bits-- I am not sure why this is zero. 4 - 7 : pointer E6 00 00 00 00 00 00 00 This is just makes the RDP wait until it is not using any textures, or something like that, in preparation for loading the texture image. It has no parameters. F3 (00 0,0 00) 07 (7F F)(1 00) 0 : F3 = command to load the texture into the texture memory along with more settings 1 - 3 : the s, t coordinates of the upper left corner of the texture tile in fixed point format 4 : the tile number on the lower 3 bits 5 - 7 : the s coordinate of the lower right corner of the texture tile and some sort of fixed point slope These are low level drawing commands that are the product of a higher level API. In other words, the drawing was done with the Ultralib functions/macros and the resulting low level drawing list was compressed. (edited by Cellar Dweller on 06-24-05 10:17 AM) |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 231/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| Have you tried using the chunk of free space after text data? "FF FF FF FE"= free space Use the HiROM version of the pointer to avoid trouble. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 232/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| Regarding the gaps in the line, you may want to check out the SetBkMode function. You don't need an invisible brush to make the gaps in the line invisible, but if you need one for some other use, use GetStockObject. | |||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 233/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| Has anyone noticed that thr act number acts like a bit field? (e.g. 0x03 -> acts 1 and 2) | |||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 234/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| There is the possiblity of adding debuging features to existing emulators. 1964 is GPLd, so the source code is available for the most recent version. Also, an older version of Project 64 is avilable in source code form. The biggest problem, at least with 1964, is that a somewhat recent version if MSVC is needed to compile it. VC 4.0, Dev-C++, and the free command line compiler toolkit that MS released can't use the project file. | |||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 235/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| Well, I just pasted a second copy of the SM64 ROM onto the end of itself, and added 0x800000 to the begin and end pointers of the Bob-Omb battlefield file. The level loaded as normal. I then zeroed out the second copy at the end, pasted the battfied file at 0x800000, and adjusted the pointers. The level loaded as normal. Finaly, I inverted a section of the file I had placed at 0x800000, and then it did not work. Testing was done with Project 64 and 1964, so SM64 can be expanded, at least for playing on emulators. I have found and decompiled two functions that call the decompressor into C like pseudocode. They both seem to accept three parameters, a start, an end, and one of unknown purpose. See http://s91407720.onlinehome.us/acmlmboard_files/romhacking/sm64/uncompress_calling_functions.txt for a messy, but somewhat useful, decompiling job. One of them is hardwired to decompress to 0x801C1000 in RAM. I'm also working on a simple command line disassembler that puts out code that is easer to read than output from 64DISASM, and can be saved to a text file with redirection. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 236/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by The Crimson Chin Games for the N64 and newer systems tend to be written in high level languages like C/C++. The extra usless bits of code may be caused by a compiler that lacks the ability to optimize the code fully, or some optimizations were turned off. The benefit of compiler generated code to ROM hacking is that the code will tend to be grouped together in functions with well defined start and end points. Also SGI/Nintendo created a high level library, called "Ultralib", that N64 games all use almost exclusively vs direct hardware access. The functions in Ultralib can be scanned for and calls to them can thus be found. USF rippers have been taking full advantage of this to peform thier task. I think that those other function calls are more likely to be for memory management, or some other general task. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 237/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| The location of the functions differ from game to game, so they must be scanned for. hcs and someone42 have created files to use with IDA Pro to find them in a savestate. I don't have IDA Pro and I'd rather not try to use a copy from a warez site. hcs posted a utility on the USF site that can read a certain format of object file that is used in N64 development that Ultralib can be found in and produce a searchable pattern. As for information on parameters, I have such information. I think that I have the, uh, same thing that Interdpth mentioned earler in this thread. There is also lots of useful stuff in a repository of open source N64 stuff that hcs put up on SourceForge.net. Like (part of) a program to decode N64 drawing lists. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 238/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| It depends on the settings of the web browser in use. Many browsers have an option to prevent images from servers other than the server the page is from from setting cookies. Cookie access likely follows the same rule. | |||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 239/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by MooglyGuy I know about the delay slot, and I'm sure that HyperHacker(currently "The Crimson Chin") does too. If you had looked at the decompiled functions(which I admit contain errors) that I linked to you would have seen that I properly identified the loads following the JAL instructions as loading one of the arguments to the functions. What seems to be unoptimized are the branches with an offset of one instruction that are always taken. If they serve any useful function, we'd like to know what it is. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 240/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| I tried the patch. Mario's head turns into a large textured polygon inside the castle and all of the levels crashed PJ64. One level locked up Windows so tight that I had to press reset. There is a command for setting/changing the transformation matrix. It works like the OpenGL functions glPushMatrix, glLoadMatrix, glMultMatrix, and glMatrixMode rolled into one. 01 GG 00 40 PP PP PP PP The matrix pointed to by the matrix command is 64 bytes long. The matrix is composed of 16 32-bit signed fixed point scalars. All of the whole parts of the scalars are in the first half of the matrix data, and all of the fractional parts are in the second half. Within each half, the data is in the expected order. There is also a command to pop matrices. bd 00 00 00 00 00 00 GG Don't bother pushing/popping the projection matrix. Its stack is only 1 level. To enlarge peach's head, you would not need to change it anyway. I also found out how the addresses work. The RSP has a lookup table of 16 base pointers into main memory. The first byte of a pointer in a command is used as an index into the table, and the last 24 bits of the pointer in the command are added to the base pointer from the table to obtain the location of the resource pointed to in the command. There is a command to set the base pointers (among other things). bc SS SS 06 BB BB BB BB You probably will not see this command in the ROM, as I suspect that it is generated at runtime. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 241/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| The poll options are a little limiting. If the pizza is precut into slices, like takeout, I will eat the slices from tip to crust. If the pizza is uncut, as is the case when it is fresh from the oven, I don't even allow it to cool before I slide the whole pie off the pan onto my plate. To eat the pizza, I slide it to extend it past the edge of the plate, and eat from the extended portion. I do that until a portion small enough to hold remains. |
|||
|
Cellar Dweller Flurry !!! Level: 27 Posts: 242/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
| As I stated earlier in the thread, I have been refering to other files, and they fall into the same catagory as warez and ROMs. Some of the files are documents, which contain overall functional descriptions, and some are C header files, one which contans C preprocessor macros that create the commands by shifting the parameters onto the right places. I use the docs for general information, and I trace through the macros to get the exact bit layout. Finally, I write a description of the command that is intended for a different group. Many of the commands at the API level are actually wrappers for other commands at the binary level. I obtained the information from a site run by a USF ripper shortly after this thread was started. After VL-Tone posted his information, I had correctly figured that the docs that I had recently obtaned would provide more information on the format. Also, the N64 doesn't use OpenGL for an API, but an API that is tied to the hardware. Now, I really should work on a function scanner..... |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
| Acmlm's Board - I2 Archive - - Posts by Cellar Dweller |
As for that function that decompresses to a fixed address, notice that it does a few other things after decompression... probably there to handle one specific thing, like textures or sounds or something.