Q&A- EEPROM/SRAM

QA1 What kind of backup medium is used in the cartridge?
QA2 Initializing the EEPROM...
QA3 Processing when EEPROM sizes are different.
QA4 When make is reached in the pfs sample, it is executed, but it doesn't run...
QA5 Can I burn the SRAM in a FLASH cartridge using the N64 Flash Gang Writer?

Q1 What types of backup media can be installed in the cartridges? What is the development environment for them?

A1 The following 3 types can currently be used.

  1. 4Kbit EEPROM
  2. 16Kbit EEPROM
  3. 256Kbit S-RAM

Their respective development environments are listed below.

  1. In the case of an INDY emulator, the EEPROM is mounted on a board called the Joy Bus Board for connecting the controller. This is also installed as standard on development FLASH cartridges. Since it is not installed on PARTNER cartridges (there is only a socket), it is being sold by the Nintendo Tokyo Branch Sales Department.

  2. Use a 16 bit unit inserted into the EEPROM socket. This also is being sold by the Nintendo Tokyo Branch Sales Department.

  3. This is the basic development environment for PARTNER.
    Insert an SRAM board "NUS-03A," (Photo 1) in the connector on the PARTNER (Photo 2) and perform development. For debugging, a 256Kbit SRAM is already installed in the current FLASH cartridge (8F16FB-128M), while the old model (8F16F-128M) uses both the 2-port adapter "NUS-DCC Board ASSY" (Photo 3) and the SRAM board "NUS-03A" (Photo 4).

There are also IS-VIEWER64 units with 256K-SRAM built-in and those without. Those without use both the 2-port adapter "NUS-DCC Board ASSY" (Photo 3) and the S-RAM board "NUS-03A" (Photo 4).

Photo 1

Photo 2

Photo 3

Photo 4

top

Q2 The following items are noted in the "Programming Precautions" regarding the backup memory (EEPROM).

"Please make it so that it will initialize normally, even if the contents of the backup memory are undetermined. Specific values are written in the backup memory when it is shipped from the plant, but those values are not guaranteed to be the same in the future."

With respect to this, how can I tell if the backup memory is in the state it was in when shipped from the plant? Even though the value itself cannot be specified, can it be determined whether or not it is an original factory ROM by checking, e.g, if the same value is continuously repeated?

A2 The contents of the EEPROM at the time of shipping can in no way be guaranteed.

Even if the initialization data are cleared with FFH, it is dangerous for the game creator to say that "it is in the shipped condition if FF continues for x number of bytes."

Trouble was also found when saving, even with past products, but this kind of processing is definitely something that you do not want to do.

Therefore, how about trying the following initialization conditions?

  1. Check to see that a specific ID [NINTENDO64] is registered at a specific address.

  2. If the ID matches, use the game as the initialized data.

  3. If the ID is not present at the specified address, it could have been missing when the memory was shipped or the memory may have been corrupted. Therefore, either initialize or write the necessary data, and write the ID to the specified address.

By building this kind of routine, there will probably be no problems even if the data are unstable when the memory was shipped from the plant.

This procedure is only one example, but should be performed to protect the memory.

This may go without saying, but problems may arise if procedures 2 and 3 are reversed. The memory may crash depending on the save processing method, if the power is turned OFF after writing the ID in step 3, because there will be an ID when the power is next turned ON even though step 2 has still not been performed.

Saved data should probably be handled as though the data have been corrupted to some extent.

There are additional software tools which will allow normal save processing to be performed even though any one byte has been corrupted (such as double IDs, save processing completion flags, etc.)

Since the EEPROM is small at 4Kbits or 16Kbits, they probably can't all be used, but since this kind of data saving activity is important, please build the system taking all of these possibilities into consideration to prevent the user from incurring problems.

top

Q3 In games with an on-board EEPROM, the EEPROM is checked during the game, and if an "EEPROM not on-board" or "Wrong size EEPROM on-board" result is returned, the manual says to "stop the continuation of the application program." What kind of processing should be done? Should there be some kind of message displayed, or is there some sort of minimum action with which I should comply?

A3 Since it is highly likely that you are using an unofficial cartridge if this kind of error occurs, there is no standard for the specific type of processing that should be done. Simply stop the program. You may also create a loop displaying a message to the effect that there is a problem with the backup memory.

top

Q4 When make is reached in the pfs sample, it is executed, but it doesn't run. What could be causing this?

A4 The most common cause is that the 5th connector in the INDY emulator board (it looks like a modular jack) has not been inserted. This terminal is connected to the EEPROM as the 5th serial signal. Please refer to the Kantan Manual STEP 2, Chapter 5, for the proper insertion method.

top

Q5 Can I burn the SRAM in a FLASH cartridge using the N64 Flash Gang Writer?

A4 Unfortunately, you cannot write to SRAM using the NUS FLASH Gang Writer (the hardware is not compatible).

top