I don't care if this is technically a necropost, this needs to be bumped. It's a pretty awesome tool that Axe developers should know about and I'd love to see it improved even more.
Yeah, it uses a lot of processing time. Perhaps I should've mentioned this somewhere, but updating the screen at 60Hz drops the effective CPU speed down to only about 33%, so 2MHz for Normal and 6MHz for Full.
Are you sure it actually crashed? The contrast settings wrap around, so it seems likely to me that you may have wrapped around from the darkest to the lightest setting, making the screen look blank and as if the calculator crashed.
I installed 2.43 and the fast flash mod on my 84+SE, and I could perfectly replicate the instant goto symptoms reported by the other two users of 2.43 and the fast flash mod. The issue seems to be specific to the 2.43 version of the patch.
Also, the fast flash mod seems to really conflict with zStart, at least on 84+ calculators. This often means that the OS will crash upon startup if run on RAM clears is enabled. If it isn't enabled, opening the zStart app will often either freeze, crash, or let you in only to reveal that the settings are mostly random garbage. This doesn't seem to be specific to any particular OS.
EDIT: And yes, I've been able to replicate both of these in Wabbitemu.
I am now fairly sure that this patch has at least one negative side effect. I have reports from two users of this patch that, with it installed, scrolling to errors from Axe results in garbage being displayed, corruption of RAM, and possibly other issues (now that I'm testing it again in Wabbitemu, the OS will not boot after the issue occurs). After a short amount of testing, it appears that the error can be triggered not just by instant error scrolling from Axe, but also from DoorsCS. The OS version may or may not matter; both users who reported the issue use 2.43.
I'm just going to pop in here quickly and say that, if you try to wrap the OS inside your own program or recreate a homescreen-like experience, you're probably going to have a hard time (especially using Axe). The second option of minimally recreating the homescreen experience is probably more feasible than the first, but it would still be tough.
This looks awesome! Now if I only knew how to use it...
Well, try perusing the commented version of GrayLib with some computer 8xp viewer and check out the option constants and functions, which should all have comments explaining what they do. Also, check out the examples I provided, which should show a few examples of how a program interfaces with the library. If you have questions after that, I can answer them here.
Wait so it's written in Axe ? I thought it was an Axiom. Awesome job Runer !
Axioms unfortunately don't offer the customizability that can be achieved by using constants as options, which is why I chose to go with a regular Axe library. Almost all of the code is actually Axe and not assembly anyways.
The latest version is attached at the bottom of this post.
GrayLib v1.0
== BASICS ==
What is GrayLib? GrayLib is an Axe library, designed for Axe 1.2.1, to provide nearly perfect grayscale and tons of useful related functions to Axe programmers with extensive customizability.
== FEATURES ==
Tunable crystal timer-based grayscale for non-83+ calculators. Nearly perfect!
Tunable slower hardware-timer based grayscale as a fallback for 83+ calculators. Still looks very good!
Supports either 3-level or 4-level grayscale.
A buffered approach to avoid any frame mixing when rendering new frames.
Automatic setting loading and saving from/to an archived variable.
Includes a default contrast and grayscale timing tuner which can automatically start on the first run.
Masked sprite drawing for both 3- and 4-level grayscale. (Axe's built-in Pt-Mask() command can only draw to a set buffer pair, which is no good for a buffered approach)
Text routines to print integers, tokens, strings, and characters in any foreground/background grayscale color combination.
Support for hooks in the grayscale update interrupt, which can optionally replace the default grayscale update command.
Support for using getKey like normal, despite the OS interrupt not running.
== EXAMPLE PROGRAMS ==
To get a basic idea for how to use GrayLib, I have created a few example programs. One is a very basic wrapper for the default tuner, one is a screensaver-style bouncing text program, and one is a fairly complicated recreation of the movement engine from the first-generation Pokemon games, set in Pallet Town. Every example program comes in two forms: a smaller version, which contains just the code, and a larger "Commented" version. The commented versions contain detailed comments explaining exactly how each piece of the code works, and can be good resources for both learning how to use GrayLib and simply learning Axe coding approaches and tricks.
Spoiler For Animated screenshots!:
83+
84+
GRAYTUNE
GRAYTUNE
GRAYTEXT
GRAYTEXT
GRAYPKMN
GRAYPKMN
They look less flickery on real calculators, although more blurry.
== LEARNING TO USE GRAYLIB ==
GrayLib itself also comes in a small version and a commented version. The small version is good to store on your calculator if you don't need a reference on your calculator about how to use the library. Whether or not you want to store the commented version on your calculator, THE COMMENTED VERSION IS CRUCIAL TO LEARNING THE MYRIAD OPTIONS AND COMMANDS IN GRAYLIB.
== FEEDBACK ==
If you have any questions, comments, concerns, feature requests, or bug reports, make a post here and I (or somebody else who knows the library) will try to reply as soon as possible!
Oh sorry I forgot to reply. It works perfectly now.
Edit : Nope, the patch doesn't do anything. It installs fine but nothing happens on RAM clears.
I have the same results. zStart 1.3.012's run on RAM clear functionality doesn't seem to work, at least on Wabbitemu (OS 2.55; older versions work fine).
I also come bearing other gifts:
Bug reports:
When MathPrint is enabled, any of the shortcut key actions used from a menu eject control back to the home screen.
When uninstalling the run on RAM clear functionality finishes, "No" is printed over "Yes". But no erasing is done, so you end up with "Nos". A simple fix for this would be to append a 3-wide space (character code $EE (could a small font hook with a wider "s" ruin this fix?)) to the end of the "No" string.
The "Select font" option sometimes says "No" when no font is selected, but other times is just blank. I suspect that one of these behaviors is a bug. If showing the string "No" was the intended behavior, may I suggest a slightly more fitting string, like "None"?
Bug report/feature request hybrids:
Shortcut key actions do not work in contexts other than the home screen. This includes menus launched from these contexts.
A common, minor oversight of many programs/apps: if you use plotSScreen, you should mark it as dirty with set graphDraw,(iy+graphFlags).
Feature requests:
A negative feature: remove the confirmation on setting shortcuts? I don't think I've ever accidentally hit any of those shortcuts, so the confirmation seems a bit unnecessary to me. If you do want to keep them in, though, it wouldn't bother me much. But if you do, can you display some text between "Confirm" and "Set" (perhaps "Working..." or "Setting...")? On my calculator, the option setting/saving process takes about 4 seconds. It may take a non-trivial amount of time on others' calculators as well, and during this time, the calculator appears frozen.
A shortcut to toggle MathPrint.
Here's a big (code size-wise) one that probably isn't super important, but would be neat if it existed: instead of having individual options to control a few defaults, include an option that saves basically all settings as defaults (everything currently available and everything in MODE). If you were crazy enough to add this, you might also be crazy enough to be interested in adding a second option that does the same for the WINDOW and FORMAT settings.
Hmm... being able to see the real code could be helpful. I believe there are some copying errors in that code, like the size argument of GetCalc() being inside the quotation marks and the value outputs all overwriting each other. But even with these errors fixed, I don't see anything critically wrong that would be causing what you got.
Axe libraries are fully recompiled everytime you compile a program that uses them. It can often take over half the time needed to compile the program. Therefore, it would be nice if there was a way to precompile axe libraries (maybe into axioms?), to decrease the time needed for compilation.
Show Posts
I thought it was an Axiom. Awesome job Runer !
It works perfectly now. 