It is currently Thu Nov 22, 2018 3:23 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Tue Sep 11, 2018 7:00 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7730
Location: Seattle
nocash wrote:
About racermate, using 74xx logic powered by battery... is that good for battery lifetime? Or is it only powering the transistor part from battery?
If it were actual TTL ICs, it'd be bad. But 74HC's quiescent current is pretty small, comparable to the SRAMs'.

(On Racermate, it's the 74HCT74 and one of the two 74HCT32. The other logic ICs are powered by +5V )


Top
 Profile  
 
PostPosted: Thu Sep 27, 2018 6:25 pm 
Offline

Joined: Fri Jun 24, 2016 4:20 pm
Posts: 19
So, sorry to anyone who was on the edge of their seat waiting to see my schematic (nobody) but for completeness's sake, here's my circuit:
Attachment:
battery_sram.png
battery_sram.png [ 5.57 KiB | Viewed 1182 times ]

(And for those reading this in the year 2025 with dead links everywhere...)

I'm using the 62256 SRAM chip (256K). The SRAM VCC (pin 28) is supplied via two diodes, one connected from the battery, the other connected from VCC on the board. When the game is on, board VCC takes over powering the SRAM, and when it is off, the battery will supply the SRAM power. There is a pullup resistor from the /CE pin on the SRAM (pin 20) in order to keep the pin from floating while the board is off - this ensures that whenever the board is off, the SRAM chip is not operating and will not erroneously write values to the memory addresses.

And it works! Time will tell of its robustness, but I used this really simple circuit to save on a 64K game and it worked fine even after a few power cycles. The fact that it's so simple bothers me - I don't know why Nintendo wouldn't have used it, or something similar. Oh well!


Top
 Profile  
 
PostPosted: Thu Sep 27, 2018 8:02 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7730
Location: Seattle
Check the voltage on /CE_SRAM while it's in the console and the console is off.


Top
 Profile  
 
PostPosted: Thu Sep 27, 2018 8:15 pm 
Offline

Joined: Fri Jun 24, 2016 4:20 pm
Posts: 19
I read 3.1V. This is also on the VCC pin.

3.3V from the battery, minus a diode drop

According to the datasheet, the minimum VCC for data retention is 2VDC. So plenty of headroom! I just tried it again after letting it sit for two hours out of the console - still has the save data (not that I didn't expect it to)


Top
 Profile  
 
PostPosted: Thu Sep 27, 2018 8:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7730
Location: Seattle
I mean, the thing I'd worry about it something dragging SRAM_CE low, and causing excess power dissipation or maybe random data loss. If the relevant part that drove /CE_SRAM had ordinary overvoltage protection diodes, that would tank the idea. (But evidently that's not true here)


Top
 Profile  
 
PostPosted: Thu Sep 27, 2018 8:55 pm 
Offline

Joined: Fri Jun 24, 2016 4:20 pm
Posts: 19
I gotcha! I always figured it was open-collector


Top
 Profile  
 
PostPosted: Fri Sep 28, 2018 11:58 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 707
poorstudenthobbyist wrote:
So, sorry to anyone who was on the edge of their seat waiting to see my schematic (nobody) but for completeness's sake, here's my circuit...

The circuit pulls /CE high to protect SRAM... I guess you must also have something (=address decoder) that pulls /CE low when needed?

poorstudenthobbyist wrote:
I used this really simple circuit to save on a 64K game and it worked fine even after a few power cycles. The fact that it's so simple bothers me - I don't know why Nintendo wouldn't have used it, or something similar. Oh well!

A few power cycles sounds as if it could require a bit more testing. And does the game verify SRAM checksums to ensure that all bytes are still intact, or did it just "seemed to work" despite of several potentionally corrupted bytes?

I am no expert for analog stuff at all, just some vague ideas...

Could there be some current leaking from /CE towards address decoder? For example, if the SRAM takes 1uA in standby (or so), and the address decoder leaks another 1uA then you would drain the battery twice as fast as needed. You could try to measure power consumption with/without address decoder connected - though multimeters might lack accuracy for such small currents.

Diode reverse current leaking: 1N4148 datasheet says 25nA at 20V (=supposedly even less nA's at 3V), so I guess that isn't much of a problem, even when using cheap diodes. Or would it be recommended to use battery-friendly diodes in such circuits?

Looking at cart edge connectors for cartridges for different consoles, the supply pins are often a bit longer than other pins. I guess that's supposed to give clean power up/down on hotplugging, maybe specifically related to carts with SRAMs.
Some SNES carts can be ejected while powered (and power-switch get's move to OFF position, during ejection, not sure what happens first: losing cart edge contact, or losing power, but I guess there'll be some signal spikes, especially if the cart edge contacts are a bit dirty).

The professional battery controllers are also handling SNES./RESET and check if SNES.VCC drops below 3V (and disable SRAM access in such cases). Nintendo seems to have considered that required, and they've probably considered millions of users playing hundreds of games - and wanted to avoid angry customers reporting lost game positions after several months of playtime.

Apart from hardware:
If your SRAM is large enough: You could store the game position twice (with checksums) and use 2nd copy if the 1st copy got corrupted.
Theoretically, ECC error correction might also help, but that's probably too difficult (you'd more likely find that in CDROMs or dotcodes, not in SNES games).


Top
 Profile  
 
PostPosted: Fri Sep 28, 2018 5:54 pm 
Offline

Joined: Fri Jun 24, 2016 4:20 pm
Posts: 19
I work with analog electronics on a daily basis for my job, so I think I can answer some of your questions. I'm no expert, but I do have experience in the field :)

Quote:
The circuit pulls /CE high to protect SRAM... I guess you must also have something (=address decoder) that pulls /CE low when needed?


Yep, I'm using a 139 decoder, just like boards without the MAD decoder. Verified the wiring with the manual, should be addressing the RAM correctly.

Quote:
A few power cycles sounds as if it could require a bit more testing. And does the game verify SRAM checksums to ensure that all bytes are still intact, or did it just "seemed to work" despite of several potentionally corrupted bytes?


I loaded up Super Mario All-Stars and played a few levels, and saved. Turned it off, let it sit for a few hours, then put it back in and loaded the levels just fine. That was yesterday - tried again today, and still worked! It's still plausible that this won't work perfectly and something gets corrupted in the future, but I can't really see how that would happen.

Quote:
Could there be some current leaking from /CE towards address decoder? For example, if the SRAM takes 1uA in standby (or so), and the address decoder leaks another 1uA then you would drain the battery twice as fast as needed. You could try to measure power consumption with/without address decoder connected - though multimeters might lack accuracy for such small currents.


So I don't see anything on the decoder datasheet that would indicate a leakage, but there might be a tiny bit. I'm pretty sure the decoder outputs are open-collector, so they act as if they're disconnected when they are not powered on (they're transistors internally). And you're right, at least my multimeter wouldn't be accurate enough to figure that out!

Quote:
Diode reverse current leaking: 1N4148 datasheet says 25nA at 20V (=supposedly even less nA's at 3V), so I guess that isn't much of a problem, even when using cheap diodes. Or would it be recommended to use battery-friendly diodes in such circuits?


I'm using 1N914s. The reverse leakage is only when you're biasing the diodes backwards, i.e. when you apply a higher voltage on the cathode than the anode, so I don't think that's applicable here. The only time this applies is when the SNES is on, there might be some minor leakage into the battery, but nothing serious enough to damage it. The current we have to worry about is the standby current of the SRAM chip, which I can't really control anyway.

Quote:
Looking at cart edge connectors for cartridges for different consoles, the supply pins are often a bit longer than other pins. I guess that's supposed to give clean power up/down on hotplugging, maybe specifically related to carts with SRAMs.
Some SNES carts can be ejected while powered (and power-switch get's move to OFF position, during ejection, not sure what happens first: losing cart edge contact, or losing power, but I guess there'll be some signal spikes, especially if the cart edge contacts are a bit dirty).

The professional battery controllers are also handling SNES./RESET and check if SNES.VCC drops below 3V (and disable SRAM access in such cases). Nintendo seems to have considered that required, and they've probably considered millions of users playing hundreds of games - and wanted to avoid angry customers reporting lost game positions after several months of playtime.


This is what I suspect they use the transistor for. I figure that some voltage spikes might be enough to kill the chip, but then again, they didn't really implement this on the NES and I don't see why the SNES would be more susceptible to game erasure than NES games. And if you have a big enough cap across the VCC pin on the SRAM, that should be enough to let it ride out any kind of transient voltage spikes.

Quote:
If your SRAM is large enough: You could store the game position twice (with checksums) and use 2nd copy if the 1st copy got corrupted.
Theoretically, ECC error correction might also help, but that's probably too difficult (you'd more likely find that in CDROMs or dotcodes, not in SNES games).


Hahaha well that never crossed my mind, but it definitely could be done. That'd be a decent amount of work though. And I'm trying to use these in a "universal" board that can handle all SRAM sizes. But those are good ideas, definitely.

The fact that the circuit is pretty simplistic led me to ask why I didn't really see it anywhere else online. I'll update this thread if I ever run into any problems.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2018 6:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7730
Location: Seattle
poorstudenthobbyist wrote:
So I don't see anything on the decoder datasheet that would indicate a leakage, but there might be a tiny bit. I'm pretty sure the decoder outputs are open-collector, so they act as if they're disconnected when they are not powered on (they're transistors internally). And you're right, at least my multimeter wouldn't be accurate enough to figure that out!
74'139s are definitely totem-pole outputs, both driven high and low. Almost no 74xx parts are open collector/drain; those that are are explicitly called as such.

HOWEVER, and I only discovered this recently, some parts are explicitly designed without a overvoltage protection diode on their outputs. For exactly this reason, I suppose.

Quote:
I don't see why the SNES would be more susceptible to game erasure than NES games.
Because they had people call and complain during the NES's commercial life and fixed it for the SNES, perhaps?


Top
 Profile  
 
PostPosted: Fri Sep 28, 2018 6:35 pm 
Offline

Joined: Fri Jun 24, 2016 4:20 pm
Posts: 19
Yeah now that I think about it, they must be totem-pole, otherwise it wouldn't be able to provide any kind of output current. Thanks for the correction :)

I remember reading somewhere, and I don't know where nor do I know the accuracy, that NES games underwent a redesign at some point that fixed a lot of save corruption problems, and that's why the later versions of games didn't have the "hold reset button while saving" warning. No idea if this is accurate or not, I haven't even looked at an NES board in like two years now to be honest haha

I will say I've never had any NES game lose save data or get corrupted, and I've played NES games a whoooole lot throughout my life. Anecdotal, of course, but still.


Top
 Profile  
 
PostPosted: Fri Sep 28, 2018 7:35 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 707
Reverse battery current leaking will occur on your D2 diode when powered off. It's leaking into your ROM/CIC, and, if plugged into the console, also leaking into CPU/PPU/etc. Though it might be only a few nano-amperes.

As far as I remember, NES Maniac Mansion did prompt the user to hold down the Reset button during power off. Later NES mappers did have SRAM write-protection functions via I/O ports to prevent SRAM corruption.

One reason for data corruption is that the CPU may run unstable during power down, and could fire writes to random memory addresses. That should occur on SNES, too. Or well, unless the power-up reset circuit in the SNES should happen to be designed to also work as power-down reset(?)

Uh, sorry, spikes may have been the wrong word. I didn't mean dangerous voltage spikes, bat rather simple dirt effects occuring if a data/address pin loses contact for a short moment when/while mechanically ejecting the cartridge.

PS. I didn't want to rule out that your multimeter can't see leaks, better give it a try - if it's showing several milli-amperes in standby then you have some major leak somewhere : )


Top
 Profile  
 
PostPosted: Fri Sep 28, 2018 7:58 pm 
Offline

Joined: Fri Jun 24, 2016 4:20 pm
Posts: 19
Quote:
Reverse battery current leaking will occur on your D2 diode when powered off. It's leaking into your ROM/CIC, and, if plugged into the console, also leaking into CPU/PPU/etc. Though it might be only a few nano-amperes.


Haaaa yeah was thinking of the other diode. I don't think it's too big of an issue though. Datasheet appears to claim around 3nA leakage.

Quote:
As far as I remember, NES Maniac Mansion did prompt the user to hold down the Reset button during power off. Later NES mappers did have SRAM write-protection functions via I/O ports to prevent SRAM corruption.

One reason for data corruption is that the CPU may run unstable during power down, and could fire writes to random memory addresses. That should occur on SNES, too. Or well, unless the power-up reset circuit in the SNES should happen to be designed to also work as power-down reset(?)


Hmmm ok that might be something to check out then. I think I had a Zelda cart that told me to hold the reset button down.

Quote:
Uh, sorry, spikes may have been the wrong word. I didn't mean dangerous voltage spikes, bat rather simple dirt effects occuring if a data/address pin loses contact for a short moment when/while mechanically ejecting the cartridge.


I knew what you meant! I used wrong verbiage - I didn't mean "kill the chip" as in cause it to stop working, but more like briefly "kill" the power line, or the data stored on it.

I actually forgot - I recently bought an oscilloscope. I'll check the current running through the 220 ohm resistor I put in line with the battery to determine how much power is being dissipated. Should be a bit more accurate than my crappy decade-old Radio Shack multimeter :P


Top
 Profile  
 
PostPosted: Sat Sep 29, 2018 5:53 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20794
Location: NE Indiana, USA (NTSC)
nocash wrote:
Later NES mappers did have SRAM write-protection functions via I/O ports to prevent SRAM corruption.

Which isn't very helpful if part of the SRAM is used for saves and part used for extending the 2K of work RAM. One difference on the Super NES is that it has enough work RAM in the Control Deck that games not using a coprocessor can do without extending it.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: 93143 and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group