Tari, how hard would it be to have mkg3a support images that are already in the RGB565 format so that one could use another program to do the conversion or so converts from one of the other SDK's could just drop in their existing images?
Should be trivial, depending on how exactly the image is formatted. Should just be a matter of skipping the bitmap decoding step and dumping file data into the output.

I suppose there's probably room in my toolkit (along with g3a-icodump) for something to convert arbitrary images to binaries fit to objcopy into your code.
TheStorm, the other SDKs require you to somehow already have RGB565 images? I'm quite surprised to hear that. Sad I wonder if there's a way I can easily make SourceCoder output RGB565 binaries instead of its current hex text output, although using mkg3a normally obviates that, I suppose.
Since Jonimus was building a new SDK release on Kerm's prompting (mostly with upgrades to libfxcg), here's a newer build of mkg3a, too.

Identifies itself as version hg f4f61a7ef3c9, implying I didn't build this from a tagged release, which means it's less tested than usual.
The changes since 0.1e mostly involve compatibility when building with clang and cleaning up the bitmap loader to be easier to shoehorn into other utilities (such as the RGB565 dumper mentioned above that I never got around to implementing), so I don't expect there should be any regressions.

Same download link as usual: http://media.taricorp.net/mkg3a.exe
Superb, Tari; thanks for your continued work. Thanks also for letting me know about the -n basic:AddinName method of setting the default Add-In name for every language. Smile
Since Kerm was sad that I didn't tag the tweet with #cemetech, I've been working on adding PNG support for icons.

Still working out the bugs, but if you want to watch it error out when loading a png (the bmp loader still works fine), update to the png branch in hg. And in case you want to build a stripped-down version of mkg3a, it's possible to disable the PNG loader (thus removing the libpng dependency).

Note to self: add stuff to the version output to indicate the version of libpng in use.
Meet version 0.2a. This adds PNG icon support so everybody can stop throwing around pointlessly large image files. As usual, there's a static windows build on my web site (much larger, now that it packs libpng and zlib), or you can check a copy out of Mercurial for yourself.
Windows binary: http://media.taricorp.net/mkg3a.exe
Source repository: https://bitbucket.org/tari/mkg3a/

Project page is at http://www.taricorp.net/projects/mkg3a/, BTW.
For anybody looking to build it themselves, it's a huge pain to do on Windows. I wrote up some notes on getting CMake to find all your packages and getting libpng and zlib compiled. It should work without intervention on most sane (non-Windows) systems.

Since this is finally working, I can re-enable the convert565 utility and construct some scripts for embedding images straight into your binary without dumping them into the source code. Such a feature will probably warrant a new SDK release. From there, I hope to do some work on an image compression library.
I made a PKGBUILD.

One other thing I need to do before the next release (after the image embedding helpers): finish writing the manpage.
Minor bugfix today per silliness with PNG color depth. Since the error messages from that failure were a bit odd, I also changed how it reports errors while parsing options.

My Windows binary has been updated to version hg 3ddb31682058, I don't see much reason in tagging a release just for this fix.
The latest mkg3a is telling me that it's reaching an unexpected EOF for both of the .bmp icons Graph3DP uses. I tried re-saving them as 8-8-8 BMPs with GIMP, but the error remains. This didn't happen with an older, November 2011 build of mkg3a that I had.
Hi Tari!

Today I made some modifications in your mkg3a project. Now, it's possible to set the version of an addin. It would be great if you would integrate my code to your project.

My changes are:

Added to g3a.h:
Code:
void g3a_fillVersion(struct g3a_header *h, char *version);


Added to g3a.c:

Code:
void g3a_fillVersion(struct g3a_header *h, char *version) {
   strncpy(h->version, version, sizeof(h->version) - 1);
}


Modified in g3a.c (in g3a_mkG3A):

Code:
...
header = g3a_mkHeader(1);
    if (header == NULL)
      return 1;
    g3a_fillSize(header, inSize);
    g3a_fillCProt(header);
    g3a_fillIcons(header, icons);
    g3a_fillVersion(header, version); //  <---- NEW LINE
...


Added to main.c:

Code:
int storeVersionSpec(char *k, char *v, void *dest) {
   unsigned int i;
   if(!strcmp(k, "version")) {
      if(strlen(v)!=10){return 1;}
      char d[8] = {0, 1, 3, 4, 6, 7, 8, 9};
      for(i=0;i<8;i++){
         if('0'>v[d[i]] || v[d[i]]>'9'){return 1;}
      }
      if(v[2]!='.' || v[5]!='.'){return 1;}
      memcpy(dest, v, 10);
   }
   return 0;
}


Modified in main.c (in main):

Code:
...
   struct lc_names names = {{{NULL}}};
   struct icons icons = {{0}, {0}, {0}};
   char version[] = "01.00.0000"; //  <---- NEW LINE

   while ((c = getopt(argc, argv, ":n:i:w:hv")) != -1) { // <----- "w:" characters added
      switch(c) {,
...
      case 'w': //  <---- NEW LINE
         if (splitAndStore(optarg, &storeVersionSpec, version)) //  <---- NEW LINE
            errors++; //  <---- NEW LINE
         break; //  <---- NEW LINE
...
Added. Your patch was incomplete, but there were a few changes I wanted to make anyway.

https://bitbucket.org/tari/mkg3a/commits/66cf3e92599bbe0fb7ea590f9296f80f3303c573
OK, thanks for adding
Finally, Simon figured out what those two bytes at 0x16 in the .g1a/.g3a header mean.

It is a word sum of 8 words starting at offset 0x300 in case of a .g1a header or at offset 0x7100 in case of a .g3a header. Also remember that bytes from 0x00 to 0x20/0x30 are usually inverted.

Example:

Code:
Conv.g3a (0x16 : C907)

0x7100 :
7B01 + E720 + E506 + 66B3 +
4A0B + E401 + 7F04 + DC0E = 36F8

36F8 xor FFFF = C907
I wonder what's the point of having those two bytes there, if the OS doesn't care about them (or does it?).

I also know how to enable strip support (see my Image Viewer and Eigenmath port). I should probably post my modifications here so that Tari can merge them, and so that I can stop using my hackish mkg3a builds based on old code. (I also added code for specifying the version string, without having noticed balping had done it already, and since my builds are not based on a git repo, it's now really hard to track the changes...)
The fx-9860G SDK emulator checks these bytes.
But they are not checked in the normal fx-9860G and Prizm OSes - at least for add-ins. So they may be checked in other formats or in future OS versions.
gbl08ma wrote:
I also know how to enable strip support (see my Image Viewer and Eigenmath port). I should probably post my modifications here so that Tari can merge them, and so that I can stop using my hackish mkg3a builds based on old code. (I also added code for specifying the version string, without having noticed balping had done it already, and since my builds are not based on a git repo, it's now really hard to track the changes...)

Dear Tari, would the above be possible please from you, maybe also with the ability to control those 7th and 8th locales for add-in names just in case please?

I also noticed that if I don't specify basic name (maybe only sometimes or maybe because of some overblown makefiles - I have not been checking all my g3as in hex editor) it puts my project directory in like C:/CASIO/projects/... at 0040 address and that is what then is used in calculators main memory for saving variables or similar (when viewed via INSIGHT MCS viewer). Obviously it is controllable by adding basic name so just in case you are releasing a new version...

Other small issues for me were if I want to specify French lowercase e-acute for example - I have not found the way to make it work with mkg3a - if I use hex code E9 it compiles but does not display properly on the French main menu, I believe Casio expects E60A as a hex code but I believe 0A part breaks the makefile making it think it's a line break or so - so I wonder if there is a way around or if it would be possible to feed mkg3a with lets say E9 as a hex code for the character and mkg3a converting it into E60A or whatever casio likes in their header for this?

Many thanks for developing this tool
Hi again, I started working on Pokémon add-in for Prizm and was hoping you could help with the above issue with é please - to make it slightly easier for me to print the correct name on the add-in icon if you know how to fix it in your mkg3a tool directly please. Thanks in advance for looking into this for me.

One problem I also have when trying to include many (like 150+) sprites of pokémons is the following error please:

Code:
c:/users/myself/onedrive/prizmsdk/bin/../lib/gcc/sh3eb-elf/4.6.0/../../../../sh3eb-elf/bin/ld.exe: C:/Users/Myself/OneDrive/PrizmSDK/examples/Pokemon/Pokemon.bin section `.rodata' will not fit in region `rom'
c:/users/myself/onedrive/prizmsdk/bin/../lib/gcc/sh3eb-elf/4.6.0/../../../../sh3eb-elf/bin/ld.exe: region `rom' overflowed by 252656 bytes
collect2: ld returned 1 exit status
make[1]: *** [C:/Users/Myself/OneDrive/PrizmSDK/examples/Pokemon/Pokemon.bin] Error 1
make: *** [build] Error 2

is it because of the actual limit set by prizm architecture (and what is it - maximum add-in size etc) or something hard coded in mkg3a
Also if the above limitation is necessary what would be the best work around if possible please.

Thanks again
This isn't mkg3a complaining, it's the linker. I don't know what the actual limits on binary size are, but you're 256k over the 1M limit set in the linker script. Either increase that limit (and let us know what values you can verify work) or find ways to make your data smaller.

For encodings, it's still mostly an environment problem; mkg3a just grabs bytes you supply. If you have an appropriate shell, (sh or compatible) octal escapes should work (\0346\012 I guess). Or just patch the binary after generation, I guess.
Thanks Tari for both answers, much appreciated - I will look into this when back at the computer
  
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 4 of 5
» 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