It is currently Sat Nov 18, 2017 4:34 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject:
PostPosted: Mon Jul 09, 2012 11:36 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
In this post about Battle Kid, Dwedit wrote:
Sivak mentioned that SRAM was expensive. I wonder how much a tiny EEPROM would have been to use?

As far as I can tell, once you're using RAM at all anywhere in the system — and for modern homebrews that's probably CHR RAM — you should just increase its size and battery-back it instead to get saving capability. The cost of the battery, diodes, resistors and capacitor to battery back a SRAM is (~10+2+2+3+1)¢ in quantity and will take 2-4 bits of bankswitching registers; the cheapest EEPROM solution I could find was (13+2+1+1)¢, I²C, 128b, and will take 2 bits out of the bankswitching register.

Incidentally, Renesas now (still?) sells a 5V 128kB SRAM at $942/1000.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 09, 2012 11:41 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5822
Location: Canada
Oh, so it's just for saving data, not as general purpose RAM. Interesting.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jul 09, 2012 12:23 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Even if you use only 8KB of battery-backed CHR-RAM without anything fancy such as bankswitching you could give up a few tiles and the space for saving data instead.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 11, 2012 5:09 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
tokumaru wrote:
Even if you use only 8KB of battery-backed CHR-RAM without anything fancy such as bankswitching you could give up a few tiles and the space for saving data instead.


Yeah, and he probably only needs 1 tile, 2 max. 1 tile is 16 bytes which should be more than enough for his game. Don't have to remember much.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 11, 2012 6:20 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Yeah, 2 tiles should be enough for most games that are not RPGs or any kind of detailed world simulation.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 11, 2012 6:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19226
Location: NE Indiana, USA (NTSC)
True, one tile is worth about four 8-character passwords. But given what I've seen in Shiru's init code and even some of my own code,* the problem with putting tiles and saves in the same bank of CHR RAM is the possibility of a bug in the VRAM loading routines causing loss of saves. One might solve that by using a 62256 and switching to the bank with the saves only when loading or saving, much like how SOROM and ETROM have a separate chip for the saves, or SXROM and EWROM have four banks.


* Concentration Room 0.02 palette updates may overwrite VRAM on the first frame of a game due to the address increment being set at the wrong point in the subroutine.


Last edited by tepples on Wed Jul 11, 2012 7:04 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 11, 2012 7:02 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
I don't see how bad programming can be used as excuse not to do something. That's pretty disgusting if you're that terrible of a programmer you shouldn't be programming anything.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 11, 2012 11:00 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
3gengames wrote:
I don't see how bad programming can be used as excuse not to do something.

I have to agree with this. It's like saying "you can't jump in my game because my jump physics are crap". If there's a bug with your VRAM routines, fix them. The complexity and cost of adding another chip is hardly a good alternative to actually fixing bugs.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 11, 2012 1:16 pm 
Offline

Joined: Wed Feb 17, 2010 5:42 pm
Posts: 359
Location: Denine's Devil Mansion
3gengames wrote:
I don't see how bad programming can be used as excuse not to do something.

I agree. If something is invalid, improve and fix it.
Quote:
if you're that terrible of a programmer you shouldn't be programming anything.

I Disagree. The greatest failure is when you don't try at all.
If you are bad programmer, just improve, lern new techniques, make some demos "for yourself only" and then try again. Just don't give up saying "I'm just born as bad programmer".
Remember MOE?.
I spent about a year to improve my skill so(for example)map isn't read form $2007(MOE does that) for collision. I don't need to turn rendering off at bottom of screen to update on screen tiles(because of badly written NMI).
ETC.
By looking at MOE one might say. "Please DON'T make anything anymore, it'll suck anyway." But I improved, and in new game(currently waiting for Hardware tests) coding part is better.
Even worst programmer can improve if he really wants it.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 19, 2012 11:50 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3482
Location: Indianapolis
lidnariq wrote:
In this post about Battle Kid, Dwedit wrote:
Sivak mentioned that SRAM was expensive. I wonder how much a tiny EEPROM would have been to use?

As far as I can tell, once you're using RAM at all anywhere in the system — and for modern homebrews that's probably CHR RAM — you should just increase its size and battery-back it instead to get saving capability.


I think it's worth noting that while SRAM standby power consumption is generally low, it does vary. On the (admittidly, older) chips I've looked at previously, the part number will have an L for low power, and LL for extra low power (this is what you'd want for battery backup, ideally). Throwing any random SRAM on there, the battery might not last as long as one would hope. So, it's possible one would be paying a higher price for SRAM, if they wanted the longest battery life.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 20, 2012 10:15 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
For this and other purposes, I have idea to make an extended .NES format where there is one mapper number assigned to make a custom defined mapper, including zero or more audio expansions, ROM, RAM, disk, nametables, mirroring, and whatever else. I can try to make a better idea and we can work together too, in another thread, to figure this out.

_________________
.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 20, 2012 12:07 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
Memblers wrote:
I think it's worth noting that while SRAM standby power consumption is generally low, it does vary. On the (admittidly, older) chips I've looked at previously, the part number will have an L for low power, and LL for extra low power (this is what you'd want for battery backup, ideally). Throwing any random SRAM on there, the battery might not last as long as one would hope. So, it's possible one would be paying a higher price for SRAM, if they wanted the longest battery life.
Good reminder; currently on Digikey the cheapest options are a high speed 61c256 (350uA standby, 10ns cycle time), and a "slower" 62c256 (15uA, 45ns). Fortunately they're the same cost ($112.90/100) but it is necessary to be careful and check.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 25, 2012 7:27 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19226
Location: NE Indiana, USA (NTSC)
3gengames wrote:
tepples wrote:
One might solve [the possibility of save corruption] by ... switching to the bank with the saves only when loading or saving

if you're that terrible of a programmer you shouldn't be programming anything.

We're all terrible programmers. "All have sinned and fall short of the glory of God," as Paul wrote in Romans 3:23. You and I both know this: as you pointed out to me later, you too have released imperfect software. And it's a lot harder to patch a cartridge after release than to patch, say, a downloadable Android game. On some platforms, even a downloadable game can run into problems, as Microsoft charges tens of thousands of dollars for certification of a patch to an Xbox Live Arcade game. (See the recent Slashdot story about Fez.)

So the right thing is to do one's best not to be terrible, but also to take reasonable steps to mitigate the effects of being unintentionally terrible. That's why I suggested using the extra banks in the RAM chip that one's already using to build in extra memory protection mechanisms as a layered defense. There are a lot of ways to do this, including some that involve no additional cost:
lidnariq wrote:
Renesas now (still?) sells a 5V 128kB SRAM at $942/1000.

If you have 16 banks available (128 KiB SRAM divided by 8 KiB visible to the PPU at once), and your game uses one or two, then why not store the saves in a bank that nothing else uses?

Another mitigation is to have both password and battery save within the same game. For example, after completing a chapter, a game could give the player a password to restart the game from that chapter in case a freak glitch wipes out the player's saves, although with a somewhat underpowered party. It wouldn't be much different from the "bronze password" in Golden Sun for Game Boy Advance that summarizes the stats of a completed game at a reduced level of detail so that the character could be imported to the sequel.

tokumaru wrote:
If there's a bug with your VRAM routines, fix them.

I agree that one should learn from one's mistakes. Jonah at first shied away from preaching in Nineveh but ended up learning from his sins and delivering a very powerful prophecy. Likewise, after having denied three times in one morning that he knew Jesus, Simon Peter became a strong advocate for the faith.

But one still can't fix what's already shipped. Case in point: The original Super NES console, revision 1/1/1, has a defect that freezes the CPU if a DMA copy finishes too close to an HDMA. Nintendo fixed this for the more common 2/1/3, but games still had to work around the bug in 1/1/1 by not using DMA copy at the same time as HDMA. Likewise, after 3gengames reported Concentration Room's VRAM corruption bug to me, I isolated the problem and prepared a patch to fix the defect within the hour. But it still took years to discover this problem, as it had eluded me until long after I had already shipped Concentration Room 0.02 as part of the MGC 2011 multicart. Had I planned on battery-backed CHR RAM from the start of a project, I'd probably catch such an obviously reproducible bug quickly, but a similar bug that's harder to trigger might slip past the testers and end up in the shipped product. Furthermore, defensive programming techniques that allow programs to run correctly even in unanticipated environments are especially helpful when developing for a PC or an Android device.

Besides, how would one test a game that uses this method? The only iNES mapper I know of that supports battery-backed CHR RAM (without NES 2.0 hackery that I don't believe anything really supports yet) is 168, used only for RacerMate Challenge, and that's marked "planned" on retrousb.com. That too uses two CHR RAM chips, only one of them battery-backed. Do any emulators support adding battery-backed CHR RAM to a more common board through the NES 2.0 header?

(You may have seen my avatar change a few times in the past couple weeks. If you want, I can post an explanation of my avatar images elsewhere.)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jul 25, 2012 11:45 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1919
Location: WhereverIparkIt, USA
tepples wrote:
Besides, how would one test a game that uses this method? The only iNES mapper I know of that supports battery-backed CHR RAM (without NES 2.0 hackery that I don't believe anything really supports yet) is 168, used only for RacerMate Challenge, and that's marked "planned" on retrousb.com. That too uses two CHR RAM chips, only one of them battery-backed. Do any emulators support adding battery-backed CHR RAM to a more common board through the NES 2.0 header?

(You may have seen my avatar change a few times in the past couple weeks. If you want, I can post an explanation of my avatar images elsewhere.)

Sorry for the plug but testing something like this is the main goal of the NESDEV1. Let's just hope things go as planned for the release :)

And yes I did notice the avatar changes and was curious to their meaning if you're willing to share elsewhere.

EDIT: oh, and nice to see your back Tepples :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot], Yahoo [Bot] and 4 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