In the quest to obtain more information on the FT-897 and answer some theories that have been floating around, I participated in a discussion on the Yahoo group FT-897. Here is some of the information that came out of that.
The CPU on my unit is a H8S/2134A series. I fully believe that all other CPUs, even from older models, will be just as capable, if not identical. If anyone
wants to open theirs up and peek, it is located by the solder pads where you do the MARS/CAP mod (set the operating region). It is the only 80 pin chip in that area. To avoid clutter, please only add a comment if your CPU is different. This makes it easier for others to read which are different as opposed to 100 comments all saying “mine too”. The data sheet for the H8S/2134A series cpu is available at http://pdf1.alldatasheet.com/datasheet-pdf/view/249719/RENESAS/HD64F2134AV.html
This CPU has 128k ROM and 4k RAM. The ROM appears (as in this is a guess) the radio firmware, band plan data, and various other tidbits. It is likely that there is a method to rewrite the firmware easily, so that when the radio is sent to Yaesu they can just load the newest without having to desolder and resolder anything. This would actually make a lot of sense and it would be kind of stupid to do it any other way, as a result I believe this is a correct guess.
There is an EEPROM located on the board wired into the CPU as well. This EEPROM is a Microchip 24LC1281. It appears that ths holds the configuration data. Your alignment settings, memory settings, and preferences for the radio. This EEPROM has at the time I write this, not been dumped to validate this theory of configuration data being stored, however it is the right size, and has other features that strongly imply that is what its purpose is.
The data sheet for this EEPROM may be obtained from http://www.alldatasheet.com/datasheet-pdf/pdf/194702/MICROCHIP/24LC128-I/SN.html. This is a 128kbit EEPROM, which is accessed via an I2C bus (natively supported by the CPU). This is also a somewhat robust EEPROM with a 4kv rating. This EEPROM is rated for > 1 million erase/write cycles which given what appears to be going on with the radio, that should last longer than the radio itself. The EEPROM can also retain the data for > 200 years before it needs to be refreshed. If the radio is still operational in 200 years (and not superceded by a non-RF based communications
method) I would personally be amazed, so again it seems that this EEPROM is likely better than the reasonable life of the radio.
Charles Scott n8dnx wrote that there is a capacitor that would provide power for a limited duration to both the EEPROM and the CPU after power is disconnected. Additionally, he observed a trace on the board that connects the CPU to a watchdog circuit for the input voltage. If you lose battery or 13.8v the radio would appear to have the ability to detect this and have just enough power to commit any changes the radio has experienced.
By dumping the eeprom it is known that certain settings such as the active VFO, frequency, mode, etc are stored on the EEPROM. By committing the information only at the time of a power loss/shutdown the radio can spare the EEPROM so that it can last for decades without failure.
What the radio appears to be doing is loading the firmware into the 4k of RAM that the CPU has internally, as well as the EEPROM data. Any changes are made in RAM, although some may be committed instantly. On power disconnect/shutdown changes are written to the EEPROM.
This would mean that it is perfectly safe to write to the EEPROM in an endless loop as quickly as you possibly can since wear on the EEPROM is mitigated in one of the ways that Dean Gibson AE7Q said was common in the industry based on his decades of work in the embedding industry.
I said that some changes may be committed at the time they are made. Things like a memory location may be stored instantly, I have not done a dump of the EEPROM or monitored the I2C bus to see if this is the case or not. The reality is that it would be easier from a development perspective, result in smaller code from an embedding perspective and generally be easier to commit everything, possibly with a boolean flag indicating that something has changed.
At most only 16kbytes would be written, that is the capacity of the EEPROM. Much of this appears to be unused according to the memory map. This means that only about 2k would have to be written. The estimates by Charles Scott are that you would have up to 0.5-1 second to flush all the data based on the capacitors size and current consumption of the EEPROM and CPU. If this holds, and the write routine is optimized for speedy writing, this should be more than enough time for this amount of data. If that is the case, Yaesu may commit the entire EEPROM at each power disconnect/shutdown. Yaesu probably thought ahead a little and only commits data if there is a change and does not commit data if there is no change.
If the previous assumptions are found to be correct, you would be able to power cylce the radio over 1 million times before there is a potential for failure in the EEPROM due to wear. If you turned the radio on and off 100 times per day every day (which is a lot unless you are just trying to wear it out) the EEPROM would last 27.4 years. Even in this extreme example I think that the EEPROM would last far longer than most people would continue to use the radio. I think 20+ years is a reasonable lifetime for this radio, and it is likely that relays or something else would fail before the EEPROM.
The only thing left is to dump the firmware off the CPU, disassemble it to figure out how it works, and start writing enhancement mods Providing there is enough RAM, one enhancement would be more memories, I would prefer to have more limit memories personally. There exists the potential to add a “license band plan” so that the radio knows where you, based on your license class, are authorized to transmit in and does not let you go outside of that. This would not be a trivial undertaking, I have disassembled quite a bit of code in my time, and usually I only look for the relevant sections and do not go through the entire program. Going through everything would consume a lot of effort just to get to the point where you can understand enough of what is going on to make even the tiniest of modifications.
I have not looked very far in the datasheet where it talks about the ROM storage and if there is even a way to access it. If there is not an easy way then it is likely that pulling it off would be even more daunting. To try to write code from scratch that does everything Yaesu’s does would also be a less than trivial task. Without a method to easily load new firmware, perhaps through the CAT interface, few would try it out anyway, making it somewhat less rewarding to do.
And finally there are regulatory issues that may come up as well as copyright issues that most certainly will come up. For various reasons this would probably be one of the harder projects to accomplish.