MPoupe wrote:
Hello,
you already know, that it is very hard to debug an application for Casio cg 10/20 (Prizm).
We have 3 SDKs, but no debugger :-(
I would like to introduce you simple, but usable idea - workaround. One can write calculator's simulator - not the complete emulator, but just reimplementation of important syscalls to another platform, where debugger is available. I did a try and this is a result.
I created a tiny enviroment, with console window (for debug messages), display window and a keyboard window. This environment should simulate calculator's behavior. Now I have display (draw to VRAM and then call Bdisp_PutDisp_DD()), keyboard (only PRGM_GetKey() yet) and few another syscalls.

Please extract the attachment,try the puzzle.exe and puzzle.g3a (simple game) and tell me, what do you think about this. I can boast - I needed only 1 rebuild for Prizm platform, all bugs (except the last :-) )were debugged on this environment.

Few notes to the game - it is a simple puzzle, one has to move numbers to get them in the correct order. Numbers on correct position are green, red otherwise. Use arrows to move number box to the wished direction. The game will not quit after success, it is in very early stage.

Few notes to the simulator - to press key, click on it on the keyboard window. Computer keyboard is ignored (in this version). The display doesn't refresh when the display window is hidden and then restored. Right-click on it twice will workaround it. Image of the keyboard (tastatur.bmp) must be in the same folder as the simulator.
BTW: right click on the display switches zoom of the display between 1x and 2x

Sorry, but I did not attach the source code, it is really mess now. Needs some time yet ;-)


Edit by Merth: Fixed your BBCode.
seana11 wrote:
MPoupe wrote:
Hello,...

This is repost from http://ourl.ca/12030
Please read it there to see attachments.
For those who can't access linked site, would you mind providing updated information and mirror links for us?
Ashbad wrote:
For those who can't access linked site, would you mind providing updated information and mirror links for us?

Probably most interesting may be the sources of the simulator. I released them with cgplayer at http://martin.poupe.org/casio/cgplayer/index.html

Please can you explain me what is the problem between omnimaga and cemetech ?
Why are there banned users on omnimaga (I tried anonymous access and it worked) ?
I think it is better to discuss on one place and not to duplicate everything on multiple servers (my personal opinion).

I personally slightly prefer omnimaga, because I can attach files directly to the post and archives can be in any format. Here in cemetech one must use zip (I use rar or 7z by default, but no problem), but the file has to be submitted in archives. This is useful for releases, but not for application preview.
MPoupe wrote:
Please can you explain me what is the problem between omnimaga and cemetech ?
Why are there banned users on omnimaga (I tried anonymous access and it worked) ?
I think it is better to discuss on one place and not to duplicate everything on multiple servers (my personal opinion).

I personally slightly prefer omnimaga, because I can attach files directly to the post and archives can be in any format. Here in cemetech one must use zip (I use rar or 7z by default, but no problem), but the file has to be submitted in archives. This is useful for releases, but not for application preview.


Thanks for the link Wink As for the banned users, it's generally a long and painful story, so it'd be best not to go into details here. Essentially, though, there are a few members here who can't access Omnimaga at all because they are IP-banned, which being an anonymous user doesn't fix. As for uploading attachments on cemetech, perhaps consider DropBox or MediaFire as a replacement?
Ashbad wrote:

Thanks for the link Wink As for the banned users, it's generally a long and painful story, so it'd be best not to go into details here...

Sad story...
I program calculator for fun only, so I do not understand why this could happen Sad

I will probably use my own server for attachments Wink
MPoupe wrote:
Ashbad wrote:

Thanks for the link Wink As for the banned users, it's generally a long and painful story, so it'd be best not to go into details here...

Sad story...
I program calculator for fun only, so I do not understand why this could happen Sad

I will probably use my own server for attachments Wink


Indeed it is, but on another note, awesome, and thanks for the consideration Smile
In general, we prefer not to discuss site relations on the forum to avoid any possible fights that could arise, but I will address your concerns with the caveat that after this post we keep discussion about your debugger rather than any site issues.

MPoupe wrote:
Please can you explain me what is the problem between omnimaga and cemetech ?
Why are there banned users on omnimaga (I tried anonymous access and it worked) ?
This is an incredibly long history, and not really worth getting in to. As for why there are banned users, it's generally because those users disobeyed the rules of the forum either often enough or in an egregious enough way that they were banned. Cemetech and Omnimaga have different rule structures and different disciplines, so there tend to be different users banned from the two places.

MPoupe wrote:
I think it is better to discuss on one place and not to duplicate everything on multiple servers (my personal opinion).
That certainly would be ideal--unfortunately people thrive in different environments, so it would be impossible for there to be a single place where everyone could go and be comfortable.

MPoupe wrote:
I personally slightly prefer omnimaga, because I can attach files directly to the post and archives can be in any format. Here in cemetech one must use zip (I use rar or 7z by default, but no problem), but the file has to be submitted in archives. This is useful for releases, but not for application preview.
My understanding of requiring zips is that it standardizes our archives. If you use rar, someone might not be able to open that, and we'd rather everyone use the same format so that we don't get people either a) mad at us and blaming our archives or b) making redundant posts about how they can't open the files. As for attachments on the posts, we prefer to keep our footprint small, I feel, and having the option to add attachments could grow the database immensely. Keeping them in the archives allows for updates, so that there aren't 10 posts on one topic with attachments each one a different version, each one taking up a bunch of space. My solution (as you've mentioned) is to just host it on my server. While not everyone has a server, there are plenty of hosting solutions available, and I think using those makes more sense than us adding that functionality (though, that's obviously an opinion, and it the other opinion is just as valid).

I hope that clears up any questions you have. If you have more or want more specifics, feel free to send me a PM and we can discuss it.
Merthsoft, thanks for those eloquent and concise statements of our policies with regards to all of those points. For the first point, I think it bears clarification that many of those bans were decried as on the (unfair) whim of one or more staff members, though the environment has since changed. As Merthsoft points out, the audiences at Omnimaga and Cemetech are quite different, and for the cohesion of both sites, it's best that they remain distinct to cater to those very different groups.

Anyway, getting back to the subject at hand. I'll try to get a chance to poke through your sources at some point in the near future, but I also have a handful of questions. It seems that you must have had to re-write the functionality of a substantial number of system calls, for which I salute you. Is this indeed the case? How difficult would it be for you to build a tool to let the PrizmSDK build both Prizm and (simulator) binaries at the same time, or is this not as simple as it sounds?
KermMartian wrote:


Anyway, getting back to the subject at hand. I'll try to get a chance to poke through your sources at some point in the near future, but I also have a handful of questions. It seems that you must have had to re-write the functionality of a substantial number of system calls, for which I salute you. Is this indeed the case? How difficult would it be for you to build a tool to let the PrizmSDK build both Prizm and (simulator) binaries at the same time, or is this not as simple as it sounds?


If you check the source, you will see that I rewrote few syscalls - just the minimum to be able to test my program. But I think extension will be easy, because the base is done (LCD + keyboard). Check it.

I think it could be done that way (to make 2 targets: addin + win32 simulated application). But unfortunately I cannot use PrizmSDK, the last part (bin to addin converter ) crashes. So I use Simon's MiniSDK.

The CGPlayer is not well done, I wrote it for simulator (with some usage of win32 functions) and then copied to another place and fixed for Prizm. It is visible in the package.
CGDoom follows your idea more, the sources are really shared. I would like to share the sources with somebody, who will help me, but it seems nobody is interested in CGDoom development Sad
MPoupe wrote:

but it seems nobody is interested in CGDoom development Sad


I speak for myself: I'm quite interested in what may come out of that development effort. And speaking for the community, I believe most people are, too. I'm only unsure if there are many people interested in actually helping with the development (I don't remember if you shared the sources here on Cemetech or not).
MPoupe wrote:
But unfortunately I cannot use PrizmSDK, the last part (bin to addin converter ) crashes. So I use Simon's MiniSDK.
I'd love to know what it says (and perhaps what you're telling it to do) so I can fix whatever the problem is...
Tari wrote:
MPoupe wrote:
But unfortunately I cannot use PrizmSDK, the last part (bin to addin converter ) crashes. So I use Simon's MiniSDK.
I'd love to know what it says (and perhaps what you're telling it to do) so I can fix whatever the problem is...
Indeed, we can't fix a bug that we don't know about. Wink And regarding CGDoom, I thought there was actually a great deal of interest in the CGDoom thread here on Cemetech about it becoming a more mature game...
Tari wrote:
MPoupe wrote:
But unfortunately I cannot use PrizmSDK, the last part (bin to addin converter ) crashes. So I use Simon's MiniSDK.
I'd love to know what it says (and perhaps what you're telling it to do) so I can fix whatever the problem is...

Command line:
../..//bin/mkg3a.exe -n :DEFAULT cgdoom.bin cgdoom.g3a
make: *** [cgdoom.g3a] Error 128

Messagebox:
Application popup: mkg3a.exe - Entry Point Not Found : The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll.

mkg3a.exe size:91648
mkg3a.exe date:Thursday, 19.May 2011, 5:35:52

KermMartian wrote:
Indeed, we can't fix a bug that we don't know about. Wink And regarding CGDoom, I thought there was actually a great deal of interest in the CGDoom thread here on Cemetech about it becoming a more mature game...
I mean my latest post in that thread which remains unanswered.

gbl08ma wrote:
I speak for myself: I'm quite interested in what may come out of that development effort. And speaking for the community, I believe most people are, too. I'm only unsure if there are many people interested in actually helping with the development (I don't remember if you shared the sources here on Cemetech or not).

I released source code, check the CGDoom thread .
MPoupe wrote:
Application popup: mkg3a.exe - Entry Point Not Found : The procedure entry point DecodePointer could not be located in the dynamic link library KERNEL32.dll.
Looks like this is because you're running an old version of Windows (EncodePointer/DecodePointer are only supported since XP SP2). On my end, I have to build with VS2008 or older to make it not do that. Confused

I'll try to put up a "fixed" binary later tonight. Out of curiosity, what kind of machine are you running this on that has such old software?
Tari wrote:
I'll try to put up a "fixed" binary later tonight. Out of curiosity, what kind of machine are you running this on that has such old software?

A7N8X Deluxe + AMD Barton 2500+@950MHz, 2GB RAM, ...
XP SP1 + VS 2003
I is much faster than my PC in work (Intel I7 2.9 GHz, 12 GB RAM, windows 7x64) in operations like boot, run application, show context menu, etc.

BTW: how do you use DecodePointer() in mkg3a ?
MPoupe wrote:
I is much faster than my PC in work (Intel I7 2.9 GHz, 12 GB RAM, windows 7x64) in operations like boot, run application, show context menu, etc.
In my experience, this is usually because companies like to load their machines down with poorly-written software. Wink

MPoupe wrote:
BTW: how do you use DecodePointer() in mkg3a ?
I don't, directly. The C runtime library used by VS2010 uses it for something, hence I need to build with VS2008 or older to avoid this problem.
I didn't get to rebuilding it for you yesterday, but hopefully tonight I will.
Tari wrote:
In my experience, this is usually because companies like to load their machines down with poorly-written software. Wink
I think developers should test their SW on very old / slow computers and optimize what is cheap and easy to optimize.

Tari wrote:
I don't, directly. The C runtime library used by VS2010 uses it for something, hence I need to build with VS2008 or older to avoid this problem.
I didn't get to rebuilding it for you yesterday, but hopefully tonight I will.
Thank you, no hurry is needed Smile
BTW: do you know if the Prizm SDK compiler supports 64 bit integer (emulation) ? I tried it (variable of type long long) in MiniSDK, but it didn't compile.
MPoupe wrote:
BTW: do you know if the Prizm SDK compiler supports 64 bit integer (emulation) ? I tried it (variable of type long long) in MiniSDK, but it didn't compile.
Yes, that's provided by GCC. If I'm remembering correctly, it also provides floating-point emulation (though I haven't personally tried it).
Tari wrote:
Yes, that's provided by GCC. If I'm remembering correctly, it also provides floating-point emulation (though I haven't personally tried it).
Super, so CGDoom will be faster, because there is a lot of 64 bit multiplication / division and my implementation was safe, but not fast Smile
  
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 2
» All times are UTC - 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