0 Members and 1 Guest are viewing this topic.
With static recompilation, you do the same as in dynamic recompilation, but you follow branches. You end up building a chunk of code that represents all of the code in the program, which can then be executed with no further interference. This would be a great mechanism if it weren't for the following problems: * Code that isn't in the program to begin with (e.g. compressed, encrypted, generated/modified at runtime, etc) won't be recompiled, so it won't run * It's been proven that finding all the code in a given binary is equivalent to the Halting problemThese combine to make static recompilation completely infeasible in 99% of cases. For more information, Michael Steil has done some great research into static recompilation -- the best I've seen.
There would be extra code to substitute for the BIOS and graphics routines, but the actual graphics, as in tiles and sprites, can be converted into 4lvl grayscale, cutting down their size fourfold. (GBA has 32,768 colors, so I'm assuming 16bppThat stupid autocorrect tried to change sprites to spruces, but this time I caught it.
Even better - an OS hook to run ROMs directly from the my documents screen.
Most GBA graphics are already 4-bit. The actual colors are looked up from a palette. And I'm not sure how exactly you would locate the graphics data in a ROM automatically, anyway. Also, there are not "graphics routines", there is graphics hardware.
In other words, before we get a calc powerful enough to run a GBA emu at full speed, emulating all effects, it may take years...
Quote from: calc84maniac on November 16, 2010, 10:32:15 pmMost GBA graphics are already 4-bit. The actual colors are looked up from a palette. And I'm not sure how exactly you would locate the graphics data in a ROM automatically, anyway. Also, there are not "graphics routines", there is graphics hardware.You don't need to locate graphics data in a ROM, you only need to block access to HW and emulate it in signal handler. Should be simple to do if Nspire's CPU includes proper MMU. The only question is if it'll be fast enough: context switch is slow business and Nspire is only 10 times faster then GBA...Quote from: DJ Omnimaga on November 16, 2010, 09:59:08 pmIn other words, before we get a calc powerful enough to run a GBA emu at full speed, emulating all effects, it may take years...It's not a question of power: Nspire is more then capable enough. It's question of doing the actual work. Compare XBox (original, not XBox360) emulation with PS2 emulation. It's actually harder to emulate PS2 - but people want it so it works (not perfectly, but compatibility was over 50% two years ago, by now I think it's about 80-90%) while XBox... well, you can run one or two games - and that's all.So ironically enough while I agree that "it may take years" I don't agree that we need new hardware: it'll take years, but the end result will probably be GBA emulator for Nspire, not for some exotic new platform.