Airikita
Member-
Posts
1,192 -
Joined
-
Last visited
-
Days Won
99
Content Type
Profiles
Forums
Downloads
Calendar
Bug Tracker
Everything posted by Airikita
-
Dammit, I'm fukkin rich today: Alright Microsoft, where's my money???
-
LoL, you sound like one of those super happy/crazy killers. It's like a spoof/parody of an LP, I like it!
-
And, I have made a little lead today: Still doing a lot of digging, trying to find some leads on the GBC cart being converted, but it's apparent that the address is stored to be used. Funny thing is that it's stored too many times? I don't understand why... Ah, Nintendo... I've been busy too, so I've been slacking off on my other projects.
-
Yeah, I know you mentioned it... I did some digging on it, and that was just a video I thought I'd pop into the topic. Also, Pokemon Stadium 1 may not be compatible with GBC games but just GB games, I wouldn't chance it. I have made headway on finding the Transfer Pak with some digging I found Nintendo's documentation: http://n64devkit.square7.ch/pro-man/pro26/26-07.htm It's saying there is a check for 0xA000 and 0x2000. I see 0xA0000000 has data, but 0x20000000 has nothing (according to Nemu). I did a search on Pokemon Stadium 2 for 3C012000 and found some results in RAM. I found something in OoT Debug, and according to Playtendo, you can save custom cutscenes with the debug camera to a memory pak.
-
Apparently Gameboy Tower can play the game in Pokemon Stadium 2: Better yet, we could hack the ROM to play Gameboy games by going straight to the built-in interfacing in Pokemon Stadium 2.
-
All valid points xdan, and glad you pointed it out. For the rom chop the configuration is unknown, but a burner is possible. The configuration for N64's rom chips vary. ED64 is still possible, but I'm making a custom cart for myself to save money from buying the ED64.
-
Naw, I was thinking of reading straight from the Transfer Pack, not have it connected to the cartridge... I realize now that the code would not generate the same, and I would probably need a real GBC to use. It could be possible to use the Transfer Pak alone, idk.. Would require some code converting, and dma work. I would have to look at the code for GBC ROMs, but it can still be doable. I could convert the stuff to RAM, translating it to N64 code, then run the code (again, converting code).
-
EDIT: Reviewing C2 and 82 commands, they seem to relocate display lists within the code... so they're a bit irrelevant, which is good... I wasn't going to just fix them without first knowing what they were. It's not like I need to associate the zobj file with the actor AI file (although it's possible I could do that later, which will require other options). I could go full-on actor/object editor if I get the right fixings. Would be better if I could hook the emulator process, but I'll have to focus on the file for now. The Pid is obtained, but the JAR files to read from process memory are all mixed up, and there's little documentation on them. I might have to use C# to get the RAM data of a ROM, which I'll have to research later as I never fully coded in C before. Also, it could be possible to read the RAM for the OoT ROM, but I don't know a way yet... not without digging at the process, which is turning out to be too OS-specific if I tinker at it. Might not end up with what I need either. I found a way to do it with Linux, but I'm not going to be shitty and just make it do the operation for Linux. Besides, testing in Linux is.... blargh!!! I'm too used to Windows like that. Not saying I won't make it available for Linux, but one without the other defeats the purpose of the feature for me. And chances are it may not even work. EDIT2: UPDATE: And... with some spare time, here's a generated list of static values from a sample actor: Same can be done for any actor. It also seems there are more relocation values shoved in there, so I might have to look into them. They could point to functions, so it's likely I may not change those, but rather filter them out (but still keep them). It's likely other relocators are filtering those out, possibly the 82XXXXXX or C2XXXXXX operations I found earlier
-
It's interesting, yeah, but I just found something to work with something in particular. Right now it appears to be a Windows-only tool, I don't know if I'll work on it to work for Linux yet as I have to work out the kinks. I picked up a book titled "Windows XP Secrets" from the library, it has some info on Windows' console and .msc files, so I will hopefully dig up something with that.
-
Thanks, and I'm on a roll tonight... I tried to look up how to get the process PID, and every Java site I went to was like "Nuh, you can't do that!"... Well, behold: I got it from Windows' task manager, but now I don't know if I can get it to work for Linux. I could try to find the path for Linux's process list, but maybe not... Also, Nemu64 is being a little butthole from my app trying to execute it. I don't know why, but Nemu throws pissy errors when you try to open it from another application... which is weird. The PID always changes, so this is just an identifier for Windows' runtime to eventually find the RAM source. Might need to tinker with it more. I'm a bit stumped on one of the relocators though... does anyone know what the C2XXXXXX operation is for? It seems to be a duplicate of another relocator.
-
Got the relocations to generate a list: I will have to analyze samples before I begin to generate a complete set of items, since this is only the first step to loading actor values. Error checking is detailed, checking for invalid sizes and offsets, so you can't really spoof this (yet you probably can, I will do another check for size of the actor file vs the size of the relocations, and any array index exceptions). Other anticipations: Plugging in the altered data file into an emulator to test, removing the need to save over a file every time and load it. I will do this within the application, which will allow choosing an emulator, and a click of the button will send the temporary data to the emulator for testing. It's not perfectly live, but it will be as "live" of an editor as it gets. The obstacles to making it a live editor is not an issue of reading the RAM, but rather an issue of converting the values to ROM later. It's possible to load the data from emulator RAM, but I will have to look into it later as an option. You could, in theory, create a ROM file from the RAM data. You won't get a live edit, but you can likely reload the map you're testing in by moving around Link. That will be reviewed later in the project as the main focus is the ROM file for now.
-
Zelda's Eternal Youth Hack - [MORE UPDATES!!!]
Airikita replied to Airikita's topic in Modifications
I'm trying to dig up display lists in Pokemon Stadium 2, but the setup is very... bizarre: And yes, this is part of the project... I am hoping to convert it to OoT's output later, but uh... does anyone know how the shit the display lists are even operated in Pokemon Stadium 2? I found the texture/tile commands, but eh... I can't really find a file table, but I wouldn't be surprised if there wasn't considering it's more likely Pokemon was just programmed for the visuals to be loaded on-demand, and the RAM changes frequently. EDIT: (scrapped) -
I was figuring that perhaps I could save money by modding my own cart, instead of buying ED64. I would need a custom ROM, which would require modding a ROM that has the same CIC chip info. I also have an old SD card reader sitting around from a computer that died from a defective CPU. I mean, this is possible too. I mean, you could create a code hook to create a thread that detects the Transfer Pak, then uses the save data... would require digging into Pokemon Stadium 2, but it's not necessary unless you really want to do something wild with it.
-
Hello! I have a question for everyone... I normally hack Zelda OoT, but since I received my N64 with Pokemon Stadium 2, and there's not much I can do with my mod for now, what if I start a new project by making an N64 cart play GBC games? I want to use it to play Pokemon Gold on N64, or I could transfer a hacked ROM to a GBC cart, and play it on GBA (meh...). I dunno about you, but I might just start Homebrewing my own N64 Gameboy Color cartridge. Maybe I'll torture a Superman 64 cart (but it's $15 at Microplay... dafuq?) although I want to make a modified ROM use the features of the N64 cartridge to play Gameboy Color games. I don't have sodering equipment, or anything yet, but I could probably get lucky with an N64 cart in the dump, one of those crappy N64 games tossed away, and mod it. I could use a break from Zelda OoT for a while, and maybe look into modding an N64 cart for this purpose. Any thoughts? Disputes? Ideas?
-
I sold a lot of my GBA games and got an N64 console and Pokemon Stadium 2. The console was $44 and the game was $20, yet I only had $65 on me. They let me buy it. I can't wait to play it later, it was a game I always wanted in its cart form... Behold! I also took the cover off the expansion pack. Looks like it comes with an Expansion Pak! BONUS!!!
-
Editor now loads faster, and creates a clean list of actor files: I will move on to making the list generate actor files later, and also will generate values.
-
Hello everyone, Today I decided to tinker with a new project, for better AI hacking. For now it will be for values, whether it would be float or otherwise. I am running a few tests, and will be updating accordingly. To start with, an entire ROM has to be uploaded to the application in order for the values to be loaded, and it has been tested on 1.0 and Debug so far, and I doubt I will have any issues making this compatible with 1.1 or 1.2 whatsoever. First testing phase: EDIT: I changed the way the list loads, it won't take this long to actually load any more. All actor offsets from the official actor table are loaded, nothing else (if everything works as it should). Unfortunately loading individual actor files is NOT POSSIBLE for the values to be loaded, due to the fact that actor files on their own don't contain relocation information to make the correct changes. Some of you might be aware of this, or not, depending on how experienced you are with AI hacking. This tool will be usable for anyone, not just me.
-
The green one looks like a lime gummy Goron, yum yum. XD
-
Supposed to be to 00000000 which is a NOP (cancels that operation), if you change it to 0C000000, it's just going to hang the system. EDIT: Try changing the one at B4D45C to 00000000 also, might be a mixture of commands.
-
I've been listening to Vocaloid songs today from my playlist, one I would recommend is this mash-up mix: http://www.youtube.com/watch?v=JaTxVDqN-Y8
-
Zelda's Eternal Youth Hack - [MORE UPDATES!!!]
Airikita replied to Airikita's topic in Modifications
Before I forget, I would like to thank someone for helping me, whether he likes it or not. I give credit to SoulofDeity for teaching me how to hack display lists, however he's being an anus right now, and not helping me fix a current issue, instead is quitting hacking. I wish you luck (anus) and hope your tooth explodes in your mouth. -------------------------------- On another note, I would also like to credit the following people for their assistance: - Sakura - HeavyZ - xdaniel - Petrie911 and mzxrules for their actor/exit knowledge (clashing minds always helps, no?) And I acknowledge any assistance in the last while. If you guys are worried, this is not a quit post, this is just a shout-out since I forgot to list some honorable mentions. Even if a certain anus won't admit he's being a smartass for accusing me of not knowing anything <^>. Yes, I still care, but I still move forward. -
OH! Why not make it so the panels can be edited? I don't know how familiar you are with textures, but it would be fun to change that panel that shows the six medallions. I'm loving this, it has smex appeal~
-
I'm sure a LOT of people have no idea... I mean, it doesn't shock/surprise me to know this, but it was something I have been unaware of. As a child, I was more indulged into Zelda to wonder if Nintendo was something else before... I mean, I thought Nintendo was a new company just for gaming, I didn't know the name was used for OTHER things. To me it's an oddity to keep the same company name, but perhaps it's somewhat a good thing. The "love hotel" is interesting if you read into its history.
-
That would be great. I have my own stuff to do today, so I won't be waiting all day for it (thank goodness).
-
Yes, the combiner is a challenge... although yours still looked similar to one I pulled up, I guess that worked then?