Iíve noticed a number of games available on this site for PRIZM calculators (space invaders, chess, senet, etc.) work fine on the CG10/20, but have broken graphics on the CG50. This has probably been asked before, but is there a workaround to fix these bugs without having to rewrite it all myself?
Yes so in general there isn't much to do. The #1 problem, which fixes almost all add-ins, is using a hardcoded VRAM address. Due to physical reasons the RAM on the fx-CG 50 starts at 0x8c000000, not 0x88000000, and so the VRAM moves as well.

Just use the GetVRAMAddress() syscall instead of the VRAM_ADDR macro (not sure how it's usually called), recompile, and most programs will work out of the box, and even on both platforms with the same g3a.

Additionally, many programs set some overclock on fx-CG 10/20 for a little added speed. The CPU of the fx-CG 50 natively runs faster than the fx-CG 10/20 (specifically twice as fast), and so this overclock step is no longer needed. It is even detrimental as the configuration it sets is slower than the default. This overclock step can thus be skipped. You can heuristically detect the fx-CG 50 with the stack address (if it's < 0x8c000000 -> fx-CG 10/20, if it's higher -> fx-CG 50).

I should also mention the icon style which has changed with the fx-CG 50 and has been backported to recent OS versions of the fx-CG 10/20. Old icons would benefit from a re-design.

Other than these simple considerations, I believe every program is different. Technical programs like emulators are extremely likely to have complicated memory layouts that would probably require the expertise of the author to port. I attempted to decipher CGDOOM once, but quickly gave up as there are so many memory-layout tricks, filesystem bypassing mechanisms, and generally an insane number of shenanigans that are hard to reverse-engineer and replicate on the CG-50.

As long as you don't get near these programs, and you have the source code, recompiling for the fx-CG 50 should be an easy and pleasant experience. ^^
Lephe wrote:
I attempted to decipher CGDOOM once, but quickly gave up as there are so many memory-layout tricks, filesystem bypassing mechanisms, and generally an insane number of shenanigans that are hard to reverse-engineer and replicate on the CG-50.

I will take it as a compliment Smile
CGDOOM is quite the tour the force indeed! My memories of dealing into it are admittedly quite painful, but this is mostly because of the complexity and the fact that I had no documentation (is there any by the way?). There is a reason why no similar program has appeared in years! ^^

If you ever want to port it, I would be glad to offer help. In France there is basically only the fx-CG 50, and it's a shame that CGDOOM cannot be played and advertised on this platform.
Lephe wrote:
...I would be glad to offer help.

I do not have fx-cg 50. Can you take current source code of CGDOOM, compile it and test on fx-cg 50?
If yes, we can try to fix it.
Yes I can! The most recent link I have for sources is https://martin.poupe.org/casio/cgdoom/cgdoom0.03src.zip , is that the correct one?

I no longer have my original port attempt, but I know the first few problems are about display and loading data from storage memory. Setting the VRAM addresses, disabling overclock etc. are the first obvious targets. Then IIRC, CGDOOM loads files by searching for for the first few bytes (or some kind of signature) on a 4k/page/sector/whatever-aligned address to find file fragments without querying the filesystem. This is probably what stopped me when I first wanted to port it.

If you have a chance, you can try to run the add-in on the fx-CG 50 emulator which is wonderfully close to actual hardware (I have run incredibly edgy programs on there with great success); the only major difference is that RAM is at the old fx-CG 10/20 address (0x88000000) and not the fx-CG 50 address (0x8c000000). Depending on how you want to tackle the port, this might save a lot of back-and-forth testing. ^^
Lephe wrote:
Yes I can! ...
Yes, it is my latest source, but there is an attempt to port cgdoom to fx cg-50 at https://github.com/ComputerNerd/cgdoom It contains the fix with GetVRAMAddress() and getSecondaryVramAddress(). You can try to merge these changes.
About the CreateFileMapping() function. As you probably already noticed, reading files from flash is very slow and there is a busy symbol. Moreover it takes RAM, when the data is already available in flash, which also can be read by pointer. So my idea is to find address of the file (wad) and read it directly. Unfortunately the file might be fragmented, so I have created file mapping, which is several records of pointer and size (of continuous data). I think I put some comments in the code. I think there is no need to change the code except to tune the addresses to match fx cg-50. The routine is pretty stupid, it reads the file per 4KB pieces and try to find each piece in flash. I think it can be optimised, the OS file read function seems to provide this address, but it is not important for porting.

Next thing is to tune RAM buffers. Do we have map of memory for fx cg50? There are rumors about 8MB of RAM in it. If this is true, cgdoom will work much better. fx cg20 has 2MB of RAM, but only about 1MB (in several pieces) was used for cgdoom

Sorry, but I did not develop anything for calculator for several years, so I forgot all the details. Please try to find the documentation from Simon Lothar (or anything more recent, if it exists)
Sorry for the delay. So I started from ComputerNerd's version, although there are some differences with the PrizmSDK: common/prizm.ld vs toolchain/prizm.x, -D_FXCG_MINICOMPAT (obviously) for compatibility ; and I also had to pull the platform.h header from your archive as ComputerNerd's version doesn't have one in CGDOOM-miniSDK/CGDOOM.

I still lack display_tools.h in my PrizmSDK, so I'm not confident I'm building it with the proper setup. Some update I made since my first attempt might have caused problems. Could you point me to the proper SDK source/version to use to compile CGDOOM? I'd rather solve one problem at a time and not mess around with the SDK as I'm not very familiar with it. ^^
Lephe wrote:
So I started from ComputerNerd's version

I noticed, that that project is incomplete, that is the reason I recommend you to ingegrate changes from it to cgdoom0.03. It should be compiled by Simon's mini SDK.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement