Post by palmdoogie on Mar 16, 2014 6:35:23 GMT 1
If there's anyone on this board who is familiar with the LJP Code, can you answer a question for me?
What's the deal with the stack that is allocated in PNOmain.c? There is a chunk of memory allocated, swapped, and filled with garbage data(for the purpose of determining how much was used after execution). The pointer to the stack is: my_stack. But no where else in the entire code base is that pointer ever used. Is this stale code or does it have some other purpose or some sneaky way it is being accessed? I'm going to comment it off and see what happens for now, but I'm just curious as to it's orgin.
In the meantime, I've made a lot of progress under the hood in getting the MAME module to look more like the other console modules. I had forgotten how much hacking I originally did to shoehorn it in there, including making a separate custom PNOMAMEmain.c for the ARMlet as well as a bunch of different handling in LJPMain.c on the host side. Among other things, the passing of data and functions between the consoles and the original PMAME was quite different. The LJP Modules use a small handful of FTR pointers to pass simple parameters to the PNO while also utilizing a "Bridge" data structure and passing a pointer to it in the PNO call. PMAME on the other hand, made heavy use of FTR calls and instead of passing a pointer to a bridge data structure, it passed a Tapwave Glue pointer in order to access Tapwave functions in the 68K domain. I'm not sure why this was done as I see Tapwave function calls being made directly from many of the LJP Console PNOs. Why you would ever want to call them in the 68K domain is beyond me. The point is Moot for LJP-Lite, however, as I have stripped all Tapwave native functions from it. You can still run it on a Zodiac and take advantage of the larger screen to some extent, but Tapwave only features are not being implemented in LJP-Lite. I may add some back in in he future if it helps speed up the execution(read: rendering) on a Zodiac, but for now I wanted to distill the code down to it's simplest form.
Once I finish making MAME work with a common PNOmain function, the only major feature left is to cleanup the BeltBar implementation on MAME, and then squash a handful of bugs. Also, NES has a memory leak I need to track down. Surprisingly, none of the other modules seem to leak.
One more thing. The more I test this, the more I realize that the Atari VCS module is a huge turd! It is not at all up to the quality of the other modules. Many games don't run properly. Some don't render correctly. The audio is crap. It's just BAD. Now that I am understanding how the generic emulator engines have been threaded into the PALM OS specific user interfaces, I may just try and get a high quality Atari Emulator in to replace the existing VHS emulator. Of course, for me, the only logical choice is "Stella", which seems to be an extremely mature and robust Atari emulator. I hope that it won't be too difficult to make it work with LJP. At the same time, I hope it's not TOO easy, either, cause I want a new challenge
What's the deal with the stack that is allocated in PNOmain.c? There is a chunk of memory allocated, swapped, and filled with garbage data(for the purpose of determining how much was used after execution). The pointer to the stack is: my_stack. But no where else in the entire code base is that pointer ever used. Is this stale code or does it have some other purpose or some sneaky way it is being accessed? I'm going to comment it off and see what happens for now, but I'm just curious as to it's orgin.
In the meantime, I've made a lot of progress under the hood in getting the MAME module to look more like the other console modules. I had forgotten how much hacking I originally did to shoehorn it in there, including making a separate custom PNOMAMEmain.c for the ARMlet as well as a bunch of different handling in LJPMain.c on the host side. Among other things, the passing of data and functions between the consoles and the original PMAME was quite different. The LJP Modules use a small handful of FTR pointers to pass simple parameters to the PNO while also utilizing a "Bridge" data structure and passing a pointer to it in the PNO call. PMAME on the other hand, made heavy use of FTR calls and instead of passing a pointer to a bridge data structure, it passed a Tapwave Glue pointer in order to access Tapwave functions in the 68K domain. I'm not sure why this was done as I see Tapwave function calls being made directly from many of the LJP Console PNOs. Why you would ever want to call them in the 68K domain is beyond me. The point is Moot for LJP-Lite, however, as I have stripped all Tapwave native functions from it. You can still run it on a Zodiac and take advantage of the larger screen to some extent, but Tapwave only features are not being implemented in LJP-Lite. I may add some back in in he future if it helps speed up the execution(read: rendering) on a Zodiac, but for now I wanted to distill the code down to it's simplest form.
Once I finish making MAME work with a common PNOmain function, the only major feature left is to cleanup the BeltBar implementation on MAME, and then squash a handful of bugs. Also, NES has a memory leak I need to track down. Surprisingly, none of the other modules seem to leak.
One more thing. The more I test this, the more I realize that the Atari VCS module is a huge turd! It is not at all up to the quality of the other modules. Many games don't run properly. Some don't render correctly. The audio is crap. It's just BAD. Now that I am understanding how the generic emulator engines have been threaded into the PALM OS specific user interfaces, I may just try and get a high quality Atari Emulator in to replace the existing VHS emulator. Of course, for me, the only logical choice is "Stella", which seems to be an extremely mature and robust Atari emulator. I hope that it won't be too difficult to make it work with LJP. At the same time, I hope it's not TOO easy, either, cause I want a new challenge