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
RT-55J

Ninji
Level: 23

Posts: 194/240
EXP: 65287
For next: 2436

Since: 12-29-04

Since last post: 9 hours
Last activity: 9 hours
Posted on 08-24-05 09:01 AM Link | Quote
Originally posted by VL-Tone
RT-55J thanks for the sample Was it part of a mailbag entry on TMK? If so can you link it?

It's in the 15th e-mail in the game information section.
mekakame

Micro-Goomba
Level: 7

Posts: 12/18
EXP: 925
For next: 523

Since: 06-08-05
From: Samut Prakan, Thailand, Asia, Earth, Milky Way, Space...

Since last post: 5 days
Last activity: 1 day
Posted on 08-27-05 06:42 AM Link | Quote
I wonder which program you use to hack N64, and rip grphics?
Dark Ludwig

Red Paratroopa
Level: 21

Posts: 68/172
EXP: 45740
For next: 4203

Since: 09-17-04
From: Georgia

Since last post: 9 days
Last activity: 2 days
Posted on 08-27-05 07:23 AM Link | Quote
Originally posted by mekakame
I wonder which program you use to hack N64, and rip grphics?
They pretty much most likely use hex editors as far as modifying little things in the rom, but they made their own MIO0 decompressors for the graphics. They then just made programs that display them. I am 99% sure that's right.....
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: 6576/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-27-05 12:08 PM Link | Quote
That's pretty much what I did. I mainly use Tile Molestor for the graphics part, though, since my program isn't as accurate.
eNathan

Goomba
Level: 8

Posts: 27/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-28-05 11:37 PM Link | Quote
(been away for a while..)

wow im suprised, it seems like you's are getting somewhere with this Mario 64. BTW, Excellent hack V-Tone! Thats pretty advanced stuff im sure, chaning mario's head into princesses's

Im still trying to find the X Y and Z cords of mario atm, I have found a few addresses that change Mario's location but I am not sure of their exact location (maybe a byte or two off?) and what type of float they are Ill get it them soon to!

*eNathan plans to make a SM64 teleporter
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: 6621/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-29-05 12:16 AM Link | Quote
If you mean RAM addresses, GSCentral should have them.
mekakame

Micro-Goomba
Level: 7

Posts: 13/18
EXP: 925
For next: 523

Since: 06-08-05
From: Samut Prakan, Thailand, Asia, Earth, Milky Way, Space...

Since last post: 5 days
Last activity: 1 day
Posted on 08-30-05 05:19 PM Link | Quote
Originally posted by HyperHacker
That's pretty much what I did. I mainly use Tile Molestor for the graphics part, though, since my program isn't as accurate.

I how have Tile Molester v0.16
When I open it, it doesn't seem to open anything... How to use it?
Riku

Giant Goomba
Level: 42

Posts: 699/1239
EXP: 505941
For next: 15421

Since: 06-21-05
From: ....Is this like a custom title?

Since last post: 6 hours
Last activity: 6 hours
Posted on 09-01-05 05:29 AM Link | Quote
So would it be possible to when you get all 120 stars, make it have a boss run? Ya know, like Koopa 1, 2 and 3? Seprate levels I mean.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 163/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 09-06-05 10:39 AM Link | Quote
Hi there, gotta keep this thread alive...

The image format in Mario 64 and in many other n64 games, is 16-bits per pixel, 5 bits per color channel and 1 bit for alpha, RGBA 5551. To produce my images I used my own program that converts a MIO0 file into an RGBA 8888 (8 bits per channels) RAW file that I open in Photoshop.

For some reason, Photoshop defaults to CMYK color when opening a 4 channel file. I converted the images straight to RGBA color. Unfortunately I recently found out that I it still resulted in colors that are off. So it means that all the images I posted until now have wrong colors Maybe I'm daltonian and I don't know, but I didn't notice it before I'll try to make a batch script to fix them all.

As for my level editor, the version online is not really useful now as the included combos mostly work in other levels. You can move and rotate objects though...

But my own development version did improve. I recently discovered some key commands used in the object layout data.

Take Level 1:

You can find this line in a list in my hacking doc http://pages.infinit.net/voxel/Mario64HackingDoc.txt

[Start ] [ End ] [Entry ]
00405A60 00405FB0 0E000264 -- Bob-Omb's Battlefield

It comes from this command at 2AC10C in ROM:

00 10 00 0E - 00 40 5A 60 - 00 40 5F B0 - 0E 00 02 64 - 07 04 00 00


The "00" command that is 0x10 bytes long loads and warps to a level. The level layout data is loaded in "bank" 0E in RAM. So 405A60 is the address (in ROM) of where the object layout data starts, 405FB0 is the end, usually where a MIO0 file is (and that file is not necessarily used by this level). Now 0000264 is the entry point inside the level layout data. This is where the game starts to read data inside bank 0E in RAM. (these are symbolic RAM banks, not hard-wired).

So 405A60+ 0x264= 405CC4 At this address you get:

1B 04 00 00 --This commands seems to signal the start of MIO0 texture and
geometry loading.
18 0C 00 07 00 3F C2 B0 00 40 5A 60 -- Decompresses a MIO0 file from 3FC2B0
into RAM (bank 07)
1A 0C 00 09 00 32 D0 70 00 33 4B 30 -- Decompresses MIO0 file (textures only?)
18 0C 00 0A 00 2A C6 B0 00 2B 8F 10
18 0C 00 05 00 13 4D 20 00 13 B5 D0
17 0C 00 0C 00 13 B5 D0 00 13 B9 10 -- Copy Geometry layout data from 13B5D0 in
ROM into RAM bank 0C
18 0C 00 06 00 1C 42 30 00 1D 7C 90
17 0C 00 0D 00 1D 7C 90 00 1D 83 10
18 0C 00 08 00 1F 22 00 00 20 08 D0
17 0C 00 0F 00 20 08 D0 00 20 14 10
1D 04 00 00 -- End of RAM loading commands?
25 0C 00 01 00 00 00 01 13 00 2E C0 -- Must point to behavior data...

06 08 00 00 15 00 06 60 -- Command 06 makes the program jumps to somewhere
else in RAM to continue loading.
In this example, it jumps to offset 000660 in bank 15 in RAM, which contains
data copied from 2ABCA0 in ROM.
Bank 15 seems to load a lot of MIO0 files and many objects (command 22, see
below) that are shared by many levels.
To jump back here, command "07040000" is used.
06 08 00 00 15 00 07 6C
06 08 00 00 15 00 09 58

22 08 00 17 16 00 0F E8
22 08 00 36 0E 00 04 40 -- Command 22 is used to load geometry layout data for
objects in levels
In this example, geometry data is loaded from bank 0E in RAM (where this data
is) at offset 000440.
This data is associated with number 36. This is the same number used after by
command 24 to position objects in level
Number 36 for Level 1 is the grill that encloses the Star behind the Chain
Chomp.
Note that objects from other banks can be loaded and many "external" objects
are loaded from bank 15

22 08 00 37 0E 00 04 58
22 08 00 38 0E 00 04 70

1F 08 01 00 0E 00 04 88 -- Command 1F is much like 22, but is used only once
and usually to load all the main geometry data from the main MIO0 file.

06 08 00 00 0E 00 00 00 -- Other jump, this time at the begining of this data
(in bank 0E in RAM), loaded from 405A60 in ROM.
06 08 00 00 0E 00 00 7C
06 08 00 00 0E 00 01 E8

24 18 1F 00 E6 62 03 E8 19 40 00 00 00 87 00 00 00 0A 00 00 13 00 2F 74
--The already explained command 24.
E6 is an object that was defined by command 22 (or 21 which can load data
directly from a bank without geometry layout data)

24 18 1F 00 02 47 0A 7B EA F5 00 00 FF 66 00 00 00 0B 00 00 13 00 07 5C
24 18 1F 00 06 90 0E FB EA 6D 00 00 FF 67 00 00 00 0C 00 00 13 00 07 5C
24 18 1F 00 E6 2C 04 00 F2 E9 00 00 00 6B 00 00 00 0D 00 00 13 00 07 5C
24 18 1F 00 07 BC 03 00 19 DA 00 00 FF 69 00 00 00 0E 00 00 13 00 07 5C
26 08 0A 09 01 0A 00 00 -- I don't know what command 26 is about.
26 08 0B 09 01 0C 00 00
26 08 0C 09 01 0B 00 00
26 08 0D 09 01 0E 00 00
26 08 0E 09 01 0D 00 00
26 08 F0 06 01 32 00 00
26 08 F1 06 01 64 00 00
2E 08 00 00 07 00 E9 58 -- Loads collision data from decompressed MIO0 file
3FC2B0, at offset E958 in bank 07.
39 08 00 00 07 01 10 4C -- Loads smaller object commands from inside the MIO0
file (Coins, trees and other things found in the big list you did)

I don't know much about the rest of the data, it ends up with command "0000",
then it's the geometry layout data for level 1.
30 04 00 00
36 08 00 00 00 03 00 00
31 04 00 00
20 04 00 00
1E 04 00 00
2B 0C 01 00 00 87 E6 62 00 00 19 40
11 08 00 00 80 24 BC D8
12 08 00 01 80 24 BC D8
1C 04 00 00
04 04 00 01
02 04 00 00 --End of level layout data.
00 00 00 00

Now about the geometry layout data, I wont deconstruct the whole data since
I don't know much about it.
The data happens to start at offset 0x0440 in bank 0E.
As you can see in the command up-there: "22 08 00 36 0E 00 04 40", it's the
data to load the grill geometry and associate it with 36.

20 00 03 E8
04 00 00 00
15 04 00 00 07 00 E4 58 -- loads geometry data inside bank 07, starting at
offset E458.
05 00 00 00
01 00 00 00 --End of this object geometry layout data (to end command 22's call)


Ok that's about it as for describing data. (Dang this post is long!)

My development program can now show just about every level including most of it's "24" objects. My programs now look into a folder containing all decompressed MIO0 files from the game. So it can now decode just about everything on the fly. This means an eventual editor could feature the actual objects instead of boxes It also decodes the textures directly from the MIO0 files now so the colors are fixed. For now though, it's very slow to load a whole level and I'm still experimenting. One thing that I have to find is how the different body parts of Mario and other enemies are connected, and it's probably in the geometry layout data. Another important thing missing is the connection between commands 22 and level layout found inside compressed data. Those for which there is a description list.

One last thing, I put all the pictures I posted here in an album that you can see there:
http://pages.infinit.net/voxel/m64index.html

Note, the colors are off



(edited by VL-Tone on 09-06-05 03:05 AM)
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: 6876/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 09-06-05 11:17 AM Link | Quote
Awesome. Looking at commands 06 and 07 it seems like this is some sort of script code. If you looked at what the game does with the command number you could very well find a jump table pointing to the code of every command.

Any idea how the RAM 'banks' are mapped to real memory addresses? Maybe they're byteswapped or something, like 01 00 23 45 should really be 00 01 45 23. If it was just a straight memory address, it seems pretty odd to stick a zero in there.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 164/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 09-06-05 11:37 AM Link | Quote
Originally posted by HyperHacker
Awesome. Looking at commands 06 and 07 it seems like this is some sort of script code. If you looked at what the game does with the command number you could very well find a jump table pointing to the code of every command.

Any idea how the RAM 'banks' are mapped to real memory addresses? Maybe they're byteswapped or something, like 01 00 23 45 should really be 00 01 45 23. If it was just a straight memory address, it seems pretty odd to stick a zero in there.


Yeah these are called ASM macro-commands, StarFox uses that too.
I don't know exactly how banks are mapped into memory, but from I've looked inside a savestate, banks don't all have the same size. I would guess that their location is always the same though.

I'm not sure what you mean by byte-swapping things though everything I posted is in normal byte order. I cannot find your example "01 00 23 45" in my post, what kind of offset were you talking about?

Edit:

I think I know what you mean HyperHacker...

This is from the command that loads geometry layout data for object type 36.
22 08 00 36 0E 00 04 40

0E is the bank number and 000440 is the offset inside this bank. And I'm %100 sure about it since I use it to decode levels. 000440 is meaningful, it's the offset of the first command of the geometry layout data in bank 0E, and it happens to be the grill that appear when using object type 36. Other offsets precisely match. I did not find the use of this command by messing with it and loading the emulator, I found it by figuring out that those were offsets to geometry layout data inside a specific part of RAM, just by looking at the data. Then I did some experimentation that proved it to me. Most everything described in my last post is tried and tested, except things with question marks



(edited by VL-Tone on 09-06-05 02:57 AM)
(edited by VL-Tone on 09-06-05 03:06 AM)
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: 6885/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 09-07-05 02:33 AM Link | Quote
That was just an example. I figured that in the command you posted, the real memory address would be 000E4004. But it's just an idea.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 165/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 09-07-05 07:57 AM Link | Quote
HyperHacker, I guess I over-reacted, but I felt a little insulted you thought I have done a byte order mistake, when I fully knew it was impossible, since all offsets matches and are used in my current decoder version... Anyway I don't do byte ordering mistakes anymore!

So like I said, in my example, it's really 0E for the "bank" and 0440 for the offset inside that bank.

Here is something very very interesting that I found...

Take this command: 18 0C 00 07 00 3F C2 B0 00 40 5A 60

It decompresses the main MIO0 file for level 1 (3FC2B0 in ROM) in RAM bank 07, which is always used to store the main geometry data for a particular level. 405A60 is the end of this MIO0 file in ROM.

You can re-point the pointer to the end of the ROM at 800000 for example (don't forget to set the end pointer too), and append a MIO0 file at the end of the ROM. Some emulators may want a ROM with a standard size so you may want to "pad" the rest with "00" or "FF" to get a 12 or 16 megs ROM. It works, I tried it, but you still have to decompress, recompress every-time you make a change...

But here is the very very interesting part: command 17 is just like command 18, except that it copies uncompressed data in RAM...

So try this: At 405CC8 in ROM, change "18 0C 00 07 00 3F C2 B0 00 40 5A 60" to "17 0C 00 07 00 80 00 00 00 81 17 C2". Then append the decompressed version of MIO0 file 3FC2B0 at the end of the ROM (at 800000), pad the rest to get a 12 or 16 megs ROM.

You can then edit the uncompressed version of the MIO0 data right in the ROM!!!

As a quick example, you can change the sign object byte (34) that is found near the starting point. Byte 34 for this sign can be found at 1129B in the MIO0 file (81129B in ROM) . You can change it to something else, like 64 for a breakable box.

The same could be done for almost all other MIO0 files. The only problem with this would be making patches for hack distribution, but still, for now it can be very useful to experiment without having to decompress and recompress data all the time!

(Edit: added an example hack of level 1's MIO0 file)


(edited by VL-Tone on 09-06-05 11:04 PM)
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: 6900/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 09-07-05 08:39 AM Link | Quote
Awesome. I wonder if that means we could compress things that aren't normally compressed if we run low on ROM space? (Though that would mean adding 24MB of content. )

If bank 7 is always used to hold the current level's layout, and the banks vary in size, then they're probably just various chunks of memory reserved for stuff. I imagine there's a master pointer table somewhere that would tell you the location of each 'bank'.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 166/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 09-07-05 09:06 AM Link | Quote
Originally posted by HyperHacker
Awesome. I wonder if that means we could compress things that aren't normally compressed if we run low on ROM space? (Though that would mean adding 24MB of content. )

If bank 7 is always used to hold the current level's layout, and the banks vary in size, then they're probably just various chunks of memory reserved for stuff. I imagine there's a master pointer table somewhere that would tell you the location of each 'bank'.


All the MIO0 files decompressed amount to a little less than 8MB so doing this for all files would get us a 16MB ROM, though you could use the compressed MIO0 file space in the first 8MB for other things. What is the biggest possible size for a n64 ROM? In any case, compressing the resulting ROM or patch using ZIP would probably save us as much space as using MIO0 compression.

Yeah I'm pretty sure there is a table for the "banks" locations, I didn't look for it yet though, one way to find it would be to find where bank 07 is in RAM, then looking for this offset inside the ROM.
Nebetsu

Shmee
Level: 55

Posts: 1401/1574
EXP: 1291130
For next: 23059

Since: 09-01-04
From: Nebland

Since last post: 3 hours
Last activity: 1 hour
Posted on 09-07-05 09:55 AM Link | Quote
VL-Tone: I just want to interrupt the technical mumbo-jumbo and say this:

OMFG WILL J00 HAVE MY CHILDREN??????


Seriously man: Keep up the good work. It's not often that I read a 20 page topic and wish it was MUCH longer.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 167/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 09-07-05 10:44 AM Link | Quote
Originally posted by Nebetsu
VL-Tone: I just want to interrupt the technical mumbo-jumbo and say this:

OMFG WILL J00 HAVE MY CHILDREN??????


Seriously man: Keep up the good work. It's not often that I read a 20 page topic and wish it was MUCH longer.


lol, I'm a man, and hetero at that (oh well do I really have to specify that in a ROM hacking forum?)

So you just read all pages of this topic in one stretch? How much time did it take?

I wish I had more time to spend on this, fortunately I will be able to post more often in September.
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: 6909/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 09-07-05 11:28 AM Link | Quote
Hello and welcome to last week. It's September 7th.

I think the max size for an N64 ROM is 32MB; any higher than that and you need to use some bankswapping or something. Though I'm not entirely sure. I doubt we'll be adding that much any time soon anyway.

If you can get me a dump of what would be in this 'bank 7' I can look for it in memory and see if I can find where it starts. From there a pointer table shouldn't be difficult to produce. I doubt it contains any length information though.


(edited by HyperHacker on 09-07-05 02:29 AM)
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 168/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 09-07-05 12:43 PM Link | Quote
Originally posted by HyperHacker
Hello and welcome to last week. It's September 7th.

I think the max size for an N64 ROM is 32MB; any higher than that and you need to use some bankswapping or something. Though I'm not entirely sure. I doubt we'll be adding that much any time soon anyway.

If you can get me a dump of what would be in this 'bank 7' I can look for it in memory and see if I can find where it starts. From there a pointer table shouldn't be difficult to produce. I doubt it contains any length information though.


I knew that it's September , so what I mean is that I have more time, starting this month, I guess I should have just said that

As for a dump of bank 7, if you are in Level 1, it should contain in RAM the decompressed data found in the MIO0 file found at 3FC2B0 in the ROM. It starts with:

31 8C 31 8C 31 8C 31 8C 31 8C 31 8C 31 8C 31 8C
31 8C 31 8C 31 8C 41 CB 39 89 52 0B 5A 4B 5A 4D
83 51 AC 55 9B D3 A4 15 BD 1B 31 8C 31 8C 31 8C

Cellar Dweller

Flurry
!!!
Level: 27

Posts: 244/269
EXP: 107817
For next: 8342

Since: 03-15-04
From: Arkansas

Since last post: 16 days
Last activity: 34 min.
Posted on 09-08-05 12:27 PM Link | Quote
This may need some more verification, but I think that I have found the location of a copy of the segment table in a savestate. Using a PJ64 format savestate the location is 0x33bb60 in the savestate(subtract 0x75c to get 0x33b404 in RAM). The 7th 32 bit word points to the current level data. The decompression locations for the MIO0 files seem to be dynamic.

It is posible that this may not be the master copy of the segment table.
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.024 seconds.