#7698 - sfhuang100 - Mon Jun 23, 2003 3:52 am
Hi,
I have been searching for this answer for a long time and hope somebody can help me.
As people said, there are 3 kinds of save game type of original cart. : EEPROM, FLASH, and SRAM. The physical interface to these 3 types of hardware are different, for example, EEPROM is with serial interface and others are with parallel interface.
When these different cart. are plugged into the GBA machine, how would GBA know the way to communicate with these save-game chips ?
Thank you very much.
_________________
---
sfhuang100
#7702 - tepples - Mon Jun 23, 2003 7:17 am
A driver for the save chip is stored in the game code. Nintendo has made such drivers available to its licensed developers. That said, the homebrew community has managed to figure some things out.
I know about everything about SRAM and very little about flash or EEPROM.
SRAM is easy; it's just a 32 KB (or so, depending on save chip specifics) array of bytes, which must be addressed as bytes. There's code in the FAQ to move things in and out of SRAM; just make sure you put bytecpy() in EWRAM instead of ROM.
Flash save memory is 64 KB in 4 KB sectors; it's read like SRAM but written differently.
EEPROM is serial and either 4 Kbit or 64 Kbit in 64-bit sectors, connected to lines A23 and D0. Here's some info from GBATEK.
(EDIT: fix gbatek url)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
Last edited by tepples on Mon Jun 23, 2003 5:45 pm; edited 1 time in total
#7708 - sfhuang100 - Mon Jun 23, 2003 10:37 am
Really thanks a lot , tepples.
So does the game developer need to choose what kind of hardware of saving chip before developing the game? Or does he just only combines the driver into his game and the driver will detect the hardware automatically?
By the way, could you please type again the link to EEPROM info linked to GBATEK ?
Thank you again.
_________________
---
sfhuang100
#7712 - gb_feedback - Mon Jun 23, 2003 2:09 pm
I have never managed to get any facts out of those who know...
But here's some speculation.
EEPROM at least is quite complex to write to, using as it does \RAMCS, A23 and D0 to access the device (serially). It was at least originally something like the Xicor X84256. These take about 2ms for a write cycle, and I believe there is a library function available to official developers which handles this (possibly stealing an interrupt to do the job?).
Any commercial cartridge will have imbedded in it somewhere, a text string indicating the type of save access in use. For example a Static RAM saving game may have 'SRAM_V112' embedded.
Some people have been able to change the save type of a ROM image by a small patch, which suggests that the library function is present in most commercial games, and contains the necessary code for each save type.
The logical consequence would be that the library function is accessed in a generic way and the save processing is invisible to the official developer.
Anyone bothered by this because they are hoping for an unofficially developed game to become an official game in the future could take comfort in the knowledge that as long as they save through their own fairly generalised save function (to sram), then it could easily be replaced in the future.
Of course statistically most such games are extremely unlikely to ever get to this stage!
_________________
http://www.bookreader.co.uk/
#7720 - torne - Mon Jun 23, 2003 3:35 pm
The Nintendo backup libraries for SRAM/Flash/EEPROM have totally different interfaces - the savegame type is highly visible to the developer. Onlky the used save method is present in a commercial cart. The savegame patches used on roms work by simulating the Flash/EEPROM calls, as the SRAM functionality is a 'lowest common denominator' in terms of permitted operations. (I think, anyway; I have never examined the SRAM patchers in detail).
The patches work on any game which uses an unmodified copy of the Nintendo backup libraries; all versions in current use by licenced developers are dealt with. And not through reverse engineering, either, I'm sure. =) There are a few Flash games such as Pokemon which do not use the Nintendo backup library for various reasons, and instead interface directly with the flash memory; these have custom patches. *grin*
To be honest, the motivations for using EEPROM vs Flash vs SRAM are such that it makes little sense to present a unified interface. For example, Pokemon uses flash because it has to save a large amount of complex, highly variable data, twice over for backup purposes; but only when the user explicitly asks to save, and a delay is expected. The interface desired is therefore one of bulk data transfer; the data is kept in WRAM and is dumped out to flash in bulk when Save is selected. Whereas a game like Klonoa uses SRAM saving: the game saves transparently every time you walk from one room to the next (which is great as being able to just turn the gba off when the puzzles get frustrating does wonders..). There is relatively little data to save and few things change between saves (as all rooms reset when you leave them; only the current room and player status need be recorded), so the SRAM interface which allows direct usage of the savegame data (albeit with 8 wait states) makes sense. I confess that I'm not too familiar with the EEPROM interface, and so can't really tell you much about it (other than it has the longest lifetime of all the save types; EEPROMS can be rewritten more times than flash, and don't need batteries like SRAM).
Homebrew games are all written to use SRAM because that's all that's trivially available on most carts; some of them probably would benefit from using other save types. It all depends how 'natural' the SRAM interface seems to be.
If you're actually intending to publish a game, abstract out your savegame concept; don't just have a save function, move anything related to savegames out of your main code. This would allow you to switch between a bulk-save model a la Pokemon, or an incremental save model like Klonoa with relative ease.
Hope this helps,
Torneo
#7724 - gb_feedback - Mon Jun 23, 2003 4:02 pm
torne: thanks - nice to hear some facts at last!
_________________
http://www.bookreader.co.uk/
#7736 - Cyberman - Mon Jun 23, 2003 7:04 pm
EEPROM saves work by as said utilizing A23 and D0.
This ONLY works through the use of DMA. You cannot do an EEPROM read or save otherwise. The data bits are written to a buffer in WRAM the DMA is set up and the data is sent. The dma is monitored to find out when it's done. Reading is pretty much the same only you send a read command and then read from the DMA channel. Why is DMA neccesary? this is entirely because of the EEPROM chipselect.
FLASH/SRAM are 32KB/64KB respectively and are memory maped. Writting to this takes I believe 8 wait states (IE normal write + 8 extra bus cycles). So it's much slower. FLASH requires one to support flash erasure and writting routines which vary from manufacturer to manufacturer.
However there is another way to save games. Flash Again. This is how those cartridges (flash type) are programed in the GBA. The same address space as the ROM resides in can also be used for saving game state. (So you can have 16 mbytes of flash memory in a game if you do a LOT of saves ;) ).
All of these require different methods and program code to be able to facilitate them.
Cyb
#7862 - ampz - Fri Jun 27, 2003 3:48 am
Just to point out, EEPROM is by far the slowest savegame type, as well as the smallest. ( 512Byte / 8kByte )
The life of EEPROM is usually the same as flash memory.
The main technical advantage of EEPROM over flash is that it is not sector-based, so you don't have to erase an entire sector when you need to update one byte.
The important difference is that EEPROM is cheaper than flash.
Flash is cheaper than SRAM.
EEPROM and Flash does not have any real technical advantages over SRAM. It's really only a price difference.
Yes, SRAM has a limited life of 10 years or so due to the battery, but that's not considered much of a problem.
#7903 - Cyberman - Sat Jun 28, 2003 12:22 am
A few things EEPROM doesn't have the same erase write life cycle expectancy of flash.
Flash is normally good for 10000 cycles ERASE write they often use additional memory for errorcorrecting small corruptions getting it's endurance close to 50000 (this is normally just parity data). EEPROM can range from 100000 to 1000000 erase write endurance cycles. If per chance they are using FRAM EEPROM (little expensive but). These are good for 100000000 erase write cycles.
EEPROM is not limited to 512 (4Kbit) or 8K (64Kbit) as well.
Ones options are:
128K 256K, 512K, 1024K bit EEPROMS (16K 32K 64K 128K)
Serial flash:
512Kbit 1Mbit 2Mbit densities.
Data flash <atmel special?>
Densities available are
1M, 2M, 4M, 8M, 16M, 32M, 64M, 128M
These have extra data per sector availabel for error correction and 2 RAM buffers for fast reading and writting (20mbit/second peak rate).
Cyb
#8436 - ampz - Thu Jul 10, 2003 2:36 pm
| Cyberman wrote: |
A few things EEPROM doesn't have the same erase write life cycle expectancy of flash.
Flash is normally good for 10000 cycles ERASE write they often use additional memory for errorcorrecting small corruptions getting it's endurance close to 50000 (this is normally just parity data). EEPROM can range from 100000 to 1000000 erase write endurance cycles. If per chance they are using FRAM EEPROM (little expensive but). These are good for 100000000 erase write cycles.
EEPROM is not limited to 512 (4Kbit) or 8K (64Kbit) as well.
Ones options are:
128K 256K, 512K, 1024K bit EEPROMS (16K 32K 64K 128K)
Serial flash:
512Kbit 1Mbit 2Mbit densities.
Data flash <atmel special?>
Densities available are
1M, 2M, 4M, 8M, 16M, 32M, 64M, 128M
These have extra data per sector availabel for error correction and 2 RAM buffers for fast reading and writting (20mbit/second peak rate).
Cyb |
We were talking GBA savegame types here, and there are only 4k and 64k EEPROM carts. I'am well aware that serial EEPROM's exist in many different configurations.
The ones you pointed out are not "N compatible".
As for flash savegame support, only 64kB is supported due to the 16bit adress bus.
Flash memories generally have the same erase cycle expectancy as EEPROM. Only a few special Intel flash versions have 10k cycle expectancy.
100k and 1M cycle expectancy is normal for flash.
#8437 - Cyberman - Thu Jul 10, 2003 3:46 pm
| ampz wrote: wrote: |
We were talking GBA savegame types here, and there are only 4k and 64k EEPROM carts. I'am well aware that serial EEPROM's exist in many different configurations.
The ones you pointed out are not "N compatible". |
You mean Nintendo library compatible then? hmmm Then options are pretty limited sadly, would be nice if one could have larger saves with the simple EEPROM and FLASH. However it is possible to have > 64K flash saves. Though you must use part of the memory normally reserved for the game cartridge for this. I am not sure if N has library code for this, I believe from what I've read they do.
| ampz wrote: wrote: |
As for flash savegame support, only 64kB is supported due to the 16bit adress bus.
|
Well if you aren't using N's library's this is not true, the same with SRAM. You can do a lot of odd little things to gain more space the question in my mind though is it worth it. I have seen mentioned ATMEL flash used, this small sectored flash? It must be because it's 64k. That makes things interesting because you can erase and write 128 byte sections of the flash memory.
| ampz wrote: wrote: |
Flash memories generally have the same erase cycle expectancy as EEPROM. Only a few special Intel flash versions have 10k cycle expectancy.
100k and 1M cycle expectancy is normal for flash.
|
Doh yes sorry about that :)
I was thinking embeded processor flash.. le sigh.
Anyhow it looks to me if one is planning on needing lots of save memory compatibility with N is out the window. Which isn't a real shame just anoying.
Cyb
#8491 - ampz - Fri Jul 11, 2003 11:53 pm
If you intend to design your own cart hardware then you can do whatever you want and put any amount of memory in there, but I think the original discussion was regarding Nintendo savegame types.