I was trying to convert a 208x44 monochrome image. Not even twice the size of the screen. And last time I was trying to convert an image that was just 4 times as large as the screen but still smaller than once the size of an Nspire screen, even forgetting the fact that my image was saved in 8 bit format to save space while an Nspire image would probably be saved in 16 bit format.

For the second image, I was able to split it in 4 times 96x64 but I still used at least as much processor power as if the image was converted in one pass, and this can not be done so easily with dimensions such as 208x44. Not impossible of course, but a lot more annoying (because I need to interlace the produced hex codes, not just copy paste one beneath the other).

Yes, I certainly see your point about that. How do you feel about me making the limit 320x240 for logged-in Cemetech members? Would that fit all of the images you need to convert in the foreseeable future?

Well I can't tell about the future
However, while I agree that 320x240 would be a great improvement and probably enough for my z80 needs, I thought about something that could be done. Would it be possible to have the restriction be based on size in bytes or pixels instead of dimensions ? I mean that instead of limiting to 320x240, you could limit to 76800 pixels. This way, people can also make images wider than 320 (but less high) or higher than 240 (but less wide), without wasting excessive power. And for huge images, there is still the possibility to split them into smaller images that have the right width.

For an update to SC3, I'd like to recommend a text adjustment on the main menu:

Under Casio, it says: "Casio Prizm BASIC: .g3m and .g3p"

I'd like to recommend removal of Prizm, or adding of the other fx models, and adding of the g1m file type being listed, please I'd do it myself, but I don't have that level of access.

I updated it to the following. Thank you for the suggestion, sir.

Thanks for modifying so quickly.

My pleasure; I appreciate your ongoing help in getting SourceCoder 3 to be even more powerful and featureful. Speaking of which, does this decoded .g1m picture file that I rendered match the original, including the solid black line at the right edge, or are there errors?



Edit: Turned out the answer was "yes". The photographs from tifreak8x and his fx-9750gII below show that SourceCoder 3 is now able to both import .g1m monochrome picture files and export the same files for display on-calculator. Unfortunately, it appears that the last row of these images is ignored, as on the TI-83/+/SE and TI-84+/SE calculators. As with the .g3p format, I will be documenting the .g1m picture format when I get a chance.

Congrats on getting yet another format working in SC! I look forward to a day when SC3 handles all calculator formats that jstified can emulate calculators of

Thank you! One of the things I've noticed is still missing from SourceCoder 3 is the ability to import one calculator picture format and immediately export into another calculator picture format; I didn't realize that was missing. Other than that, which calculator formats do you find particularly lacking?

Well, there is more than just the .8xp format, the 83 format is nearly identical, is it not? I'd really just like to see SC be able to handle all the calc types, 73 through 68k, though I know that's tantamount to a mountain of work. Pretty sure we have fully working xmls for the 73 and 82, though, already in Tokens, so that'd take most of the work out of it, wouldn't it?

It's a mountain of work whenever we need to create a new token file (or cut down an existing token file) for a particular model. The other half is building the file parsers and generators to understand and produce the tokenized files with their headers and footers It would take most of the work out of it. Unfortunately, I don't seem to have those XML files.

Pretty please Kerm? Just had to split my large CSE image up into smaller chunks in order to convert them. It is very useful if you just want to display a single-color image depending on the order of bits. The z80 monochrome image converter is really useful for this.

What size images are you dealing with?

Oh, they weren't too big, only about 208x32 pixels. The only problem was that the width was way to big.

Bug (I guess)
I'm not able to select text in SourceCoder on Android.
Browser: Chrome
The default browser works but I can't select by long press (I use keyboard shortcuts).

Wait, for CSE images? It should accept up to 320x240 for converting CSE images, unless I misunderstand you.

Hmm, that's weird. Can you place the cursor and then drag the selector handles to select text, or does that not work either?

That doesn't work because I can't get the handles. There is only the middle cursor selector.

No, I have these images stored as 1 bit per pixel. So it's basically a one bit per pixel any size sprite routine for the CSE; so that way I can output 8 pixels (Pretty much any color, actually, as long as I set the high and low bytes separately) with just one byte. The converter is very useful for this, as it outputs the monochrome image, which is one bit per pixel. Hopefully that explains it somewhat...

Oh look, I was the last one to post here as well.
Anyhow, It would be usefull if SourceCoder could support images that need to be encoded in 4-bit BCD, such that numbers $0-F represent a palette index. That way many more colors are available in pallets, and you can get better compression for images. I know that this isn't really important, but it would be a nice feature.

Sometimes, when changing back and forth between multiple programs in SC, one of the programs will be completely replaced with another. It happened a few times already and I lost a lot of changes because of it.