I have a program that is named programCREDITS for a TI-84+CSE. I call this program from another program as such:

Code:


After having some trouble with TokenIDE changing prgmCREDITS to prgmCRedITS (due to the color command), I switched to Sourcecoder.
In Sourcecoder it reads it as the same. However when I transfer it to jsTIfied, it changes the name. In the program menu, the name is C(uparrow)BITS. When I try to run this from the homescreen it changes again to prgmC?BITS.

I have a feeling this is something like the PVPCRAFT bug.

Yes, it's extremely similar. Call it via "prgmCR\EDITS" in the code you've listed there.

I am sorry if I was misleading with the code I posted above. The problem is not with the actual code. Rather it is with the actual program name of prgmCREDITS.

I tried the above suggestion of adding the backslash and I still get the error message: ERROR UNDEFINED

You'll need to both change the name of the program to CR\EDITS in the name input box, and call it via prgmCRE\DITS (or CR\EDITS) in the parent program. I will soon get to implementing the more limited name tokenizer that will prevent this problem.

That fixed it. Thanks!

Source Coder 3 doesn't seem to want me to edit files. This is the same Google Chrome that has trouble with jsTIfied.

Can you tell me more about this bug? I assume the jsTIfied issue you refer to is the misaligned screen?

*bump* Did you ever find out more about this?

In other news, thanks to tifreak8x's work on his Age of Darkness Prizm Edition work, the support for ordinary and unusual Casio Prizm tokens in SourceCoder 3 is drastically improving. Please feel free to use SourceCoder 3 for your own Prizm programming work (you can import, edit, and export programs), and let me know if you run into any problems. I'm also strongly considering supporting older fx9860 (.g1m) programs.

I, for one, would be grateful for our g1m's overlordiness.. rule? That doesn't sound right..

Anyways, I'd be happy if .g1m would be supported I'd like to figure out which calc uses the g2m format so I can get one of those and see what format that setup has in its header.

What would be cool is the ability to convert PNG/GIF/BMP files to FX-cg10/20 g3p files. I mean the low color ones that can be drawn directly on-calc that are like 84+CSE 8xi files, not the cg20-only files that are like 8ci files.

Some PRIZM BASIC programmers would probably like to have nice looking pictures in their games then have minimal movement during gameplay, but by using the 8 color files so that they can make their games run on the American models at the cost of having 8 colors instead of 65536.

Examples of pics that could probably be displayed on the calculator:

Can you either point me at format information about those files or send me a few samples along with PNGs of their contents? Thanks!

I do not have any info about the format and I think nobody ever bothered to look at it, but I got two samples below (copy URL in address bar):

http://www.omnimaga.org/pixel-art-and-drawing/mockups-'please-say-this-is-going-to-be-a-game'/?action=dlattach;attach=16815
http://www.omnimaga.org/pixel-art-and-drawing/mockups-'please-say-this-is-going-to-be-a-game'/?action=dlattach;attach=16816

I posted those for fb34ca9 months ago, because he wanted to look at the format, but he sadly vanished shortly afterward.

*bump* Based on those files and a few days of reverse-engineering, I succeeded in determining the obfuscation method used to hide the image data within the files. I have been able to parse the 3-bit-color g3p images, which for now allows SourceCoder to render them as images on a computer:



My next steps are as follows:
(1) Get SourceCoder to parse and display the contents of "full-color" picture files.
(2) Reverse-engineer the signatures and checksums used to verify that an image is valid.
(3) Check that a Prizm will accept these images, both for 3-bit and 16-bit images.
(4) Post a topic on Cemetech and discuss the moral and ethical implications of releasing this feature
(5) Release this SourceCoder feature, if the community decides that the ongoing lack of response from Casio as well as the ability of the TI-84+CSE to display full-color images and detailed non-full-color images means that no major detriment would come from making this tool available.

Looks awesome. I honestly don't think Casio is going to throw a huge fit over it, but I really wouldn't be one to say. They've obviously seen what we've done with creating an sdk trying to make our own C programs for the prizm. IF they had a real problem with us doing things for their calcs, I'd have thought they'd lock it down by now.

Good job so far Kerm.

Regarding the 16 bit images conversion, this might be controversial because this would circumvent Casio's protection against loading third-party images on American models. If possible, you should make 16-bit pictures cg20-only.


However, the 3-bit image format is not limited on any calc model. I can create/store/reload them perfectly fine on my cg10 with no modification in every OS, via the Sketch tools and the StorePict/RecallPict commands. It's just that creating the images directly on-calc takes an outrageously high amount of time (if I estimated correctly, the non-Zelda RPG style mockup I posted above would take approximately 2 hours to render via BASIC code). I don't see why 3-bit image conversion should be a problem, considering none of the calcs have limitations against that format.



For the time being, if I was you, I would only make 3-bit conversion public and perhaps cg20-only 16 bit conversion.



Suggestion: For 3 bit image viewing, try to add a SourceCoder feature allowing the user to view the images in true PRIZM colors if he checks a box. On the PRIZM, green is much darker than on the computer so maybe the user would like to see the result as it looks on calc.

Yes, I believe that's accurate. On the other hand, my change of opinion is actually due more to the new offerings like the Prime and the TI-84+CSE from the other manufacturers and the fact that they can load arbitrary picture files in the US.

I'm considering that. That's why I will open up a discussion after I finish figuring out the checksum format.

See gbl08ma's post about this.

Unfortunately, that's the fault of the (older?) calculators' LCD rather than the color values that the OS stores for each color index. What SourceCoder shows is what the colors are supposed to look like, so I'll probably keep this for now.

Also, after working past a silly error with filesize assumptions, I got 16-bit images to be parsed:

Strange, I didn't realize that 3 bit images had the limitation too. I am surprised since I can create them fine on my calc. I hope there isn't something preventing them from being sent to a different calc if created on my calc, though, else I guess then I am screwed x.x.

Unless the community as a whole decides that having SourceCoder generate 3-bit images that work on CG10 and CG20 calculators is okay.

In other news, my investigation of the g3p format and progress in writing Python test code to try to generate new g3p files has led me to find a few inaccuracies in my initial understanding of the g3m format. The inaccuracies have been fixed and pushed to the live version of SourceCoder; in practice, this means that SourceCoder will correctly generate programs (g3m files) with total sizes below 256 bytes and above 65,535 bytes.

Could you please add support for z80 monochrome Axe/Hybrid images that are larger than the screen ?
I don't think the "uses processor power" argument is valid since when I try to parse my image, processor power is wasted by giving me results for CSE and Nspire even though I want it for monochrome z80.

You're right that it would make sense to not produce all of the output formats at once, and instead only generate the specific format that the user might want. How big of images are we talking about? I might consider allowing logged-in users to have a larger maximum image size than guests, since I could keep track of who was issuing jobs with large sizes.