#16139 - tepples - Mon Feb 09, 2004 6:37 pm
The GBATEK page describes how to access EEPROM.
| Martin Korth wrote: |
| After the DMA, keep reading from the chip, by normal LDRH [D000000h], until Bit 0 of the returned data becomes "1" (Ready). To prevent your program from locking up in case of malfunction, generate a timeout if the chip does not reply after 10ms or longer. |
In practice, does a program have to keep reading from that address continuously, or can it go do something useful during that time?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#16145 - poslundc - Mon Feb 09, 2004 8:43 pm
I don't know about in practice, but in theory, if it's recommended to generate a timeout in case of malfunction it would follow that you aren't constrained by the hardware while the EEPROM writer is in operation.
Otherwise, why would they operate in parallel? It should just suspend the CPU like the DMA does otherwise.
Of course, you were asking about behaviour in practice, and as far as that goes I have nothing useful to offer.
Dan.
#16151 - SmileyDude - Mon Feb 09, 2004 11:16 pm
I believe I've seen Serial EEPROM based games do something while saving (like update an animation/play music), but I can't remember which game it was off the top of my head. It seems like most just "lock up" until the save is finished.
I'll try to check again sometime to see which game it was.
_________________
dennis
#16156 - torne - Tue Feb 10, 2004 12:05 am
You can do anything you like that doesn't access EEPROM; most games just don't bother. The N backup library uses a callback for the timeout.
#16178 - tepples - Tue Feb 10, 2004 4:45 am
| poslundc wrote: |
in theory, if it's recommended to generate a timeout in case of malfunction it would follow that you aren't constrained by the hardware while the EEPROM writer is in operation.
Otherwise, why would they operate in parallel? |
What I was most unsure of was whether reading ROM during an EEPROM write would interfere with the write.
SmileyDude: Actually, "doing something" while updating EEPROM could be done even if EEPROM writing blocked ROM reading; according to GBATEK, an EEPROM write typically takes less than half a frame.
But if in fact, as torne implies, it's OK to read ROM during EEPROM write completion, I'll take the callback technique into account when I start experimenting on a GBA-side hex editor for savegames. (Or do most commercial games use some sort of complicated checksum?)
Now all I have to figure out is how to write to 512 Kbit flash, as GBATEK gives little or no guidance in this department.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#16190 - torne - Tue Feb 10, 2004 2:38 pm
| tepples wrote: |
| What I was most unsure of was whether reading ROM during an EEPROM write would interfere with the write. |
Shouldn't do.
| Quote: |
| But if in fact, as torne implies, it's OK to read ROM during EEPROM write completion, I'll take the callback technique into account when I start experimenting on a GBA-side hex editor for savegames. (Or do most commercial games use some sort of complicated checksum?) |
The N backup library requires that you surrender a timer to it when you write; it sets that timer up to generate the timeout, and on the timer interrupt it checks the flag. Not exactly a callback, but similar. Games often use checksums as well as this; games that use flash almost always read/verify the data they write as well.
As I said in another post just now, I'm hopefully going to be able to clean-room the N backup library at some point soon. Flash is a pain as there are at least three or four different flash chips used in commercial carts, all of which have different access protocols. (but a standard 'identify' technique which tells you which is on a particular cart)
#16233 - ampz - Wed Feb 11, 2004 1:36 am
| torne wrote: |
| tepples wrote: | | What I was most unsure of was whether reading ROM during an EEPROM write would interfere with the write. |
Shouldn't do.
| Quote: | | But if in fact, as torne implies, it's OK to read ROM during EEPROM write completion, I'll take the callback technique into account when I start experimenting on a GBA-side hex editor for savegames. (Or do most commercial games use some sort of complicated checksum?) |
The N backup library requires that you surrender a timer to it when you write; it sets that timer up to generate the timeout, and on the timer interrupt it checks the flag. Not exactly a callback, but similar. Games often use checksums as well as this; games that use flash almost always read/verify the data they write as well.
As I said in another post just now, I'm hopefully going to be able to clean-room the N backup library at some point soon. Flash is a pain as there are at least three or four different flash chips used in commercial carts, all of which have different access protocols. (but a standard 'identify' technique which tells you which is on a particular cart) |
Do you know how the N backup library handle the flash erase and program commands? Does it poll the flash memory continuously until the sector is erased/written, or does it use a timeout?
#16244 - torne - Wed Feb 11, 2004 3:19 am
I believe flash erase and write use the same timer mechanism; don't remember though. As soon as I start work on backup code again, I'll publish information. Been rather busy of late writing my high-level assembler due to scary deadlines =)
#16245 - ampz - Wed Feb 11, 2004 4:24 am
Exactly what function calls does the N flash API have?
Interestingly enough, not all flash memories used in GBA games feature a sector erase command. They don't even have the same sector size.
For example.. A Sanyo/SST flash memory have 4kB sectors, and it does have both a sector erase command and a programming command.
On the other hand... the Atmel flash memory have 128byte sectors, and it has no sector erase command, only a "sector reprogram command". The sector is automatically erased before it is programmed.
#16271 - torne - Wed Feb 11, 2004 1:31 pm
The flash API from backup lib 1.2.0 has:
* identify chip
* setup timer interrupt (for the timeouts)
* erase chip
* erase sector (called for you by the write routine, so normally not needed)
* write sector
* verify sector
* read sector
No idea how the differences in chips are handled other than that there seem to be multiple implementations of the above functions in some (all?) roms, suggesting that they switch implementation dynamically depending on the result of the identify.
#16273 - ampz - Wed Feb 11, 2004 1:53 pm
| torne wrote: |
The flash API from backup lib 1.2.0 has:
* identify chip
* setup timer interrupt (for the timeouts)
* erase chip
* erase sector (called for you by the write routine, so normally not needed)
* write sector
* verify sector
* read sector
No idea how the differences in chips are handled other than that there seem to be multiple implementations of the above functions in some (all?) roms, suggesting that they switch implementation dynamically depending on the result of the identify. |
The sector size must be fixed? 4kB?
#16275 - torne - Wed Feb 11, 2004 3:04 pm
Nope, sector size is detected by identify.
#16280 - ampz - Wed Feb 11, 2004 4:50 pm
| torne wrote: |
| Nope, sector size is detected by identify. |
Yeah, but API to the game must be the same no matter the sector size, right? Or is it up to the game to handle all different sector sizes?
Let's say there is no flash memory with a sector size larger than 4kB... In that case, the library could make all sector operations work with 4kB blocks so that the game sees no difference..
#16281 - torne - Wed Feb 11, 2004 4:57 pm
I don't know; I've not successfully analysed call sites in commercial ROMs that use flash. The API uses integers to select the sector number. I would guess that either the game has to handle all sector sizes, or the game only works with one sector size. You can't make all operations work with the largest block (well, technically you can, but not in any sane way) because the semantics of operations will break; a game which erases sector 3 in order to delete a temporary save might lose sectors 0-7, which could include all permanent saves =)
#16300 - ampz - Wed Feb 11, 2004 11:42 pm
No, the other way around...
Let's say there are flash memories with 4kB and 128byte sectors. But, to the programmer, the API only works with 4kB sectors.
So, if a flash memory with 4kB sectors is used, a "erase sector 0" command from the game will erase sector 0 in the flash memory. (4kB)
If a flash memory with 128Byte sectors is used, a "erase sector 0" command from the game will erase sector 0-31 in the flash memory. (128*32=4kB)
From the programmers point of view, all flash memories works the same way.
#16301 - torne - Wed Feb 11, 2004 11:46 pm
Ah yes; the other half of my cleanroom 'team' confirms that sectors are always 4kbytes from the client's POV.
#16303 - ampz - Thu Feb 12, 2004 1:27 am
| torne wrote: |
| Ah yes; the other half of my cleanroom 'team' confirms that sectors are always 4kbytes from the client's POV. |
Weee.. My guess was right :-)
You say there is a sector erase function... The Atmel flash memory has no sector erase command. Of course, the library could write all 0xff's to the entire sector to emulate a erase command, but that would be kind of pointless..
#16305 - torne - Thu Feb 12, 2004 1:42 am
Don't know, but will find out soon hopefully. Some games depend on the erase sector command working; FFTA definately does. There are both permanent and temporary save slots; you can only make permanent saves on the map, and they are kept, but you can make tempsaves during battles. The game exits after you save, and it deletes the save when you reload it. However, the delete is implemented in terms of erase sector, which means that when you SRAM patch the game to make it work on a flashcart (the normal SRAM patches map erase and erasechip to no-ops), the tempsaves are not deleted, which means you get to have semi-real saves during battles. =)
#16319 - ampz - Thu Feb 12, 2004 10:52 am
Oh? Do the flashcarts with flash savegame support do the same? The easiest way to emulate sector erase and chip erase commands in hardware is to ignore them..
#16321 - torne - Thu Feb 12, 2004 1:24 pm
| ampz wrote: |
| Oh? Do the flashcarts with flash savegame support do the same? The easiest way to emulate sector erase and chip erase commands in hardware is to ignore them.. |
Don't know; haven't got one. I just abuse that feature to cheat at FFTA. =)
#17760 - caitsith2 - Sun Mar 14, 2004 8:26 am
While flash writing is not all that well documented, this is what I have found out in doing so.
----- Check flash identity -----
0xE005555 = 0xAA
0xE002AAA = 0x55
0xE005555 = 0x90
Value 1 = 0xE000000
Value 2 = 0xE000001
0xE000000 = 0xF0
----- Switch bank number ----- (applies only to 1Mbit flash)
0xE005555 = 0xAA
0xE002AAA = 0x55
0xE005555 = 0xB0
0xE000000 = [bank number (0, 1)]
----- Write byte to flash ----- (xxxx = address to write to, yy = byte to write)
----- This operation is essentially what write sector is more or less made up of, just a whole bunch of these. -----
0xE005555 = 0xAA
0xE002AAA = 0x55
0xE005555 = 0xA0
0xE00xxxx = 0xyy
writeloop:
val1 = 0xE00xxxx
val2 = 0xE00xxxx
if val1 != val2 goto writeloop
val1 = 0xE00xxxx
val2 = 0xE00xxxx
if val1 != val2 goto writeloop (just in case the writing wasn't quite done yet)
----- Erase flash -----
0xE005555 = 0xAA
0xE002AAA = 0x55
0xE005555 = 0x80
0xE005555 = 0xAA
0xE002AAA = 0x55
0xE005555 = 0x10
eraseloop:
val1 = 0xE000000
val2 = 0xE000000
if val1 != val2 goto eraseloop
val1 = 0xE000000
val2 = 0xE000000
if val1 != val2 goto eraseloop
This covers pretty well everything to deal with macronix flash chips, except for the erase sector command, which is also present, but I am unsure as to how it is done. It is similar to erase chip, except the last address = val part differs, and I never played around with it, as my multiboot flash writer simply erases the whole chip before reprogramming it.
#17764 - ampz - Sun Mar 14, 2004 1:44 pm
caitsith2: Have you tried using the erase flash command on a flashcart with hardware flash support? Do they actually erase the flash, or do they ignore the erase commands?
#17790 - caitsith2 - Sun Mar 14, 2004 7:40 pm
I never really tried on an actual flash cart, but on real game cartridges, like the e-reader, and Super mario advance 4, (both are 1Mbit), and advance wars (512Kbit). I don't know if the erase commands are ignored or not on flash carts with hardware flash support.
#17855 - dagamer34 - Tue Mar 16, 2004 1:08 am
Since we are on the topic, does anybody have a working example of writing to EEPROM?? The code I have doesn't work at all.
_________________
Little kids and Playstation 2's don't mix. :(