Sorry about the confusion. When Pogoshell came out, it provided a nice structured UI to accessing a virtually unlimited number of files (if you had the space for them) vs the F2A being limited to a short list of like 4-8 games (never used it so not sure what it's precise limit was). The key part was the plugin system so you could associate the nes emulator to the nes games instead of making one giant compilation* even if you still had to reflash the whole image built pogoshell image on again (which took like 5 minutes). There was also the save system that went along with it to turn the 256KB of SRAM into a 64KB buffer for one game and the other 192KB to store compressed backups.
Anyways, the EZ Omega (and IV really) don't really have a need for a different UI or save handling, and it really doesn't even need the whole game<->emulator association thing because you can run single-game compilations if you so desire (like the EZ Flash IV). I just figured that since the source was available and it seemed like it should be pretty trivial to add support--and I wanted to actually see if baking emulators into the kernel for speed was really a necessity--so I had a go at it. So, it's 99% novelty, which is why I didn't really bother to tag it in any way or put effort into sprucing up anything. Overall, I'd say though that the kernel emulators was really unnecessary. Except for the whole
possible save corruption but that could have been dealt with in a better way (an extension to the patch engine using a crc and an address on where to patch out). I'm actually sort of disappointed that we didn't see the maxzhou88 pocketnes fork but then I don't think he ever released the source for that.
* One could make multiple compilations and then they'd all share 64KB of SRAM for their saves, or let Pogoshell give each game 64KB of SRAM and compress the output and effectively share 192KB of SRAM (or 128KB if you use Pogobridge).
@
Xdqwerty:
@
BakerMan:
@
NinStar:
@
a_username_that_isnt_cool:
