News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - IIMarckus

Pages: [1] 2
1
You still haven't updated it with the breakdown for the cart checksum tables.
Thanks, it’s there now. Anything else I should add?

2
Perhaps some kind of collaborative disassembly for certain popular games might change this.
I’ve started one. So far it’s just data extraction though. I don’t know N64 very well.

3
If you’re not already, you should be using the disassembly for your hack. The time to set it up is worth spending.

Here’s an example of how to add a new Pokémon to Pokémon Red with the disassembly.

4
Programming / Re: [DMG] How to disassemble a ROM?
« on: March 25, 2016, 06:24:17 pm »
as i'm getting familar with Z80 Opcodes and using BGB disassembler, i'd like to document the subs and loops found in the game-ROM. It would be a great help, if some experienced user may give me some advice on "how to do it right". I'm sure there are some best-practice rules to follow.

I started this project and this project many years ago, although at this point my work has been eclipsed by the larger community that grew out of it.

If you’re interested in doing a large‐scale disassembly, data is more interesting than code at first. Start with the easy stuff, text and graphics, and pointers to them if practical. A debugger will be your best friend (BGB is the only choice right now).

Automation is helpful where you can fit it in. I was skeptical at first, and was doing everything basically by hand, but after someone automatically disassembled all the map scripts at once (which in Pokémon Red are written in assembly), it became much easier to figure out what particular subroutines did by comparing to the gameplay behavior I knew the maps had.

Do what you can to release quality work, but don’t be afraid to share ugly code. Initially I kept everything private, with the intent of releasing it publicly at some point; after a while, though, I came to my senses and realized that if I ever set the project down it would end like all those other ROM hacking projects that never get finished. Losing my ego, releasing my unfinished work, and accepting that reputation is not important is the only reason these two disassemblies got finished.

Yes, they are 100% disassembled thanks to many people, and have been used for countless new projects:

Sorry, this went a bit off the rails. But the ROM hacking community has a real problem with hoarding, and I just want to share how moving past that caused my own project to grow beyond my wildest expectations.

5
ROM Hacking Discussion / Re: Link to the Past GBA Voice Hack?
« on: May 22, 2015, 02:35:47 am »
I always assumed that the Oracle games were designed as a prequel to Link's Awakening, given the former two introduced Link to Zelda and Ganon, and the latter game referenced both of them. If anything, all evidence points directly against the Oracle games being a direct sequel to any Zelda game.
The Oracles are clearly a prequel to Link’s Awakening (for example, the boat at the end of Oracles), but Link’s Awakening was also clearly a sequel to ALttP (e.g., notice the manifestation of nightmares as Moldorm, Agahnim and ALttP Ganon). Hyrule Historia confirmed the timeline as being ALttP → Oracles → Link’s Awakening.

The only indication otherwise is the fact that Zelda and Link don’t appear to have met before in Oracles. But that could be attributed to any number of things without messing this up (poor translation of dialogue, same Link but different Zelda, or just an oversight).

6
ROM Hacking Discussion / Re: Speech to text
« on: January 09, 2015, 10:13:56 pm »
Chapter 2:
After months of traveling, we reached the city of Yuimen, on the borders of China. It was disquieting leaving behind the familiar lands of my youth. Still, with my new friends around me, I determined to brave the mysteries of an unknown land. At that time, I had no idea of the dangers that were lying in wait to entrap us.

Chapter 3:
Lord Taurus had dogged our footsteps throughout the western lands. Finally, we were able to defeat both him and his henchmen. But our joy was short‐lived. In our moment of victory, the staff holding the guardians was stolen by Pyric, son of Lord Taurus. However, I could not give up. We raced into the fabled land of India, hot on the heels of kid Pyric and my stolen staff.

Chapter 4:
After much trouble and travail, we reached the famous Thunder Temple, only to find a burned‐out husk. There, before our astonished eyes, appeared the mocking figure of Asura. What exactly had happened here? Overwhelmed and uncertain, we made our halting steps through the doorway to heaven.

Final:
We had defeated the powerful Asura. We had saved the world. And it still seems like a dream to me. All of the pain we felt, all of the fun we shared—all of it has been carved deep into my mind, leaving only memories.

But they are not memories. Them I will never forget, not even for a day. They are more important to me than anything. They are my friends. This was our journey. If ever someone should read this memoir, I beg you to remember us, my friends and I, as we were… on our journey West.

7
Newcomer's Board / Re: Repro Boxart Collection
« on: January 06, 2015, 06:07:01 am »
The Cover Project comes to mind but I don’t know if they do hacks or just covers (some custom) for licensed games.

8
ROM Hacking Discussion / Re: PokéText utility
« on: November 24, 2014, 05:53:05 pm »
On the Swampert Tools website, which has a big collection of Pokemon ROM hacking utilities, there's a link for a program called PokéText which is supposed to work with all the first and second generation Pokemon games. There's no descriptions, but I assume it's some sort of text editor. Unfortunately, the link to this program and all the others listed on the site are broken. I was wondering if anyone had PokéText as I'd like to use it for a ROM hack.
I would definitely suggest using the Pokémon disassemblies as a base for any new hack these days. Pokétext by nature can’t know where all the text in the ROM is that you might want to edit. I don’t know if it lets you easily expand the length of text either.

In the disassemblies text is just stored in files you can easily edit with a plain old text editor like Notepad++. (example) Once you’ve set everything up it’s much easier to work with than a ROM editor.

9
What would you use for Game Boy ROMs?
For the Pokémon Red disassembly, we used mostly a combination of a simple disassembler plus data extraction tools written in Python and manual work with BGB.

10
patch against crystal

With the disassembly it was as simple as applying this diff.

11
Maybe I'm looking at a different version, as the addresses seem off. I'm looking at the English Gold version.
The addresses are different because the linked thread is based on Crystal, not Gold.

12
This has been done before… see here for an example.

13
Newcomer's Board / Re: Gameboy Sound Extraction - MIDI
« on: October 13, 2014, 02:12:49 am »
The disassembled audio is almost exactly what I am looking for in terms of the notes that are played! Is there any way to export it as a MIDI or other visual representation of it, where the notes are grouped and played together?
https://github.com/mtolly/pokemid

I’ve never used this but have been told that it supports round‐trip conversion of music from the Red disassembly without issue.

14
Newcomer's Board / Re: Gameboy Sound Extraction - MIDI
« on: October 09, 2014, 11:44:24 pm »
Note that Pokémon Red and Blue have been completely disassembled, and the music has been dumped (in a custom text‐based format).

Pokémon Crystal hasn’t been completely disassembled, but its music has similarly been dumped. In fact, there’s a modified version of the Crystal disassembly, CrystalComplete, with music imported from Pokémon Red, Pokémon Pinball and Pokémon TCG 1 & 2, as well as some custom tracks.

15
Newcomer's Board / Re: hex editing zelda game
« on: August 01, 2014, 11:08:08 am »
i am trying to use a hex editor hxd to make changes in a zelda links awakening rom. what im trying to do right now is make the enemies and bosses have more health. im not sure which of these numbers im supposed to change? most enemy just have 1 health and boss have mostly 8 health. usualy when i trying to change all the 1s and 8s into a higher number it just does nothing noticable because there are thousands of them... if i try to change them all it just messes up the rom. how do i find exactly what the hex numbers are and get the ones i need?
You’ve already seen how many false positives there are by just looking at 1s and 8s. FAST6191 also pointed out that just because an enemy takes 8 hits doesn't mean he has 8 HP (maybe he has 16 HP and the sword does 2 damage at a time).

You want to use BGB’s debugger. Enter a boss room, dump the RAM, hit the boss once, dump the RAM, and look for bytes that decreased between dumps. If there are still too many false positives, hit the boss again and do a third dump. (BGB might actually let you do this sort of cheat searching automatically; I don’t actually remember.) Because the Game Boy maps work RAM to $C000–DFFF (and the original GB didn’t bank said RAM at all) your value will definitely lie within that range.

Once you have a good memory location, test to make sure it’s right: use BGB to set a write watchpoint on it and then restart the boss fight. It should drop you into the debugger when the boss appears, and every time you hit the boss. The code the debugger drops you into when you hit the boss is probably “sword does damage”-related code, which is probably not what you want. But the code you get dropped into when entering the boss room is probably initializing its HP, which means it reads the HP value from some table of enemies, or maybe from a map object with its own HP.

16
Don Hodges has in-depth analysis of some arcade glitches.

17
ROM Hacking Discussion / Re: Pokemon Yellow NES Translation Project
« on: December 12, 2012, 07:18:43 pm »
Well, the Red and Green remakes had data for all the (then) new Ruby & Sapphire Pokemon. And, well, Gold & Silver Pokemon by extension.

Notice how all of these appeared early in the cartoon? I'm not sure if Donphan appeared early too, but I want to say it did too. I remember Kids WB making a big deal about the Pokemon Egg (a concept that was also new to Pokemon) hatching into an unknown Pokemon, and the Pokemon movie promoting not just Mew and Mewtwo, but also the first appearances of Marill, Snubbull, and Elekid. And I think, what? Bellossom?

Donphan showed up near the beginning of the first movie. Snubbull and Marill showed up in the first movie’s Pikachu short. Elekid and Bellossom didn’t show up until the second Pokémon movie’s Pikachu short (which was still before G/S came out).

I remember hanging on every word of that news nearly 13 years ago…

18
ROM Hacking Discussion / Re: Open Source ROM Hacking Projects
« on: March 19, 2012, 03:18:41 am »
Well that certainly counts.  Pokémon communities seem to be really good about sharing stuff and info.  Slightly off topic, but do you know how far along the Crystal restoration has come along?  I know they were trying to get all the mobile phone stuff into the game.

Not sure whom you mean by “they.” Morfeo (a Spanish hacker) released a modified Crystal a couple years ago that had some mobile features put back in, but I never looked at it in great detail to confirm it was complete.

We’ve actually just started on a Pokémon Crystal disassembly. Contributions welcome. :)

19
ROM Hacking Discussion / Re: Open Source ROM Hacking Projects
« on: March 09, 2012, 11:41:37 pm »
Come to think of it, how many cases can anyone think of where somebody took released source and used it to make their own patch?  Has that mostly been limitted to handing-off translation projects?

The Pokémon Red disassembly is the base for Sawakita’s Pokémon Wood, a hack that adds new features (RTC, uncompressed graphics, new scripts). Someone else is also using it to add a VWF to Pokémon Red. Both of these are unfinished (but so is the disassembly, so…).

20
ROM Hacking Discussion / Re: Open Source ROM Hacking Projects
« on: March 03, 2012, 02:30:13 am »
I used to feel the same way, until I came to the conclusion that the benefit gained from my retaining control over a project and keeping it perfect is less than the benefit gained by releasing it. In particular, it doesn’t just help other people, it helps me, by attracting contributions from other people who do stuff I haven’t done myself.

changes will happen to it that I don't approve of

I think this pales in comparison to the probability that changes will happen that you do approve of.

Example: Someone recently decoded how battle animations work in Pokémon Red, and added the code to the disassembly. I would have gotten to this eventually—I actually had started work on it. Because the work I had done on it was public, he was able to use it as a base to complete the project, disassemble the code and data, and document it all. If I hadn’t released my half-finished work, he would have wasted time reverse engineering it all himself, and I might never have seen the final result. Open-sourcing things helped both him and me.

incremental releases will happen, flooding the web with dozens of versions of a translation, none of which fit within my ideals.

I argue that a well-maintained project actually decreases fragmentation. How many Wikipedias are there? Only one (that people care about). The data on Wikipedia is under an open license, so anyone could create their own Wikipedia mirror with their own subtle changes, but nobody does that—they contribute to the original.

Sure, people take it and sell crappy ebooks on Amazon. But would Wikipedia be what it is if it were under a restrictive license? Even Linux, which is both open source and kept in a source control system specifically designed to make things easy to fork, is rarely forked—the only one I can think of is Android, and they’re even working to merge that into mainline. The point of open source is to reduce the barrier to entry for contributions.

Pages: [1] 2