 |
| 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 |
|
| | ||
| 0 users currently in ROM Hacking. |
| Acmlm's Board - I3 Archive - ROM Hacking - Transferring memory between SNES cartridges |
New poll |  |  |
| Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Legendre Micro-Goomba                Since: 04-30-06 Last post: 6567 days Last view: 6567 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? |
|||
Darkdata   980      Since: 02-25-06 From: Newfoundland Last post: 6282 days Last view: 6282 days |
| ||
| Sounds Fun ^^;;
Excuse me while I go hack pokegear into Ruby. I think that would take way to much asm to do. |
|||
Yoronosuku Toss Tortoise Since: 11-17-05 From: Massachusetts is my new home.. Last post: 6282 days Last view: 6282 days |
| ||
| What did the entire first half of your post have to do with anything Dark? .__.
The password system idea isn't so out there, Golden Sun used a very similar system to transfer characters between games. There were 3 password you could use, as I remmeber...the longest being everything from stats to items held, the shortest being only the basics. They also allowed you to use the link cable for this feature too. The problem being that the SNES/SFC has no way to interact with another unit, you would need to go the password route which would require a good amount of hacking, most likely (it actualy could be much easier than it sounds if you know what you're doing..) |
|||
d4s Shyguy  Since: 12-01-05 Last post: 6405 days Last view: 6302 days |
| ||
| what you want is the super turbo file, a device manufactured by ascii.
basically, it acts as a snes memory-card that can be connected to the controller port. some more info: http://www.gamersgraveyard.com/repository/snes/peripherals/turbofiletwin.html |
|||
|
Legendre Micro-Goomba Since: 04-30-06 Last post: 6567 days Last view: 6567 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... |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6405 days Last view: 6302 days |
| ||
| some people here seem to be obsessed with the idea of adding features to emulators that are supposed to enhance hacks, most likely because they believe that coding stuff into an emu is easier than coding some add-on stuff for a rom.
imho, this is not only impracticable (various emulators around which are advancing at a different pace, emulator authors being strictly against adding features for specific patches or stuff thats not actually possible on the real hardware, incompatiblity on real hardware, just to name a few reasons), its also highly overcomplicating things. think again: you want to have two games, you want to be able to play them sequentially and you want to be able to exchange characters between the two. here is a simple, yet effective and universally compatible solution: combine the two roms into one. code a small intro to be able to select a game, remap one of the roms to its new adress space and do your sram stats thing. however, that is still a huge amount of work and probably not feasible. dont underestimate the effort needed to do such things. |
|||
Dan Purple Leever Since: 11-18-05 Last post: 6291 days Last view: 6282 days |
| ||
| This sounds like something that could be accomplished using a savestate or SRAM editor, and a bit of ROM hacking. | |||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6283 days Last view: 6283 days |
| ||
| On a real SNES, couldn't you do it via cart swapping? Copy a routine into RAM, disable interrupts, and have the user switch cartridges. Just keep reading from the ROM area; if no cart is inserted you should probably get some odd pattern. (Just look for the game title or something that couldn't possibly come up on an open bus.) I'm not sure if the system allows this, though.
I would imagine, though, that any decent flash cart also allows for save files to be shuffled, so you could do it pretty much the same way as on an emulator, and if you built your own cart you should be able to come up with a solution. (edited by HyperMackerel on 05-10-06 11:08 PM) |
|||
|
d4s Shyguy Since: 12-01-05 Last post: 6405 days Last view: 6302 days |
| ||
Originally posted by HyperMackerel unfortunately, thats not possible with normal snes carts. when inserting a cartridge, the rom will not immediately respond correctly, but is likely to output unpredictable data until the power has stabilized. because wram and the cartridge are all connected together to the same bus, this random data on the bus will alter the code the cpu is executing, even if its fetching it from wram. i've tried hotswapping carts before with a memory viewer executed from wram, sometimes it works, sometimes it crashes the snes. most flashroms have some kind of voltage watchdog so they wont put random stuff on the bus on powerup or write data to the flashrom by accident. thats why you can hotswap satellaview flashcarts although nintendo doesnt recommend it. in general, most hotswappable devices also have longer leads for the power and ground lines on the edge connector, so the power can stabilize before the device is fully inserted. i think you can see that when you look into an SATA power connector, but i dont own such advanced stuff so i can hardly tell. :> |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6283 days Last view: 6283 days |
| ||
| Hm, would putting a switch or latch of some sort on the ROM chip's Output Enable line help that? | |||
Captain Boh Goomba Since: 04-05-06 From: Vancouver, BC Last post: 6490 days Last view: 6490 days |
| ||
| I have no idea how feasable this would be, since I really have no clue what I'm talking about, but what about this:
Have three cartidges for your two games, one that has a connector on the top like the Game Genie. The cart with the connector on top would have the SRAM that both the other carts load from. Add some extra pins on the connectors for the SRAM, make sure both games use the same file format or write to the appropeate areas in the file for the other game and make the SRAM cart pass all the rest through to the console. When you want to change games, save, power down and switch the top cart. Again, I'm not really uptodate on rom hacking or electonics, but this works in my mind. (edited by Captain Boh on 07-25-06 10:31 AM) |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6283 days Last view: 6283 days |
| ||
| Basically what you mean is to have SRAM separate from the cartridge, that can be swapped between the cartridges. It's a good idea, but actually building another whole cartridge seems like overkill. I think it'd be much easier to just build a multicart; just power off the system, flip a switch to change ROMs, and start up again. | |||
|
Captain Boh Goomba Since: 04-05-06 From: Vancouver, BC Last post: 6490 days Last view: 6490 days |
| ||
| But that makes sense...
Of course, having it as a seperate cart means you could potentally add other games to the collection. |
|||
paulguy Paragoomba Since: 06-29-06 Last post: 6296 days Last view: 6283 days |
| ||
| i dont intend to get anyone in trouble about this but 2 and a half month thread awakening... :p anyway this is still an interesting subject. As far as emulator support for this goes, just rename the SRM file and have both games use the same savegame reading and writing routines. As for hardware, the ROM switch would be pretty nifty. | |||
Imajin Bot Local Moderator Currently affected by 'No syndrome' ---!!!  Since: 12-05-05 From: Camineet, Palm Last post: 6283 days Last view: 6283 days |
| ||
| Hm, Sonic and Knuckles did something similar... | |||
Sukasa Birdo Not quite as active as before. Xkeeper supporter Xk > ||bass I IP Banned myself! Twice!  Since: 11-17-05 From: Somewhere over there Last post: 6283 days Last view: 6282 days |
| ||
| I had an idea for a oruytine that might fix the problem of garbage code: Just Add four NOP's to the end of the routine, then if the ROM sends out garbage data, the NOP's will catch it and then code can resume as desired. | |||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6283 days Last view: 6283 days |
| ||
| I don't think that's it. The ROM chip being powered up basically scrambles RAM, or at least the data on its way to the CPU. The whole purpose of having a wait loop in RAM is so you can swap cartridges (since you can't rely on the contents of ROM during this period), but if the contents of RAM are unreliable, you can't do that, which leaves you with nowhere to stick your loop.
Hm, if you were to use a STP instruction though, could a circuit on the cartridge restart the CPU? |
| Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - ROM Hacking - Transferring memory between SNES cartridges |
| |
