Version 3.0.0 Release

Here it is, the latest version of HexaEdit CE!



When you first download this program, please read the README. HexaEdit is designed for power users, so it does not come with training wheels. You can seriously mess up your calculator with a few simple keystrokes.


-------------------------------------------------------------------------------------


It's been quite a journey since the first release three years ago.

Version 1



Version 2



Version 3





-------------------------------------------------------------------------------------


This will be the last major revision of HexaEdit CE for a while. I am ready to finally shelve its active development and pursue other programs for the CE and other platforms. Nevertheless, it has been a blast, and I am indebted to all of the community support here at Cemetech to get this program off the ground. Thanks a lot!


-------------------------------------------------------------------------------------




That's pretty much it. I have included a large section of documentation and example code in the README to explain how it works. I did scrap the call from TI-BASIC idea to reduce the program's complexity and get a release out sooner.

Enjoy!

I've had a bit of time to test this out now and offer some feedback. I think that overall the program is an improvement over the previous versions and does its job very well, but there are some notable areas where I felt that things were made more unclear or don't work as well as they used to.

- The main menu: I really don't like the new design of this. It took me a few minutes to realize that the gray bar at the bottom of the screen was used to indicate what section of the menu I was in. I liked the original's design, where it grayed out the other regions, much better. I also liked the single-pixel borders around things in versions 1 and 2, and 1's larger spacing between menu items. This new menu looks far too cramped and basic for my taste. Here's a mockup of what I would prefer, mixing the styles of 1 and 2 with the new menu layout:

- Input: The input needs some debouncing--there were a good amount of places where double activations made it difficult to use the program. A few of these were the main menu--where sometimes pressing the directional keypad quickly would lead to the selection box jumping multiple places downward or side to side, and the cut/copy/paste dialog, where pressing [clear] usually returned me to the main menu instead of cancelling the action. In cases where you can hold a key--like on the main menu--there should be a small delay before it starts doing so that resets every time the key in question is released.
- Editor: I'm mostly pretty satisfied with this, but the one large issue I have is the lack of clarity in the "i : x : 0 : 1" message or similar. Reading the readme did tell me what everything means here, but the format still was difficult to remember even after doing so. I think that the first one--which tells you whether the variable can be overwritten/read/inserted into is pretty much useless considering that you're already graying out options (maybe there could be a message that pops up when you open the editor that tells you if the variable can't be written to or something). The second, the current input state, would ideally be in a black box with white text next to the battery indicator like in TI-OS. Then you're only left with the selection size and clipboard size, which users should be able to figure out. Also, [alpha] should really change the input mode.
- Clipboard: I don't have any huge complaints with this, but I do think that it would be worth considering having the default behavior being inserting the contents of the clipboard at the cursor location instead of overwriting. Then, if you can't insert bytes, you can just overwrite them (maybe give some indication that that's what will happen as well). Inserting the desired number of bytes, selecting all of them, and then pasting the clipboard contents (assuming it matches the size of the selection) is a lot more work than just selecting, copying, and pasting like every other program.
- Battery icon: Bring it back please... (see my mockup above, version 1's was the best)

Anyway, good work on this! As always, this is a very helpful program that I use quite frequently--I wouldn't offer feedback otherwise.

Is there a way to uninstall this fully because I broke it (somehow) reinstalled it and it still was broken. I tried it with an emulator and it worked though. It says "Warning: Cannot save Recents appvar" and whenever I save things, instead of saving my edits, it basically breaks the file with random values but with the same amount of bytes. It views files correctly but breaks when I try to edit it.

The error you got usually occurs when you have too many programs/files in memory. HexaEdit requires a great deal of RAM to operate, so if it cannot get as much as it needs, it will still run but it will not save the most recently edited files. If you delete HexaEdit or clear your calculator's RAM while HexaEdit is in RAM, it will be "uninstalled."

Your problems might be related to a bug I found in the Find function recently. I will investigate.

Thank you epsilon5 for all of your feedback! I really appreciate it. Unfortunately, I decided to cut the "insert clipboard bytes" feature early on in development because it would create too many complications. The underlying buffer code was designed without it, and attempting to retrofit the feature now might invalidate the logic of a large portion of the core codebase. I designed HexaEdit 3 for stability, which requires a slow, methodical approach to feature implementation. However, if I have misjudged the effects of adding the function, I might reconsider it.

I am planning on doing some work on the debouncing issues you described and making a few minor tweaks to the UI.

I've been giving HexaEdit 3 a try and it's way faster! It's definitely a lot easier to use than the older version, so great job on that. I will say that I agree with the key press issues though.

Do you display an error message if there isn't enough RAM for HexaEdit to save edits? I feel like there should at least be some sort of warning message if there isn't already, the way that it warns you about being unable to save the AppVar. I'm not sure if this already exists or not though, since I've never encountered the issue myself.

As far as the key debouncing goes, I'd suggest using some sort of clock() timer where it will wait slightly longer after the first key press to continue repeating the key press (If that makes any sense). That way you can still hold down keys, and it gives a similar behavior to holding down a key while typing on a normal keyboard. Sorry if I didn't do a very good job explaining it, I can upload an example gist a bit later when I'm able to if you're interested.

Overall, nice work, it's definitely a big improvement from the last version!

Edit:
You can find the example gist here.

Thanks for the feedback and the gist, TInyHacker! I have been doing a little experimentation with key delays, and it might be possible to integrate the delayed-keypress-follow-up you described in your post.

I have seen several references to the "Warning: Cannot save variables to Recents appvar" error, so I want to explain how it can occur. When HexaEdit starts for the first time, it creates an appvar to store up to 15 of the variables that the user has edited. The program sizes the appvar to 255 bytes, more than enough memory to hold all of the variable names. The program allocates all of the memory for the appvar at once so it does not need to resize the appvar. Version 3 tries to avoid dynamic memory allocation as much as possible.

Every time HexaEdit starts, it creates another appvar, the edit buffer. In version 2, I ran into problems when resizing variables in the editor: pointers to data within the variable would be invalidated every time the variable's size changed. Therefore, in version 3, HexaEdit tries to make the edit buffer as large as the largest variable the user could ever have, consuming up to nearly 64KB at maximum. If it cannot grow to the maximum, the appvar will consume all the free RAM it can. This approach is essentially treating the appvar as a static memory allocation, ensuring that none of the pointers to it will be invalidated as long as no file operations happen after the edit buffer has been allocated.

Now, if HexaEdit cannot allocate an edit buffer of maximum size, it will not attempt to save the most recently edited variable. The saving process requires opening the save appvar, HXEDITr, in "r+" mode. This line ensures that there is some spare RAM available before the program attempts to save a variable name. Looking at the code in retrospect, I am not sure if the safeguard is necessary. I have a suspicion it is there because FileIOC would act up if all of the free RAM was in use, but if not, it might be removable.

In a nutshell, you should not get the error if the free RAM amount in HexaEdit's main menu is at least 300 or so.

Progess Update: Conventional Keypress Delay

When the user presses and holds an arrow key, HexaEdit now waits a split-second before moving the cursor continuously, mimicking the conventional behavior of a computer keyboard. There is not an official release because I want to patch a couple of things first, but if you want to try out the new feature and don't mind building from source, the new version is available on the project's Github repo.

Just got the chance to try it out--the input feels really nice now and I like the small UI improvements (like the new indicators for the input mode and clipboard).

What do you have planned for the full new release?

I just gave this a try, and the cursor is way easier to use! One small issue though - could it be possible to do the same thing done with the cursor to text input as well? I frequently find myself entering too many of a number and accidentally corrupting other parts of a file I didn't mean to touch. Otherwise, I really like all the changes, great job!

The new release will incorporate all of the UI tweaks available on Github and a few bug fixes.



It might be possible. I am exploring the potential ways the algorithm could be implemented, but it may be a while before it is ready.

Thank you for all of the feedback and support!

To TIny_Hacker: I have released a commit on Github that tweaks how certain keys are registered. It does not fix the text field input specifically, but I was wondering if you could try it out and see if it feels better.

One of the latest commits on Github also remove one of the extra memory safeguards that might have been generating unnecessary warnings about not being able to save the Recents appvar.

As an aside, has anyone experienced these odd graphical glitches when using the Find function?





I have only experienced them while attempting to search for a hexadecimal string in a variable or in ROM. As far as I know, it does not crash the calculator, but still it would be better to test for this in an emulator just in case.

Version 3.1.0 Release

Download v3.1 from the Cemetech archives here!

This release has a rewritten Find function to replace v3.0 faulty implementation that will cause the calculator to crash if you are doing searches in ROM. Upgrading to v3.1 will improve the program's stability and remove the graphical corruption shown in the previous post.

HexaEdit 3.1 also improves the user experience with better key debouncing in the menus and editor and with a less aggressive memory warning system. The persistent "cannot save Recents" warning when operating in low RAM scenarios will now only appear if the program encounters a file operations error.

Enjoy! As always, bug reports and feedback are greatly appreciated!

Just downloaded v3.1, with latest clibs, but whenever I try to open the program on both Cesium and Artifice, it just resets my ram :/

Welcome to Cemetech, reptile23!

I do not own a jailbroken CE, so I cannot replicate your issue. Could you give me some more details about how and where exactly it crashes? If you can install CEmu, I can send you a debug build of HexaEdit that can help identify where the problem is.

Thanks for the feedback!

I've also encountered the same issue on my TI-83 Premium CE. I tried running it through Cesium, CEaShell, and ASMHOOK and each time it crashed, so I'm not sure whether it's an issue with jailbroken calculators as the program execution should be the same when running through a shell on any calculator.

I've also noticed that when searching in a file I'm unable to change the text input mode. Is this to be expected or is something wrong?

A couple of newer TI-84 Plus CE's that I have bought for other people had flickering display issues (notably when rendering the checkered pause menu in Mental Math CE), so maybe the newer calculators have a few hardware quirks that make program execution a little different.

If you are searching for a hexadecimal "phrase," or byte sequence, HexaEdit will lock the text input mode to hexadecimal ("x"), removing the ASCII character sets ("A", "a", "0"). A similar sort of lock will occur when the user puts in a character from one of the three ASCII character sets: it will remove the hexadecimal character set. Thus, you can use either hexadecimal ("x"), or ASCII ("A", "a", "0"), but never both. This prevents users from mixing ASCII and hex characters because it will confuse the find function.

No, more than likely your code is doing something it should not be.

If it works on older calcs, it should work the same, unless TI messed something up.

I downloaded a copy of TI-OS 5.8.0, installed it in CEmu, and jail-broke it with ArtifiCE. After a little debugging, I found that HexaEdit is crashing in this function on the while-loop's first iteration:


Code:


To view the complete source code file at the line the problem occurs, click here. This is the error:


Code:


For some reason, os_NextSymEntry() does not work on OS 5.8.0 as it does on OS 5.3.0. The function os_GetSymTablePtr() does work, returing the expected value of 0xD3FFFF. I double-checked the documentation to make sure each variable was the proper type and value, and it does follow the docs. On a whim, I increased name to 500 bytes, but it did nothing.

Does anyone have any ideas as why this happens?

EDIT:

After doing some step-by-step assembly analysis on OS 5.3.0, I discovered this in os_NextSymEntry():




The instruction at 06F785, LD (HL),A seems like it just dereferenced 0x000000 to load 5 into it. This doesn't make any sense to me because I thought ROM was write-locked, except for functions that explicitly archive programs and so on.

I did the same step-thorough on OS 5.8.0 and found this:



The console has just displayed the error mentioned in the top of the post. As far as I can tell, the algorithm's assembly code is the same (I assume the offsets are different because OS 5.8.0 adds more stuff to the ROM). However, now the LD (HL),A at 083887 triggers the NMI error.

Does anyone know why this behavior occurs?

It looks like the issue here is that the last parameter, data, is an output parameter - you give it the address of a void pointer variable, and it sets the value of that pointer variable to the address of the data.
At the moment, you're passing a null pointer to it, rather than a pointer to a null pointer. So, when it goes to write the variable data address, it's writing to address 0 and crashing.
You should be able to fix it by redefining data to be a void pointer, rather than a pointer to a void pointer, and passing &data to the function.

I'm not sure why only OS 5.8 is crashing here - you'd think both versions would behave the same, as writing to address 0 should be a crash no matter what.