Transferring data from Cart->Cart?

[3gengames]

Not sure how to ask this, but would it be possible to take data from SRAM and save it on either a expansion port device or something of that nature?


I didn't do too much reading, but by looking at what the Expansion port has to offer, it seems that it's not capable of holding extra RAM on it, and making a game-genie like device with 8K of SRAM might work but am not completely sure.


I was just wondering if anything like this would be possible for Game cart->Game Cart transfer.


Also, if possible, I'd like to only have one NES do it, as transferring data from 2 carts on 2 systems and 2 TV's would just be too much it seems. :/

[tepples]

Not sure how to ask this, but would it be possible to take data from SRAM and save it on either a expansion port device or something of that nature?

First you'd have to have something that boots the NES. As far as I know, the NES won't boot from anything but the Game Pak slot.

making a game-genie like device with 8K of SRAM might work but am not completely sure.

I seem to remember the first Action Replay had this feature.

I was just wondering if anything like this would be possible for Game cart->Game Cart transfer.

Do you mean something for use with existing commercial games, or just for use with your own homebrew game?

Also, if possible, I'd like to only have one NES do it, as transferring data from 2 carts on 2 systems and 2 TV's would just be too much it seems. :/

Yet most PC games require multiple PCs and multiple TVs just for multiplayer.

[3gengames]

Yeah, basically I want to Have a Cart->Cart transfer with one system. I'd like for the RAM the data goes to to be back up....

And that is right, the action reply does do that, but wouldn't that require some extra hardware? The cart its self will have 8K of SRAM, too, so I am not sure if that would affect making something like this.


And I really would like it to be SRAM backuped because I'd be paranoid if the a freak accident happened and then the next thing you know your data is gone.....I know I've thought of the CART->NES then put the data on the NES then insert another cart, but if the connection isn't good then it's going to lose the data or something might happen.


And as for booting, it would boot from the game pak, but there would be 8K of SRAM on the expansion port that it would use to save data on top of, But is that possible?


Edit:

Also, it would be for a homebrew game....I am pondering ideas for stuff after I finally get back into it. XD School starts and programming time drops to nearly 0. :/

[tepples]

So you want an external memory card that your own game can read and write, so that players can trade doodles or pokeymans or whatever between Game Paks. There are two ways to do this: either an I2C flash connected to the expansion port, or an I2C flash inside a dongle on controller port 2.

[3gengames]

Best bet: an I2C flash connected to the expansion port.

And....what are the options to size? Any programming difficulties or complications added to it? And it would be serial right?


How would something be hooked to the expansion port anyway? It seems there's no Address lines to it from some online pictures. :/


EDIT:

Now that one connected to the P2 port seems more of a good idea....but yet, at the bottom of the expansion port and you could have 2 controllers hooked up. -goes back to reading up on I2C-

[tepples]

Dang, you're fast.

Yes, I2C is a serial connection.

Ideally, your cart does the address decoding and puts the enable signal on one of the lines from the center of the 72-pin connector to the expansion port But if you go the expansion port route, you forgo compatibility with the Famicom and the top-loading NES.

[3gengames]

Dang, you're fast.

Yes, I2C is a serial connection.

Ideally, your cart does the address decoding and puts the enable signal on one of the lines from the center of the 72-pin connector to the expansion port But if you go the expansion port route, you forgo compatibility with the Famicom and the top-loading NES.

Haha thanks.


Okay well....hmm.....this is deffinently something to think about. I think Famicom won't be needed and Toploading would be nice since they're a little more popular, but toasters are just EVERYWHERE, and the only things I have.

Yet the 2 player thing would be smaller, easier to make, but then then the P2 port would be taken up. Would removing the device cause any type of data loss or chip damage? I've never done serial stuff so this also kinda of scares me....

Also, I am thinking of doing this for the Pokemon project I have planned next, no promises, but this would be a necessity and I would even love to find other things to make any other games more interactive.


EDIT:

Also, the extra pin on the cart.....I was thinking of using a MMC1 and 512K rom and a 8K CHR-RAM with 8K of SRAM if this happens. I doubt there would be anymore hardware on the cart left over for such a thing so it might be better to go the P2 port->Serial Flash ROM. Wow, I can't believe I never thought of that as an option! -facepalm- You guys know all the good tricks. XD

[Memblers]

Actually, you won't lose Famicom compatibility if you do it right (through $4017, mostly - and it won't interfere with the controllers). Toploader support is a lost cause, sadly, but isn't nearly as common as the old front-loader anyways. The expansion device I'm working on should work on NES or Famicom. And yeah you'll be able to save and load data from there, I'm planning on having it provide more non-volatile storage than anyone would ever want, heheh.

You can get a large serial flashrom, say 4Mbytes, for just a few bucks. Cheap!

If you want to copy your SRAM data off of a cart, for backup and restore, you can do it today if you use a CopyNES.

[3gengames]

Actually, you won't lose Famicom compatibility if you do it right (through $4017, mostly - and it won't interfere with the controllers). Toploader support is a lost cause, sadly, but isn't nearly as common as the old front-loader anyways. The expansion device I'm working on should work on NES or Famicom. And yeah you'll be able to save and load data from there, I'm planning on having it provide more non-volatile storage than anyone would ever want, heheh.

You can get a large serial flashrom, say 4Mbytes, for just a few bucks. Cheap!

If you want to copy your SRAM data off of a cart, for backup and restore, you can do it today if you use a CopyNES.

Thats cool! Yeah well I am liking the P2 controller port idea, the device its self would be more portable and I don't wanna break the plastic peace off the console....I'd feel like I'm destroying it!

And thats great....I hope small ones are cheap! lol.


So basically, all you would have to do is hook up data pin to the P2 controller port and then ust send data to it? No worries about it being unplugged when the console is on is there?


Edit:

Well I want to make a trade-em game pokemon like and want to make sure I can do something like that safely between carts. And that P2 port serial device seems like an EPIC thing to have, so you can carry your Pokemon in it, like the little tiny Pokeball thing for DS.


One down side....If I start this project.....There's going to be ALOT of cart testing and ROM burning, since Emulators probably don't have something like this implemented...yet.

[Xious]

With the 2nd controller port, you'll almost perpetually have access to $4017's D3 and D4 registers. The d0 register is used by the 2nd controller, so although you can utilize it, you'll need to ensure that when reading or writing to your external memory device, you disable all external D0 input to avoid corruption.

(I expect that you will permit pass-through of the signals required to operate the 2nd player controller.) I dot remember if the NES 2nd port has /OE for both $4017 ans $4016, but it may. I can't remember the singular remaining line's allocation (+5DVC, GND, $4017.OE, $4017.0, $4017.3, $4017.4 and...one more. (I think it's a data write line for the Latch signal?)

If you're making your own game, and your own carts, may I suggest adding an external memory device to it for SD storage? You could interface it directly with the internal SRAM, and allow for nonvolatile storage of game data. This way, you have a fully integrated, software-controlled storage medium directly on your cartridges, which would be much easier to use for the exchange of game data and wouldn't require extra dongles that people have to constantly swap out.

-Xious

[tepples]

I dot remember if the NES 2nd port has /OE for both $4017 ans $4016, but it may. I can't remember the singular remaining line's allocation (+5DVC, GND, $4017.OE, $4017.0, $4017.3, $4017.4 and...one more. (I think it's a data write line for the Latch signal?)

The last one is the strobe signal, which has to be used for data out as well.

If you're making your own game, and your own carts, may I suggest adding an external memory device to it for SD storage?

That would require implementing FAT16 and FAT32 with write support and possibly even create and delete support.

[Xious]

If you're making your own game, and your own carts, may I suggest adding an external memory device to it for SD storage?

That would require implementing FAT16 and FAT32 with write support and possibly even create and delete support.[/quote]

How hard would that be to do with SD/MMC controllers? I mean, if you are creating a custom software routine to write SRAM data to $4017, would it be much harder to do it to an MMC/SD controller on the cart?

Even if you do it through the controller port, if you wanted to share the data on the Internet, rather than just locally, you'd need some way of reading it off the device to a PC, so some kind of filesystem handling is probably needed to easily interface it, right?

Otherwise, I think that you'd need to implement it as a USB device with a specialized driver or software to read the data in the device on th3 PC-side,. in addition to the software to pipe the data to the device int he first place. (Memblers is working on something along those lines already, as he mentioned for the NES EXS slot, but that has a full array of connections not present on the controller port that can assist.)

Am I correct about signal interrupt handling and possible interference if a SW-controlled device on $4017 shares a data path with a controller (or something like the 4Score) that is using the data lines at $4017, or are my worries unjustified?

-Xious

[3gengames]

Well I was thinking if we had a dongle to go the P2 port or Exp. port that it would be easier to swap stuff. If we made the NV storage on the cart, tranferring would have to be done by ram and I wouldn't trust that at all because if you inserted the cart you wanted to transfer it to, it might fail and youd never know it.


But with the NV storage on lets say the P2 port, You'd send items or whatever to it, turn off the system, insert your friends cart, then give him the items on the dongle. It seems more safe to me, am I right?


And then you could always do Serial RAM on the cart, but then the 8K of extra RAM would not be usable by the system so I think thats out.


And by the looks of online, the serial chips require 2 pins. Could D3 be used by the devices that if D3=1 then memory dongle was being read, where if D3=0 then then Controller is hooked up to D0 instead?

[tepples]

That would require implementing FAT16 and FAT32 with write support and possibly even create and delete support.

How hard would that be to do with SD/MMC controllers? I mean, if you are creating a custom software routine to write SRAM data to $4017, would it be much harder to do it to an MMC/SD controller on the cart?

A small-capacity memory card has a special-purpose file system, possibly with no support for subdirectories or fragmented files. (Case in point: PlayStation 1 memory cards. Each file happens to be exactly the size of the 6264 SRAM found in NES games, minus 256 bytes for a header and favicon.) An SD card, on the other hand, has a much more complex general-purpose file system. And Microsoft even claims patents on the FAT file system that won't expire until around 2015, twenty years after the introduction of Windows 95. Besides, if you include a peripheral on the game itself, like on an Aladdin Deck Enhancer or a Super Game Boy, you can't share the peripheral among several games.

Even if you do it through the controller port, if you wanted to share the data on the Internet, rather than just locally, you'd need some way of reading it off the device to a PC

I'm guessing it would be easier for a C program to understand a special-purpose file system than for an 8-bit asm driver on an NES to understand FAT16 and FAT32. Even the PowerPak BIOS doesn't have create/delete/resize support.

Am I correct about signal interrupt handling and possible interference if a SW-controlled device on $4017 shares a data path with a controller (or something like the 4Score) that is using the data lines at $4017, or are my worries unjustified?

The NES controller, NES Four Score, Super NES controller, and Super NES Mouse use only D0 out (strobe), clock, and D0 in. Power Pad uses D0 out, clock, D3 in, and D4 in. But none of these assert strobe and clock at once. So the glue logic in your controller port dongle could do what the Power Glove does: watch for strobe + clock and interrupt communication with the controllers until the transaction completes, at which point it interrupts communication with the memory.

[Xious]

Here.s the problem that I see...

While your method would work for people that live close to eachother, many NES geeks live all around the world, and if you made a game based on the exchange of data, people it would be ideal to be able to share that data with friends all over the world.

How would you get the data to them? You'd need a way to interface your storage device with a PC, upload the data to a hard drive or other storage card, then e-mail it. This means creating a USB link between your dongle and a PC, which may be as complex as using an SD card on the game cartridge.

Id you want to go the route you are planning, you should investigate the Famicom 'Battle Box', which was a device for storing FC game save data after power-off for games that didn't include battery-backed RAM. I'll have to look at its schematics to see how it did it, but you can find them on-line to view yourself as well. (If you can't, PM me and I'll send them to you.)

It only worked with titles specifically designed for it, and there way no way to extract the game data from the deice externally, but you could plug it into another Famicom, which is essentially what you're talking about. The ability to save game data this way and share it is nothing new, but being able to send that data to another person or interface the NES to a PC in a manner conducive to doing so is (thus far) relatively new.

Only the PowerPak can do it, thus far. (in fact, it would be possible to create a custom mapper with a serial number and sell the game as a ROM that required a custom mapper, generate a mapper file for the PowerPak with an encrypted serial key in its source--randomly generated for each single one sold--- then track the serial numbers to prevent piracy and do this entirely on the PowerPak. Just a wild idea, probably due to lack of sleep...)

As to SD cards being frail, people trust them to gold photographs taken on vacation, and they are common and easy to replace (inexpensively). It's a simple manner to back-up whatever you have on the card and it you lose it, or it is damaged, you can replace it. If you design a device with internal memory, and it develops a fault, then not only will you still lose the game data, but you'll have to take it apart, desolder a SM memory chip and put a new on in its place.

Additionally, SD cards are pretty tough. I've only had one die. It wqs a Sandisk USB2+ folding card, and I accidentally snapped it at the folding seam when it was sticking out of a device, severing the ground connection. I recall that I lost another one that became saturated in Coca-Cola and developed corrosion, but i can always clean its contacts if I ever need to do so.

They're really tough little buggers, and as long as it's fully inserted into something, I don't see how you'd break one. (The folding card is an exception, because, well, it was hinged and I bent it the wrong way.) You may lose the card, but as long as you can plug it into a C (or Mac, or Solaris station, etc.) at the end of the day, that isn't a problem.

If all you want to do is develop a game that uses an external device to hold game SRAM data, but you don't want to share it across a network,(which will severely limit its usefulness, and your sales these days), you should essentially clone the 'Battle Box.' That's all it was, and that is all you'd need.

If you want to ensure that people can share the data on the Internet though, it will require connectability of some sort, and if you want to make it easy, it needs to be SD or USB. Anything else will limit who can use it.

Many systems today have only USB and micro-card ports, so serial is out, and if the USB controller doesn't recognize it and its data natively (using built-in or existing software drivers), then you'll need specialized software to view and extract it, which you'd have to make multi-platform (PC, Mac PPC/x86 dual-binary//Linux) in order to ensure market durability.

That's why, in my eyes, SD makes the most sense, but 'tisn't my project, so don't feel any pressure from me, unless my word that if I couldn't plug it into a Mac and share it with my mates means I wouldn't buy it is meaningful. (Just about all of my mates that play NES/FC games live a long distance--500-600Km--away from me...)

I only have three local friends that do, and they don't own the console themselves, but visit on occasion to relive past memories. I'm pretty sure this isn't too uncommon, considering the age of the console, after all.

-Xious

UPDATE: I looked at the schematic for the Battle Box, and it indeed is exactly what you need to view, as it uses the $4017 register signals available on Port II of the NES. If you improve it to add USB attachability to a PC, you can pretty much use it as-is.