Hey. This sounds as a cross-compiler. I have used the portable Southampton compiler for this purpose. I needed to do automatic translation from parallel Occam to C. It took me around 6 months to fine-tune the cross compile to produce maintainable C-code.
This is not so complicated as it sounds. You parse the entire NES object code and create an object tree in memory of the entire program with graphics, sounds etc. Then you just edit the object tree to replace the NES hardware dependencies to Lynx hardware. The final step is to output Lynx asm code that can then be fed to a lynx compiler for producing a cart.
My guess is it takes a year to get it done.
Once the cross-compiler is ready you can toss any NES games to it and enjoy the Lynx games it produces.
Streaming is used in many kind of games. For a living I work with navigation. When a ship moves you stream in new chart elements all the time. Nobody can read in the whole planet at once. A similar approach with a spatial database of objects is used in many RPG games. You get in objects for trees and bushes while you walk in a forest and can get rid of them when you enter a cave.
The Lynx does not have a mandatory "directory" for the cart. You could also put a spatial database on the cart consisting of code snippets, animations, graphics and sound. This is of course a little hi-tech for a 20 year old console. But on the other hand some crazy developers might even create accelerometers or 3D displays for the Lynx - who knows
A SD-card with lots of space is not a bad idea at all. My laptop has an SD card slot so transferring a new version from the laptop to the Lynx for testing would be very convenient. Currently I use ComLynx for my transfers and it takes many minutes to get one game transferred.
I would like to see the SD cart as an ultimate home-brewers format. It could have some generic SPI devices on the cart. Perhaps extended addressing for the SD card, an accelerometer and an 93C86 eeprom (2kbytes). This would be a very powerful environment to work on for all kind of new games.
My suggestion is to treat the SD-cart as a read/write medium. Cart0 for read, Cart1 for write. The AUDIN would be used for the SPI bus only. I have no idea how complicated this is to implement. But if Flavor can make it he has my support.
This needs to be implemented in Handy as well for getting emulation and debugging to work.
--
Karri