Originally posted by: Tanooki
I never said it wasn't, just that it wasn't the usual subpar system on a chip junk which won't run various carts, mishandled audio and video(color) issues and the other popular complaints about such things. This one has the potential cheap Chinese junk or not with system patches to clean up a lot of stuff those garbage past clone boxes didn't bother to do.
Homebrew like battle kid and the like could work. It would depend if bunny shared the info, or one of many credible people out there with engineering talents to take a look at it and figure it out themselves and send that data to Hyperkin if they don't take it upon themselves to do it (less likely.) I think if they're approaching this on facebook already talking about firmware upgrade one to get stuff like this going, they may be seriously for now taking in complaints and wanting to address them to put most of the legit complaining to bed to just leave the hot air filled trolls with less to complain about.
It's been done already. Study Hall and Xmas 2013 have been assigned iNES Mapper #30. I have been in correspondence with the guy who figured it out, whose identity will remain a secret unless he comes forward to take credit. Fact is, the newer boards which use flashed based save data do not work the way normal SRAM games work. They actually have more in common with the FDS system in that regard, since the game data is stored on rewritable media. For example, Study Hall stores the high score tables in bank $06. To properly emulate such mapper, it is necessary to write changes back into the ROM. This would cause a lot of headaches for Hyperkin, and you definitely would not want to write the save file back to the cartridge, because the entire ROM is the save file. One wrong bit and the cart could be toast. However, during normal game operation, only the bank which contains the save data gets overwritten, so the chances of bricking the game on properly functioning hardware, original or clone, is minimal. Another issue with running a newer flash based game on the Retron5 is the CRC value which would change every time the "save" data is updated. Assuming the Retron5 uses CRC hashes to identify the game cart, it would create a new "unknown" entry every time the cart is inserted with updated save info. This is probably another reason why the Retron5 can't be arsed into supporting the Famicom Disk system.