Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
That's very good, ProgrammerNerd, thank you. Jumping by page will be totally useful.

Maybe one day something can be developed to support some type of tags like in html to highlight bits of the text in different colours or sizes and possibly support internal links. Actually what I was thinking of was more of a viewer rather than editor - you are right: the editor should show plain text so that it can be edited like when editing source files. Another application to view the files similarly to like html files are viewed in a browser, or C etc files viewed in a notepad++, and listing XML files like CATALOG on Prizm does would be cool.

Sorry I cannot yet help with coding of any of that. I know you have little spare time so that's just an idea, totally not to pressurise you in any way. Thanks again
Thanks gbl08ma for your reply.

I have to learn about eActivity - is there a convertor from Rich Text format to eActivity format or something I could create eActivity notes with colour etc on a PC please?

You are right about vanity factor - the only good practical use I could see besides whoa factor in what I was suggesting was for a tutor to not have to lean over a student but be able to just see a live copy of the screen on her/his own calculator and vice versa when showing examples to the student. I imagine it won't be easy to achieve given that Projectors and presumably PC are hosting USB connection to calculator and it probably won't be possible to establish such a connection via USB between 2 calculators only. Or am I wrong on that?

Or do you think screen sharing can be done via 3PIN somehow by perhaps dropping colour quality or other tricks?

Many thanks again for your replies and brilliant apps and support
Even if that's not the most on-topic thing, for that said on PC Eact Editor, you may try to have a look here, by choosing the right format, I think it works quite well : http://tools.planet-casio.com/EactMaker/ Wink.
+1 for the EactMaker made by Helder7 (admin of the now-defunct Casiopeia.net website) and Ziqumu. It even allows certain formatting options not available when using eActivity to create the file. Note that it can't edit existing eActivity files, though.

A document system with hyperlink support may be interesting (hey Casio, why doesn't eActivity include such a thing?), but it's probably best as a separate application.

Screen sharing needs software that stays resident on the broadcasting calculator in order to read the VRAM contents. It's not something particularly... safe, nor easy to do. It's what the OS does with the screen receiving function: it installs a timer to send the VRAM over USB periodically while GetKey and a few other syscalls are working. This introduces certain problems, which are why certain file functions are not available when in ScreenReceive mode. Replicating such thing with 3rd party software is going to involve some bricked calculators in the development phase... and we're also yet to know how to unbrick them.
Thanks All, for EactMaker.

gbl08ma - it does indeed sound very advanced for screen sharing and not worth the risk of bricks in particular. Hopefully I stay on the Utilities topic while discussing calculator to calculator communications still: if your Utilities launches Matrix-Run would then what the student/tutor does be possible to be sent to tutors/student screen live or once the built in app is launched even from your add-in you cannot run any screen grabbing in the built-in app...? Or would it be still dangerous even if possible?

If not possible to screen grab the above way would intercepting the file Run Matrix writes also be impossible? Is the file even written until one leaves Run-Matrix? In worst case maybe something like Utilities starts Run Matrix, once the student completed the task or has a question about something, she/he presses a key combo or menu/setup button if it was disabled to return to the Utilities which sends over MMEM/SYSTEM to the tutor. Presumably the tutor then sees it immediately in their own Run-Matrix directly (or in their Run Matrix launched via your add-in if needed for more confirmations who is sending whom etc)

Last thought I have on this - is it possible to fool the hardware into thinking a projector or PC is connected and intercept the broadcast translating to display on the receiving calculator - again just an idea which I suspect may be infeasible...

Thanks again, gbl08ma, I hope some of the above will help you with your excellent work. Sorry if I'm unintentionally wasting your time asking impossible things you already thought of. Let me know what you think
Can I put clock and date on look screen ?
Hi gbl08ma,

I have noticed that OS version reported by Utilities add-in differs from what it is in the native built-in system version ever so slightly - so thought it may help you if you wish to look at it. I understand your add-in uses 0x80020020 address here
Code:
  char OSversion[12] = "";
  memcpy(OSversion, (void*)0x80020020, 10);
  OSversion[10] = '\0';

I managed to match the built in version number using the following address as in the below example

Code:
void getOSversion(char* buffer) {
  // NOTE buffer must be at least 10 bytes long!
  memcpy(buffer, (void*)0x80011AD4, 10);//possibly the same at 0x80629B23
}

I tested the above in the latest emulator version so far. Haven't had time or at least cannot remember testing the above on real hardware yet.

Apologies in advance if your OS version string was meant to refer to something different than what CASIO show natively.
The difference between the OS version is intended. The version displayed by the OS is not really a version but more of a mix between OS and hardware model (the same OS version shows different values depending on the hardware and on whether it thinks it is a CG 10 or a CG 20). Since there is no difference between the OS code in these, it makes no sense to display it (except maybe in the case of the special 01.04 OS for hardware 001V04, I can't remember what is the version it reports at 0x80020020).

@zivtal, there's no way to do that as of version 1.4, sorry.
Thanks for explaining.

By any chance do you know where in memory I can find language versions as displayed by OS please.

On my emulator for example and one of the calculators OS version is 02.00... and if i scroll down languages under Message and Menu say 02.00

but on another calculator OS version is still 01.03 but languages show with 01.01 after

so I'm just wondering where in memory I can find the exact languages versions please.

Thanks in advance
For those interested, here's another video previewing more upcoming features of Utilities v1.5:
https://vimeo.com/121713661

Features shown:
- Password generator
- TOTP authenticator
- New chronometer view screen
- Home panes and shortcuts
- Monthly calendar respecting the "first day of week" setting
- Date selection through monthly calendar on many screens (instead of having to type the date's digits)
- File sorting by type
I made some more refinements to the chronometer view screen.

See if you like how it looks:



The traditional list with all the 20 chronometers in text-only form is still available, of course, and a bit more responsive than this individual view (having to do so many trigonometric calculations on each redraw makes the individual view slower).

The calculator lock function also saw updates. Now locking the calculator takes you to a locked (heh) version of the home screen, which respects all your settings (including the dark theme) but is limited as to not allow any functionality to be used:



After pressing Alpha, one is still prompted for the unlock code, as before.

Chronometer notifications appear on this lock screen as well. Depending on the setting, this could mean no action, a pop-up (flashing or not), or a message on the status bar.
gbl08ma wrote:
I made some more refinements to the chronometer view screen.

See if you like how it looks:



The traditional list with all the 20 chronometers in text-only form is still available, of course, and a bit more responsive than this individual view (having to do so many trigonometric calculations on each redraw makes the individual view slower).

The calculator lock function also saw updates. Now locking the calculator takes you to a locked (heh) version of the home screen, which respects all your settings (including the dark theme) but is limited as to not allow any functionality to be used:



After pressing Alpha, one is still prompted for the unlock code, as before.

Chronometer notifications appear on this lock screen as well. Depending on the setting, this could mean no action, a pop-up (flashing or not), or a message on the status bar.


Good work, gbl08ma, I was also planning to introduce watch and and possibly stopwatch/timer on my Lock add-in but I doubt I will have time to update my add-in before end of July. Thanks for keeping up the development
As people following the GitHub activity may have seen, I have resumed work on Utilities and I'm preparing a final release. Due to the significant amount of changes since the previous release, will most likely be version 2.0, and not 1.5 as previously indicated.

For those of you who are interested in the add-in manager functionality (hide and show add-ins in the main menu without deleting them), I just made an important breakthrough: by modifying the g3a files to make them invalid, instead of renaming them, it appears that the function is more stable. It still causes system errors sometimes, when filesystem optimization is involved. These errors also seem to unmount the storage memory, so a reboot is necessary to restore the full functionality. I am still very worried about the security of this function and it is possible that it will be scraped off in the final release, or be available only on the edition with the PicoC interpreter.
I'm excited about the progress you are making and hope you will continue contributing even after that 'final' release.

Regarding your new trick invalidating the add-ins first - would renaming after this invalidation be safe (and deleting which I believe is one of your functionalities) or will that trigger file system optimization and the problems of the previous approach (which from the hints you gave before seems to only crash when renaming add-ins which appear on the main menu before the actual utilities add-in)?

Thanks for all your work and kind regards,

A~nka
I am not sure, as right now no renaming is performed - files are just made invalid by changing their contents in a coherent way, such that they can be changed back to re-activate the add-in.
The way the OS decides to flush the TLB (which is the action that makes the running add-in stop working) or not is quite complex, it appears to check whether any g3a changed position in the flash (e.g. due to optimization), and refreshes the memory mappings in such a way that the running add-in is only affected sometimes. This is pretty much impossible to prevent or foresee, as far as I know, so there's not much to be done.
gbl08ma wrote:
I am not sure, as right now no renaming is performed - files are just made invalid by changing their contents in a coherent way, such that they can be changed back to re-activate the add-in.
The way the OS decides to flush the TLB (which is the action that makes the running add-in stop working) or not is quite complex, it appears to check whether any g3a changed position in the flash (e.g. due to optimization), and refreshes the memory mappings in such a way that the running add-in is only affected sometimes. This is pretty much impossible to prevent or foresee, as far as I know, so there's not much to be done.

Hi gbl08ma, I have an idea but have not tested it for renaming purposes yet - if the utilities were to be run from the strip in eactivities would it not eliminate crashes when renaming? If so maybe having a warning to run renaming and similar from eactivities when the add-in is detected not to be running as a strip... could be something to consider? As I said I have not tested if eactivities way helps but while I was working on something else I hoped you either know already if it does not help but if it does you may like to use it.
amazonka wrote:
if the utilities were to be run from the strip in eactivities would it not eliminate crashes when renaming?


No, it wouldn't.
After a period of over a month during which no work was done in Utilities, I decided to make a final release so that I can put a definitive end to this project, more than three years after I began developing it. In fact, v1.4 (over one year old already) was meant to be the last release, but as has been explained before, bugs and a desire to go a bit further meant development continued past this version.

So here we are, with over 280 commits past v1.4 (git says 220 files changed, 24494 insertions, 4521 deletions, but part of that is due to the inclusion of picoc).

The text editor

One of the things that was part of the "desire to go further" was a proper multi-line text editor. This is something that doesn't yet exist on this platform, over four years after the first unofficial add-ins were built. I'm sad to announce that as long as me and Utilities are concerned, this will continue to be the case.

Over the last years, multiple efforts to bring an actual text editor to Utilities have been made by two or three people, but the results of such efforts never reached a point where I was comfortable including them with Utilities, in terms of stability and usability. Stability and safety were of special importance, at a time when Utilities already had some bad reputation, due to the instability of previous versions and after being the suspected cause of calculator bricks, something that was ultimately dismissed (but still worries me, obviously).

Causes for the failure of these multiple efforts include:
- the lack of technical knowledge to build such an editor;
- the technical constraints imposed by the OS that make building a text editor, that can actually edit big files such as Lua or PicoC scripts, very hard;
- the fear of trying more advanced techniques or experimenting with lesser known syscalls (there has to be one for multi-line editing somewhere) at a point when the community had already seen many calculators bricked for unknown reasons and (still true as of today) no way to fix these bricks;
- more recently, the lack of motivation of the people involved (myself included), at a time when most communities, even Casio-focused ones, do not give much importance to the Prizm. This is also related to the new examination rules that are becoming effective in some countries, and mandate the existence of an examination mode, which the Prizm lacks, meaning less and less of these are bought and used. In my case, there are also other personal aspects, such as moving on to university (first year done already) and no longer using the Prizm in class.

All this should make it clear why Utilities v2.0 will include many new features and nice changes, but one of the most needed ones won't be present.



Major release, major removal

Lots of things have changed since v1.4 (hence the major version number increase). Features have been added, many improvements have been made, but to the dismay of some users, I decided it's best to remove one thing from the new version: the CPU speed selector.

The reason for removing it is very simple: it was developed in a time when the accepted way to over/underclock a Prizm was to mess with the main CPU clock. But in November 2014 sentaro21 came with his Ptune2 tool and showed the community what proper SH7305 overclocking looks like. The CPU speed adjustment feature included with Utilities is doubtlessly inferior to Ptune2 and may needlessly cause stress to the different calculator parts, not to mention the higher speeds provided by it are outright incompatible with certain calculators. The only point going for Utilities' adjustment feature was the ease of use, but I believe that with a bit of training, the basic and most safe features of Ptune2 are as easy to use. And finally, some members, like TeamFX, will agree that CPU overclocking should only be available to people who know what they are doing and are willing to take more risks, and thus it doesn't make much sense to make the process as easy as counting to three.

This will be the only feature to be removed. I pondered the removal of the Add-In Manager, but after the recent changes I did to it, it's a bit more stable, and most importantly, the failure mode consists on the OS disabling all of the add-in functionality without actually disabling the SMEM or deleting any add-in. The add-ins simply disappear from the main menu and from eActivity strips, until a reboot is made. This is a behavior users may find curious and perhaps even useful, so I don't mind too much. Of course, the Add-In Manager will keep being a advanced tool, only available after enabling the appropriate option in the settings.

Mission impossible, goal not achieved

Don't get me wrong: I am quite happy with the work that was done - and to think that Utilities was initially meant to be just a clock and stopwatch... At some point, years ago, I realized that Utilities could fill a gap, the gap that Doors CS fills in TI calculators, and started work towards making it some sort of shell for the Prizm. Unfortunately, the OS architecture and our lack of understanding of certain parts of it, meant that such grandiose plans had to be withdrawn.
I also hoped that, much like Doors CS, Utilities could act as a base for more easily developing programs for the Prizm. It would be awesome if certain UI routines, such as the menus, text viewers and text inputs could be re-used by other programs without having to include them again in their code. Same goes for less visible things such as the file management helpers. Shared libraries (dyanmic linking) would be a way to make this possible, but sadly AHelper's calculator died as he was working on this.

I also wanted to make Utilities more extensible; if it had evolved into a shell as I had originally planned, things like the Calendar, File Manager and password generator would actually be separate apps using the Utilities framework, and people would be able to replace or remove these apps as they wished.
PicoC actually allows for some of this, albeit not with the freedom of native binaries, but at least not everything is lost.

Finally, other failed goal was to make Utilities integrate better with the OS, or should I say, make the OS integrate better with Utilities. Things like showing a clock in more places in the OS, or even extending the OS menus, never became reality. The infamous Prizmed framework (a pun on Android's Xposed) had the sad ending of bricking my calculator, only reminding me that we don't know what we don't know. Since then I have experimented much less, as even less dangerous things are a pain to debug because the emulator doesn't support going into standby, nor simultaneous key presses, nor 3-pin communication, etc.

It is of course possible that other people will come and make some of these things reality, but given the inactivity of all the Prizm communities, I don't think that's going to happen any time soon.

Not very popular

Perhaps due to its horribly generic name, Utilities is not known to many of the Prizm users that install 3rd-party add-ins. It also doesn't seem to be as useful as I thought it would be to many people.
Of course, I don't expect people to use the calendar, stopwatch, etc. as their primary tools of the kind. Heck, some people won't even do that with smartphones, let alone with a calculator. But I hoped that with so many different things, it would have something of interest to more people.
It's actually possible most people don't even realize it has a file manager, or that they find it too hard to use.
It may also be a case of people not liking monolithic all-in-one designs where the calendar sits next to the image viewer, in the same executable. I don't like them either, but it was the only way I found to reuse code and avoid dozens of different g3a headers floating around.

Perhaps freeing Utilities of its silly name would help, but I'm also afraid it will do even worse by disconnecting it from its current popularity. If anyone has suggestions for a better name, feel free to give them.

I'm not even sure v2.0 will be of service to anyone, but I'm releasing it anyway because I think it would be unfair to keep the over 280 commits of goodness just for me. Yes, it's open source, but it's also kinda hard to compile. So in the next days v2.0 will happen, half a dozen people will download it, and I'll move on to developing more useful stuff that's not tied to a decaying platform.

Please reply if you have any questions or suggestions. And congratulations for digesting this giant wall of text Very Happy
I cannot believe I missed this post - thanks for the update as always but it is also sad you are making it another final one ;-(
gbl08ma wrote:
One of the things that was part of the "desire to go further" was a proper multi-line text editor. This is something that doesn't yet exist on this platform, over four years after the first unofficial add-ins were built. I'm sad to announce that as long as me and Utilities are concerned, this will continue to be the case.
indeed this feature would be desired

gbl08ma wrote:
Stability and safety were of special importance, at a time when Utilities already had some bad reputation, due to the instability of previous versions and after being the suspected cause of calculator bricks, something that was ultimately dismissed (but still worries me, obviously).
while looking at this subject earlier I started to suspect (but had no time to fully investigate) that perhaps auto power off custom times in Utilities and the other power properties amending add-ins could have been the reason for bricks - possibly under some odd conditions the value for auto power off was set to zero or some invalid value making the calculator power off (after restarts or turning on) and causing other problems as the result ending in the brick depending on how users tried to react to power downs/restarts - just in case you haven't looked at this possibility?
gbl08ma wrote:
the new examination rules that are becoming effective in some countries, and mandate the existence of an examination mode, which the Prizm lacks, meaning less and less of these are bought and used.
Hopefully examination rules stay unchanged outside of France - would be really expensive for school children in the UK for example to replace such a already expensive calculator...

I plan to further "digest" your post and share some of the thoughts and "pseudo" OS integration ideas when I get enough time - but thanks again for kindly posting all the details and updates on all this here.
I was planning to switch the license of Utilities 2.0 from GNU GPL 2 to something less restricting like the ISC or MIT license, but it looks like PolarSSL code (used for SHA-1 and SHA-256 checksums, plus some internal stuff) is only available under GPL v2 unless one pays for a commercial license, and it's too late / too much work to find out another library, and change the code to work with it, then test the relevant parts again, etc.
So Utilities will keep having a GPL 2 license, much to my dismay. The license of everything else (PicoC, heatshrink, TJpgDec) would have been compatible with the ISC one, so PolarSSL/mbed TLS really is the impediment here. And the Prizm still has no dynamic linking...

amazonka wrote:
would be really expensive for school children in the UK for example to replace such a already expensive calculator...


The way the rules are coming into effect in France, ensures only people who are now entering the education level where they need a calculator, will have to buy a calculator with examination mode. As I understand it, people already in the "system" (i.e. who have already bought a calculator) can keep using it until the end of their courses. Perhaps Lionel Debroux can come and confirm this?
People who were planning to inherit calculators from older brothers or friends who no longer need them had their plans foiled, but it's the same thing that happens when they change course material and school books get updated or outright replaced.

And in the case of graphic calculators it's often a bad idea to inherit calculators, unless financial reasons really do not allow it. I remember seeing people in my class with old Casio CFXs, and these were so slow compared to new Prizms and fx-9860Gs, that they effectively put these people at a disadvantage in math tests and comprehension-through-visualization in general, especially when 75% of the class has these newer calcs. The jump from low-resolution b&w screens to high-resolution color screens is even more noticeable (especially if you know well enough to install an image viewer, heh).
  
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
» Goto page Previous  1, 2, 3 ... 9, 10, 11, 12  Next
» View previous topic :: View next topic  
Page 10 of 12
» All times are GMT - 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