 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by Legendre |
| User | Post | ||
Legendre Micro-Goomba                 Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Hi,
Here's an idea I've been thinking about which could really push the envelope in ROM hacking quite a bit. A protocol to get the emulator itself in on the action. The hacked ROM would have instructions to the emulator imbedded in a header, or somewhere else appropriate. Instructions like, "check (some memory offset) for updates". Then, at various times during gameplay, numbers would be written to that memory, at which point an emulator programmed to accomodate the protocol would respond appropriately. By putting appropriate numbers in that memory location, the ROM would effectively give "commands" to the emulator which could totally transcend what the ROM alone could do. For example, the ROM itself could include a number of .ips-patch type databanks, and could tell the emulator, "ok, at this time, apply this patch to me". With this sort of power, imagine what you could do. The drawback would obviously be that the game would only work correctly on emulators which support the protocol. How feasible would this be? I hope this generates some discussion and thought... Anyway, thanks for reading! |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
You guys actually upload hacked ROMs back onto cartridges and play them on the original systems? Wow, I had no idea.. that is very hardcore! I wish I could come over to your house and play Super Demo World on your SNES 
How does that even work? Do you overwrite cartridges or is it possible to buy blank ones? For, say, SNES. The protocol idea is only an idea. I always play hacked ROMs on emulators and it seems to me that the idea should be to make the changes by whatever means necessary. For example lets say you want to increase the number of party members in Chrono Trigger (by which I mean, people you can choose to be in your 3 person team). Geiger insists this is "impossible", well, it's technically possible since anything is in theory possible, but doing it with just ASM hacking would probably be harder than reprogramming CT from scratch. But with a protocol like I suggested, it would suddenly be realizable. Anyway, where can I read about this uploading hacked ROMs onto actual cartridges business? That is totally awesome! |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Hey Stifu,
Thanks for those links, that really blew my mind and made my day!! How many of you guys do that, and how many just play hacked ROMs on emulator? Well, that pretty well shoots my idea full of holes. I still think it'd be cool to use the emulator's power to go beyond 255 kinds of items on FF3, or even mix games entirely (put a mario kart level in SMW), but not that much point if alot of people play using the actual hardware. Ah well, thanks for enlightening me. I know a guy who would really love one of these copier things for his birthday |
|||
|
Legendre Micro-Goomba  Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Here is a hypothetical example of something you could do by "thinking outside the ROM". Battle mode on Final Fantasy III. Fight your friends over the internet using your characters from the actual game (so this would be contained within the game proper, maybe at the Colloseum).
You could do this by creating a powerful protocol in an open source emulator like zsnes, or you could program FF3 entirely from first principles, which would take years no matter how good you are (after all, it's not like Squaresoft had one single person create it in the first place, and you have an even harder job since you want to duplicate it exactly). If you took the former option and created the protocol, it would still not be a one-sitting job, but it would be handleable, and when you were done, you could very easily apply it to other games. Doing this with pure ASM hacking would be a task of Herculean proportions. I'm not trying to argue everyone should start work on a protocol, I still concede you guys did a great job of showing me the light I'm just trying to say there can be a middle ground between changing box types in SMW and programming an original, SNES quality game from thin air.. |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| You've caught me red-handed about ASM experience, I have relatively little. I do have over a decade's experience in higher level languages, so that probably biases me in favor of an outside approach. Am I really THAT far deluded about ASM difficulty? I see people put SM3 bricks and icy fireballs into SMW and I am highly impressed, because it was done all in ASM with no sourcecode, but you seem to be trivializing this.
I'm honestly not trying to be a smartass, just trying to get clarification. Are you saying major surgical ROM changes, like adding a 2 player vs. mode to FF3, are doable in practice with pure ASM? (Bear in mind that FF3 actually has a very little-known 2 player feature, but it isn't vs. mode, rather it lets P2 control one half of the party-- so making a vs. mode would involve dealing with this too, either ripping it out completely or disabling it during the vs. mode) Originally posted by Disch Sorry, I think I gave the wrong impression in an attempt to keep things brief. I'm not talking about a protocol which is specifically shaped around FF3 but one with enough generic power to allow the following sort of scheme: - When certain battle is about to start, and the ROM communicates a command to the emulator, the emulator quickly applies an .ips-type chunk of data imbedded in the ROM, which changes the enemy monster's graphics to make it look like the formation controlled by the human opponent. At this point also the monster is set to have no AI attacks. - Similar event on the other side of the connection. Thus, behind the scenes, each human player's ROM treats that human as the party and the other human as a monster. - As each player enters commands, the commands are communicated between emulators and the emulators respond according to instructions contained in a high level script imbedded in the ROM. This script causes the "monster" (ie the enemy human's formation) to do the appropriate attack. This scheme has nothing specific about FF3. It needs: 1. A way for the ROM to tell the Emu to apply a patch in realtime; 2. A way for emulators to communicate; 3. A generic script language with enough power over the ROM to get monsters to perform given attacks. Once the protocol had the above 3 features, the rough "scheme" would easily generalize across games. All this machinery would be a little time consuming to do, but not overwhelmingly difficult. It seems to me that accomplishing the same sort of things for a single game in raw ASM would be far, far harder by contrast. But, like you point out, I am not a master of ASM
One thing I am having trouble understanding is, if ASM really is as easy as you are saying, how come most ROMHacks, codewise, are fairly minor? Not counting graphics/text/level editing, they usually only have small actual engine modifications. I'm not trying to trivialize all the great work everyone's done (which, let me say, really is impressive!!!), I'm just trying to reconcile your claims that major surgical changes to specific games in raw ASM are easier than creating a generic protocol in sourcecode. Please forgive me for making this post so long |
|||
|
Legendre Micro-Goomba  Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Hello again everybody,
How difficult would it be, assuming all unused RAM in a game were pinned down, to hack in a rudimentary memory allocation routine? Then SMW hackers, for instance, could agree on a specific block of unused RAM in SMW to hold a pointer table, and would jump to the memory allocation routine to populate the pointer table with pointers to however much RAM they need. This would be pretty inefficient RAMwise since the allocation routine itself would have to use extra amounts of RAM to store a linked list of blocks which have been allocated. However it would eliminate some of the problems discussed in this thread. I imagine such a routine would be pretty difficult in raw ASM, especially since the free RAM is not nicely organized in one big chunk. But, just thought I'd share the idea... you guys are awesome |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Ah, excellent points raised all around.
Hmm, on SNES lots of games use save files... and some don't, or (in the case of SMW) the savefiles can't conceivably consist of much more than a few stats and a checklist of levels completed. Would it be possible, in games like this, to actually use the savefile space as a sort of virtual RAM? I imagine this would raise speed issues on a physical machine (would those evaporate on an emu?) Thanks for the kind words Disch, and btw, sorry about the confusing remark about "this thread", I meant to post the message as a reply to the thread where people were talking about exactly the problem HyperMackerel described. |
|||
|
Legendre Micro-Goomba  Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Ah, very illuminating. I think this sort of thing should be studied by all serious coders just because it really opens your eyes to things you take for granted. I'm very impressed, for example, by these tales of desperate heroic acts of RAM usage by NES developers.
Well, continuing to use SMW as an example. Assuming you are willing to sacrifice two of the three save slots, you could disable them (so the game just has one save slot) and bang, lots of RAM freed up. Do games with savefiles usually use compression of any sort when saving the game? Heh, wouldn't that be novel, incorporate 7z algorithms into games designed over a decade before 7z
Thanks again for all the great responses you guys give a newb like me! |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
Originally posted by Disch Assuming by "any ROM" you mean "any ROM on a fixed system", why is a generic disassembler so hard? In my naive and newbieish mind it seems the hardest thing would be mapping the ROM, dividing it into code and data. Is this anywhere near the truth? |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
Originally posted by HyperMackerel Hey HyperMackerel Thank you for posting this, I found this really interesting. I love this board to death, new eye openers every day
The reason I'm replying is to ask: is there a similar explanation for the awkward pauses when you stomp on the big switches in the colored block switch palaces? I always wondered what was up with that! |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Here's a cool idea. I'll use specific RPGs but it would easily generalize. Take FF6 and first do a simple graphics/text hack to change some arbitrary 5 party members into the crew from FF4. Now here's the cool part: set it up so those 5 can somehow go from one ROM to the other, that is to say, you can level them up on FF4 and then transfer the levels to FF6, etc. Of course, game-exclusive features like espers or certain spells/items wouldn't transfer (well, they could, but that would involve a ton more work).
Now the main point is, would this be at all possible with real hardware? Well, there is one way, and that is to have the user manually enter sequences, like the way "saving" works in Mega Man X. But of course this is impractical if any significant amount of data is to be transferred (the string would have to be even longer than the amount of info it represents, encoded using a code with high error detecting capability if you wanted to prevent players from randomly entering nonsense). Of course with systems like PSX games like this already exist (eg FF7 with its 3 CDs) but is there any way to do something similar for systems like SNES and NES besides having the player manually enter sequences? |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6582 days Last view: 6582 days |
| ||
| Wow, thank you for the responses, especially the link d4s provided!! You guys rock hardcore!
Passwords with lots of info would be impractical for human players to use to transfer massive savefiles between games. However, impracticality aside, it would be possible in theory to do this using real machinery. Now here is a thought: set up the emulator so it can (optionally) detect when a game tells the human player, "write this password down and enter it in the next cartridge to continue your game", and at that point, the emulator does all the work, recording the password, loading the next ROM and entering the password. This could even be done silently so to the player it seems as if the ROMs are seamlessly one single game. This would allow, for example, putting a mario kart level in SMW. And it would not be "using the emulator to do things that transcend the SNES" (which many people have presented extremely well-thought out arguments against). Indeed you could still dump these hacked ROMs and play them on a real SNES, the only drawback would be you'd have to manually do the passwords when the game calls for them. To get it so emulators could detect the password system, some kind of signal could be used which would not effect the physical SNES. For instance, the very bottom line of pixels (which is sometimes hidden below the viewable screen on some TVs) could contain a specific pattern which an emulator could gleam data from but which would look like ambient nonsense to the human eye (or, by using pixels of almost identical color, would go almost unnoticed). The advantage to this would be that the ROM would not actually be cheating and outright talking with the emulator, it would just be giving subtle hints, and if emu writers decided on their own to support the "protocol", that would be their business
Of course, this is all ivory tower mumbo jumbo since the amount of effort to actually implement any of this would be of superheroic proportions... |
| Acmlm's Board - I3 Archive - - Posts by Legendre |
