Hello,
I am porting one bigger game to Casio Prizm. It works in my simulator, but not on the real HW.
I think the main problem may be in endianess, because Prizm is big endian (opposite to the original platform and windows where I run my simulator) and game data is in little endian.
I would like to find some way how to debug program directly on Prizm, but we do not have debugger as I know. One possibility could be to output debug messages (to screen or better to serial output so one can see both messages and graphics).
Do you have any other idea how to debug large programs on Casio Prizm ? Some tricks ?
Martin
An excellent question, and a topic that we should probably cover in more depth for other Prizm programmers as well. I generally use some of the following techniques:
:: Turn on pixels to indicate progress to successive sections of code.
:: Use PrintXY to print debug strings/numbers to the screen
:: Compile parts of the code with GCC and run on my computer to test logic. This has been invaluable with gCAS2/Graph3DP.
How about you guys?
Indeed, there aren't really any good ways to debug. I'm going in the direction of printing diagnostic messages on the serial port for the new libc work, and parts of it (tests) are designed to be run on the host computer, but I still expect debugging the lot (particularly those parts that can't feasibly be debugged on a PC) to be a pain.
KermMartian wrote:
:: Compile parts of the code with GCC and run on my computer to test logic. This has been invaluable with gCAS2/Graph3DP.
Have you seen my Prizm simulator? It is included in jpeg or raw based cgplayer (with sources). It simulates LCD, keyboard and very few another syscalls (I add them on need). But unfortunately it is for windows, so I cannot debug big endian issues here. I would probably not buy old Mac just for this
I usually make the output of certain problematic lines of code verbose (by hacking some locates/print-mini-fix into the code) in order to show the value of certain variables I want to debug.
Other than that, it's pretty much code->build->put on calc->run->fix->build->put on calc... let's hope one day I don't break the USB connector or parts of the memory for overwriting them so much...
gbl08ma wrote:
I usually make the output of certain problematic lines of code verbose (by hacking some locates/print-mini-fix into the code) in order to show the value of certain variables I want to debug.
Other than that, it's pretty much code->build->put on calc->run->fix->build->put on calc... let's hope one day I don't break the USB connector or parts of the memory for overwriting them so much...
I wonder if that's why my calc broke... I was in the middle of developing, and I had been transferring files to and from it all week. (I didn't have it in receive mode, just had it sitting there, connected to the computer while I coded, when it broke)
flyingfisch, I think that's unlikely. I'd rather much believe that your computer sent a too high voltage over the USB port for a fraction of second, breaking something in the power/memory module. Or else, the motherboard was simply defective and the calc was just waiting to die (the calcs they gave away in contests were probably refurbished already...).
MPoupe, no, I haven't seen it at all. Do you have a topic about it somewhere here?
Sometime during the day today I remembered another technique similar to Tari piping text through the serial port. Since we have BFiles to work with, we can dump debug text into files as well.
gbl08ma wrote:
flyingfisch, I think that's unlikely. I'd rather much believe that your computer sent a too high voltage over the USB port for a fraction of second, breaking something in the power/memory module. Or else, the motherboard was simply defective and the calc was just waiting to die (the calcs they gave away in contests were probably refurbished already...).
Yeah, I was wondering if maybe they were giving away a bad batch of calcs....
KermMartian wrote:
MPoupe, no, I haven't seen it at all. Do you have a topic about it somewhere here?
Sometime during the day today I remembered another technique similar to Tari piping text through the serial port. Since we have BFiles to work with, we can dump debug text into files as well.
I created topic about this at http://ourl.ca/12030, but there was almost no discussion here.
I think serial dump is better, you have real-time dumps (of course program is slower) and you save flash write cycles.
Flyingfisch: I doubt that; the rest of them seem fine.
MPoupe: Agreed, serial dumps have several things going for them, but you may not always have something that can receive from a serial terminal handy.
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
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