gmiller1018
Member
I have a version of the VBA code that I use in the class I teach at Full Sail where I took the 1.8.0 source and fixed a bunch of stuff to make it work for source code bebugging and the like. It has a core file in the emulation that on x86 machine is in assembly and I am going to rewite that for the ARM machine. There are some memory layout issues that I am looking for solutions.
The current code allows up to 32Mb of ROM code but on the current gp2x that would require using the upper 32Mb of memory (with the kernel module trick posted on the wiki). There appears to be sections of this memory that are used for frame buffers and the like. Are there any of these regions that it is unsafe to write over. I am trying to get some idea of the ROM size limits that I need to live with. I was thinking that using the cache memory on this region and an ARM core "might" make the performance of the VBA reasonable for use. I know there is a dynamic recompile thread here but I figured if my version of the emulator could run fast enough it might be a stop gap till the other project is done. Also in the mean time I get to learn something.
Any comments or suggestions?
The current code allows up to 32Mb of ROM code but on the current gp2x that would require using the upper 32Mb of memory (with the kernel module trick posted on the wiki). There appears to be sections of this memory that are used for frame buffers and the like. Are there any of these regions that it is unsafe to write over. I am trying to get some idea of the ROM size limits that I need to live with. I was thinking that using the cache memory on this region and an ARM core "might" make the performance of the VBA reasonable for use. I know there is a dynamic recompile thread here but I figured if my version of the emulator could run fast enough it might be a stop gap till the other project is done. Also in the mean time I get to learn something.
Any comments or suggestions?