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.

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...

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.

Yeah, I was wondering if maybe they were giving away a bad batch of calcs....

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.