Even though the Retrode appears to the operating system as a vast storage device, its file system is mostly fake due to severe memory limitations. Most sectors are read-only, except for the ones that contain the config file and the savegame(s). Unfortunately, in some constellations this may cause trouble when these files are written to, causing the data to not actually being stored in the config memory or on-cart SRAM.
For you, the user, the problem might manifest itself as follows. Assume you have loaded the retrode.cfg file, modified it, and want to save it back. Then, one of the following could happen:
- You get an error that the disk is full.
- The application pretends that it has successfully saved the file, but after a reset of the Retrode, the data is back to original.
The most likely cause for either is when, instead of overwriting the existing data, a new file is made, and then the old directory entry redirected to the new data. The way I understand it, this is in the hands of the application. So speaking in C, fopen(filename,”w”) (create empty file for writing) would be more likely to cause this kind of trouble than fopen(filename,”r+”) (open existing file for (reading and) writing) . Programmers usually consider the first variation to be safer since the original data is not destroyed, and the file can be reverted should an error occur halfway through the saving. Here, however, it’s counterproductive. The Retrode simply doesn’t know where to look for the modified data, and to my knowledge there is no simple and elegant way to find out (mind you, the data is written first, then associated with the file system entry). If you think you can come up with one, please tell me.
Other than changing the code ofÂ your favourite emulator / text editor, there is no “clean” solution to this problem. Here’s a workaround that you can use if you have trouble copying the config file or savegames to your Retrode. Thanks to [bryan_c] for investigating and for the write-up.