Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Rom Hacking: hukka | 2 guests
Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff | |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
stag019

Snifit
Level: 23

Posts: 230/299
EXP: 62259
For next: 5464

Since: 06-10-05
From: C:\Documents and Settings\stag019\Desktop

Since last post: 9 days
Last activity: 7 hours
Posted on 08-02-05 09:22 PM Link | Quote
Well, it should appear in the drop down menu. Odd. Read the help file.
tachyon

Octorok
Level: 7

Posts: 8/23
EXP: 1089
For next: 359

Since: 07-28-05

Since last post: 5 days
Last activity: 10 hours
Posted on 08-02-05 09:49 PM Link | Quote
it talks like I can just start it up and play a game (which I can't). what's a GUI file? it mentions them.
stag019

Snifit
Level: 23

Posts: 237/299
EXP: 62259
For next: 5464

Since: 06-10-05
From: C:\Documents and Settings\stag019\Desktop

Since last post: 9 days
Last activity: 7 hours
Posted on 08-05-05 06:42 AM Link | Quote
Tachyon, I'll PM you eventually.

Sukasa, if you still want to fiddle around with stuff, here's a GS code.
D033AFA1 0020
803474A4 0001
Pressing L will make the first Bob-omb dissapear, so fiddle with 803474A4.

VL-Tone, can you rip the texture on the fountain in the back of the castle?

And where has everyone gone? This place hasn't had a post since 08-02-05 12:49 PM!!!!


(edited by stag019 on 08-05-05 12:56 AM)
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 150/200
EXP: 64158
For next: 3565

Since: 06-06-04
From: In the Moon!

Since last post: 5 days
Last activity: 2 hours
Posted on 08-05-05 12:09 PM Link | Quote


Please don't tell me you really think you that texture reads "L is real 2041" ...

In my latest experiments confirm that if you change only the level geometry (in a savestate), Mario won't care and instead the original ground collision (This was noted in the first page of this thread). I'm pretty sure I found where the ground collision data is, and hopefully the way it's stored, it would be relatively easy to make an editor that can move any vertex in the level and also change the polygon collision data at the same time. It's located after the geometry data for each level in the MIO0 file. It's loaded with command 2E in the object layout data (the one that includes command 24). For example the castle collision data is loaded with this command 2E 08 00 00 07 00 F3 A0. The address inside the MIO0 file in this case is 00F3A0. It's a plain list of vertex, and all can be found in the geometry data before. At 00F3A2 you can find the number of vertex in the list as a 16-bit integer. Each vertex entry is 6 bytes long, 2 bytes per axis, 16-bits signed integers. After that is a list of numbers that refer to the vertex list before.

The problem is that I couldn't confirm this one, as changing the presumed collision data in a savestate or in RAM didn't have any effect when resuming the game.

I suspect that this data is used only once when the level is loading, and results from calculations on the collision data is stored elsewhere in RAM. Unless I can stop the emu exactly after it decompressed the MIO0 file in RAM and before it reads and convert the collision data, it's impossible to edit the collision data in RAM and see the results. This problem only happens when I try to test it in RAM, and modifying the MIO0 file and reinserting it in the game would likely work.

Anyway it shouldn't matter that much once we can edit MIO0 files without worrying about recompressed size.

I don't have much time these days to hack, but overall things look good for the future. (Full Mario level editor by 2007? )

Oh and by the way, I probably said it many times, but if anyone wants to program and release a competing editor, I'm all for it

I have a simple question for those in the know, can you simply extend the Mario 64 ROM much like you can do with SNES carts like StarFox, by appending 32k or maybe 256k(?) blocks of stuff like "FF" at the end of the ROM file? Or do you have to modify the header and other things?
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.
Posted on 08-05-05 04:27 PM Link | Quote
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.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 6306/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 08-05-05 09:35 PM Link | Quote
033948 10 00 00 01 beq r0, r0, 1 no...
03394c 00 00 00 00 nop ...thing ???
The game seems to do this a lot. Anyone have any idea why? 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.
Sukasa

Boomboom
Error 349857348734534: The system experienced an error.
Level: 57

Posts: 1573/1981
EXP: 1446921
For next: 39007

Since: 02-06-05
From: *Shrug*

Since last post: 6 days
Last activity: 1 day
Posted on 08-06-05 03:00 AM Link | Quote
I'll check that GS code. Perhaps it changes a sprite table? That would be interesting...
stag019

Snifit
Level: 23

Posts: 242/299
EXP: 62259
For next: 5464

Since: 06-10-05
From: C:\Documents and Settings\stag019\Desktop

Since last post: 9 days
Last activity: 7 hours
Posted on 08-06-05 03:23 AM Link | Quote
Thanks, Sukasa.
VL-Tone, I only kinda think it says L is real 2041 or 2401 or whatever. I'm not obbsesed with it out think it has to do with Luigi! And you better thank me for telling you to edit the savestate.
Kario

In Possession of a Stolen Shovel

Level: 65

Posts: 1975/2082
EXP: 2321379
For next: 14249

Since: 03-15-04
From: Texas... Yeehaw!

Since last post: 2 days
Last activity: 17 hours
Posted on 08-06-05 05:31 AM Link | Quote
Someone should edit the gfx for that sign to make it clearly say "This says nothing"
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 151/200
EXP: 64158
For next: 3565

Since: 06-06-04
From: In the Moon!

Since last post: 5 days
Last activity: 2 hours
Posted on 08-06-05 12:41 PM Link | Quote
Thanks Cellar Dweller, it's good to know that you can expand the ROM just like that! I guess I'll get back at coding my own MIO0 compressor. It's not hard, but I'm trying to optimize the speed and output and I don't have too many cycles to spare

stag019, sorry I recently read a thread about "L is Real 2041" speculation on another site and I guess that's why I was a little worked up about it.

As for editing the savestate, it's not like I didn't thought about doing it before, but the last time I checked I wasn't able to find anything. This was a long time ago and I kind of forgot about the possibility of doing it, I had other things to keep me busy hacking SM64 without having to mess up with RAM. When we chatted about replacing the decompressed Mario head MIO0 file in RAM with a Luigi-like head, it got me thinking about editing the savestate again, and I realized that the problem I had last time was because the savestates are compressed (in gzip) for my emu. After decompressing it, I found the Mario head data and replaced it with the Luigi head data I created.

Kario LOL that's really funny (well in my point of view at least)

In the same line of thought we could modify the texture so it could clearly read: "Nothing to read here", "Unreadable", "Don't look here", "Japanese characters" or "Each letter is 2 pixel wide"

Or maybe we could put the picture of a naked chick and get quoted on CNN

KTurbo

Paragoomba
Level: 15

Posts: 57/78
EXP: 15418
For next: 966

Since: 06-19-04
From: Swe

Since last post: 8 days
Last activity: 30 min.
Posted on 08-06-05 01:11 PM Link | Quote
Originally posted by VL-Tone


Or maybe we could put the picture of a naked chick and get quoted on CNN




Yep, go with that. :O
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.
Posted on 08-06-05 01:42 PM Link | Quote
Originally posted by The Crimson Chin
033948 10 00 00 01 beq r0, r0, 1 no...
03394c 00 00 00 00 nop ...thing ???
The game seems to do this a lot. Anyone have any idea why? 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.


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.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 6334/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 08-06-05 03:24 PM Link | Quote
I know C/C++ isn't totally efficient, but it really seems odd to just stick random instructions in that don't do anything.

I bet a list of those functions' addresses and parameters could be really useful.
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.
Posted on 08-06-05 04:42 PM Link | Quote
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.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 6349/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 08-07-05 08:23 AM Link | Quote
Well if we at least knew the first 16 bytes or so of these functions, we could write a program to find them.
eNathan

Goomba
Level: 8

Posts: 2/33
EXP: 1773
For next: 414

Since: 08-07-05
From: United States, but does it matter?

Since last post: 1 day
Last activity: 8 days
Posted on 08-07-05 08:12 PM Link | Quote
Im quite impressed on the gfx hacking that has been done in this thread. I have a question though -- I have been messing around with some mem addresses in SM64, and they seem to be dynamic. I am using Project 64 as my emulator (not sure of a differnt emulator would make the addresses static). Would anyone happen to know the pointer address to mario.

THX (=_=)
stag019

Snifit
Level: 23

Posts: 251/299
EXP: 62259
For next: 5464

Since: 06-10-05
From: C:\Documents and Settings\stag019\Desktop

Since last post: 9 days
Last activity: 7 hours
Posted on 08-08-05 12:14 AM Link | Quote
How did you use Project 64 to change the RAM? I had to download Nemu64.
Originally posted by eNathan
Would anyone happen to know the pointer address to mario.
Im not exactly sure what you mean by this, could you explain a bit more?
Originally posted by eNathan
...they seem to be dynamic...
I'm not sure what you mean by this either.Could you explain this too?
eNathan

Goomba
Level: 8

Posts: 3/33
EXP: 1773
For next: 414

Since: 08-07-05
From: United States, but does it matter?

Since last post: 1 day
Last activity: 8 days
Posted on 08-08-05 08:50 AM Link | Quote
Originally posted by stag019
How did you use Project 64 to change the RAM? I had to download Nemu64.
Originally posted by eNathan
Would anyone happen to know the pointer address to mario.
Im not exactly sure what you mean by this, could you explain a bit more?
Originally posted by eNathan
...they seem to be dynamic...
I'm not sure what you mean by this either.Could you explain this too?


Well, in response to your first response to my coment ...lol
I did not use Project 64 to actaully change the data in the RAM. I generally either use a program called Artmoney or TSearch. These programs will "open" a process (in this case, Project 64 emulating Mario 64) and will search its memory for certian data. If your a programmer, you may be farmilar with the API's WriteProcessMemory and ReadProcessMemory which are used to read/write data to/from another program.

A pointer address is basicly like this. Lets say marios coins are located at 3B0794DA, his health at 3B0794DD, and his number of lives at 3B0794DE. All those addresses are fairly close to eachother, as they begin with 3B0794D. All of mario's data is somewhere around these adresses also. The 'pointer' to mario is a static adresses which identifies the begining of mario's data AFAK.

Dynamic Memory is basicly memory that changes everytime you restart the program. This can be a bitch for memory hacking newbs like me to get around. However, static addresses are always the same. For example, if game uses DMA (Dynamic Memory Allocation) it will locate memory for its variables on a first come first serve kind of basis, so one time mario's health could be 3B0794DD and another time it could be 0CD995DA.

Hope this helps
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 152/200
EXP: 64158
For next: 3565

Since: 06-06-04
From: In the Moon!

Since last post: 5 days
Last activity: 2 hours
Posted on 08-08-05 12:56 PM Link | Quote
Originally posted by eNathan
Originally posted by stag019
How did you use Project 64 to change the RAM? I had to download Nemu64.
Originally posted by eNathan
Would anyone happen to know the pointer address to mario.
Im not exactly sure what you mean by this, could you explain a bit more?
Originally posted by eNathan
...they seem to be dynamic...
I'm not sure what you mean by this either.Could you explain this too?


Well, in response to your first response to my coment ...lol
I did not use Project 64 to actaully change the data in the RAM. I generally either use a program called Artmoney or TSearch. These programs will "open" a process (in this case, Project 64 emulating Mario 64) and will search its memory for certian data. If your a programmer, you may be farmilar with the API's WriteProcessMemory and ReadProcessMemory which are used to read/write data to/from another program.

A pointer address is basicly like this. Lets say marios coins are located at 3B0794DA, his health at 3B0794DD, and his number of lives at 3B0794DE. All those addresses are fairly close to eachother, as they begin with 3B0794D. All of mario's data is somewhere around these adresses also. The 'pointer' to mario is a static adresses which identifies the begining of mario's data AFAK.

Dynamic Memory is basicly memory that changes everytime you restart the program. This can be a bitch for memory hacking newbs like me to get around. However, static addresses are always the same. For example, if game uses DMA (Dynamic Memory Allocation) it will locate memory for its variables on a first come first serve kind of basis, so one time mario's health could be 3B0794DD and another time it could be 0CD995DA.

Hope this helps


Do you know if the data you are looking with Artmoney or TSearch is an exact mirror of the n64 RAM? Maybe it's Project64 that moves things around dymamically? GameShark codes that changes things like Mario's health only deals with fixed addresses, and that doesn't seem to be a problem. The data for Mario's geometry and textures, the level geometry data and some other textures files are loaded at specific places in RAM when the level starts, and those don't move in RAM. I'm not sure you have the right definition of DMA...

Here is data found in the ROM at 454AEC, part of the "Level layout data" which loads stuff in RAM while the level is initialized. Other stuff is loaded by other commands not shown here.


18 0C 00 07 00 44 AB C0 00 45 45 E0 -- Decompresses the castle geometry MIO0 data in RAM
18 0C 00 0A 00 2A C6 B0 00 2B 8F 10 -- Decompresses cloud and water background in RAM
1A 0C 00 09 00 35 ED 10 00 36 59 80 -- Decompresses other castle textures in RAM
18 0C 00 05 00 16 D8 70 00 18 05 40 -- Decompresses Peach geometry
17 0C 00 0C 00 18 05 40 00 18 0B B0 -- Decodes Peach geometry
18 0C 00 06 00 1D 83 10 00 1E 4B F0 -- Decompresses Toad, Lakitu and MIPS geometry in RAM
17 0C 00 0D 00 1E 4B F0 00 1E 51 F0 -- Decodes Toad, Lakitu geometry
18 0C 00 08 00 1F 22 00 00 20 08 D0 -- Decompresses [!] boxes and other common objects in RAM.
17 0C 00 0F 00 20 08 D0 00 20 14 10 -- Decodes [!] boxes etc. geometry

Not so far after this data you can find 2E 08 00 00 07 00 F3 A0. Which loads the collision map for the whole level from address F3A0 in the castle geometry file.

What I found while trying to make a name list of the possible objects in a level is that unless we edit much more data, we can only use objects that are loaded for this particular level. So you cannot put a Koopa or Goomba in the Castle grounds scene without some rather heavy editing.

The other kind of objects found inside the MIO0 level file seems to be shared by all level though, coins, trees, doors etc. (I didn't confirm this, it's a guess)




eNathan

Goomba
Level: 8

Posts: 7/33
EXP: 1773
For next: 414

Since: 08-07-05
From: United States, but does it matter?

Since last post: 1 day
Last activity: 8 days
Posted on 08-08-05 09:28 PM Link | Quote
VL-Tone, if im wront about DMA then there must be alot of inaccurate info on the internet (which I should have assumed). Or maybe they were just explaining in a rather simple method, and as a result they had to put a slant on the truth.

I am going to download some other emulators to see if the addresses are static.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.131 seconds.