Welcome to the HexaEdit CE development thread!

Overview
HexaEdit CE is a fully-fledged hex editor for the TI-84 Plus CE. It can edit programs, appvars, and RAM as well as display the contents of ROM!



Download
Version 2.1.0: https://www.cemetech.net/downloads/files/2010/x2384

Features

• A ROM viewer
  
• A RAM editor
  
• A file editor
  
• A file search function for finding files more quickly
  
• Storing of up to 15 "recent" files for easy access
  
• Alpha-scrolling for both main menu file list and editor for quick navigation
  
• Byte insertion and deletion for programs and appvars
  
• A search function within the editor for finding hexadecimal or ASCII byte sequences
  
• An icon/sprite viewer
  
• A "Goto" function for fast navigation anywhere in the given memory
  
• An “Undo” function
  
• Multi-byte selection
  
• Auto-translation of one-, two-, and three-byte clusters from hexadecimal into decimal allowing for little-endian architecture

Source Code

The source code is available on Github: https://github.com/Captain-Calc/HexaEdit-CE

Known Limitations

• HexaEdit cannot save changes to very large files (~65,505 bytes). When HexaEdit is asked to edit a file, it copies it into an appvar whether or not the file is in archive or RAM. When it is asked to save changes to a file, it creates a new file with same type as the original and makes it the same size as the editing appvar. This resizing fails on large files. I encountered this limitation specifically with regard to OiramT, the tile appvar for Oiram.
  
  
• HexaEdit does not support inserting and deleting bytes from RAM.

I updated the Github repository with two dummy easter_egg.* files that allow the repo to be built without having to edit the source code. The final compiled program size with the dummy files is under 14,700 bytes.

Updated Source Code
https://github.com/Captain-Calc/HexaEdit-CE

That's quite a good looking, handy tool! Looking forward to finding those easter eggs. Time to cheat at some games debug some appvars!

Thanks!


Yes, I actually debugged some appvars myself while I was developing it. You can now get all of the upgrades in Omicron 34 without having to spend a single point.

Kudos to commandblockguy for anticipating such unusual bug-fixing methods in Dino Run CE!

Thank you!! this will be very useful . I look forward to using HexaEdit to debug prgm appvars.
Also good work on the GUI. it's not over-complicated and it's very easy to understand.

Firstly, this is a very good program. I like how easy to use and organized it is, it's pretty clear that a good amount of effort went into making it. I do have a few feature requests, however:
-a search function: if people have a lot of programs on the calculator, like I do, it is very tedious to scroll through all of them in search of a program that is later in the list
-overall optimization: the menus can be very slow to scroll through, it feels like everything is taking longer than it should. I do think I know the reason for this after taking a look at the source code, however. When I was working on VYSpass CE, which had a battery indicator like this program, I noticed that the function boot_GetBatteryStatus() seemed to slow down my program a lot. I solved this by just getting the battery status and storing it on the program's first running, as there is no real reason to check it every loop. I'd recommend taking that out as a test and seeing if it runs any faster.

Good work though, I look forward to using this to test out things relating to the OS tokens, appvar editing, etc.

Version 1.1.0 now possess a search function that allows you to search the file list displayed in the left window. I also shifted some of the main menu drawing code around in order to draw the battery status indicator only once like epsilon5 suggested, and it greatly increased the scrolling rate. Thanks for the tip, epsilon!

This release also adds a feature that allows you to delete files from the "Recent Files" list. Since this list is not updated when the program starts, programs that have been deleted between HexaEdit runs will still appear in the list. Rather than implement an auto-update function which would be both bulky and time-consuming, this feature will allow you to remove those files if you find they are in your way. Otherwise, if you know you have deleted them and don't open them, they will eventually disappear from the list.

This version also fixes several other minor bugs and adds a automatic delay function for small files that reduces the cursor speed to a more manageable level.

That's nice and very handy program . Does it have a page down / page up like function?

No, HexaEdit does not have a page-up/page-down function. It does have a "Goto" function that makes jumping around inside files and RAM a little easier. This function accepts an entry in whatever offset system is being used at the moment it is called, so in file-editing mode the offsets and "Goto" input are in decimal, and in RAM-editing mode the offsets and "Goto" input are in hexadecimal.

I could implement a paging system, using the [alpha] key like the TI-OS program editor uses for fast line-scrolling. If the user holds [alpha] and presses an [up] or [down], the program would subtract or add, respectively, 120 (the maximum number of bytes on-screen) to the window offset. Maybe it could be a feature in Version 1.2.0.

Version 1.2.0 Release

I found two bugs in HexaEdit 1.1.0 yesterday, one in the "Goto" function and one in the hex-to-decimal translator. Both of these have been fixed in this release.

I have also added malagas_fire's suggestion for a page-down/page-up feature in the editor. If you press and hold [alpha] and then press the up or down arrow keys, the editor will scroll the entire screen up or down, respectively.

I added alpha-scrolling to the main menu's file list as well to facilitate traversing long file lists. In order to add this feature, I had to change the controls for the file search function and the file properties function. The new controls are:

• [mode] - File search
  
• [X, T, theta, n] - File properties

The file search function now supports lowercase letters as well.



Only 5 more days to find the easter eggs!

Easter Egg Source Code Release

Well, here we are two weeks after the release of the first version of HexaEdit CE and it is time to make HexaEdit officially open-source! The source code for both easter eggs is now up on Github. For those who want to find them on their own, please do not click the link below.

Full Source Code: https://github.com/Captain-Calc/HexaEdit-CE

I can now also explain the hints I gave about each hidden feature in my first post.

Hint 1: This can work anywhere, but usually 0x0A is best.
Solution: This hints at an icon viewer. This viewer takes the next 255 bytes after the cursor and draws a sprite with that data. The icon for each C program is offset 0x0A bytes from the start of the program, so that is where the viewer typically works best. However, you can use it anywhere in a file, provided that the cursor is at least 256 bytes away from the end of the file, so it also allows you to view the contents of sprite appvars. Please note that this viewer uses the built-in GraphX palette, so the colors of each sprite might be off if it was made with a custom palette.

Hint 2: We know what it is, but where is it?
Solution: If you look in the global defines header, defines.h, you will find the following define:

Code:

No, this does not mean that HexaEdit CE can edit ROM. I was merely making my define names consistent. It does mean, however, that you can view your calculator's ROM contents.

I have purposely not mentioned how to activate these features, so that those of you who are still looking won't have any spoilers. For those who do want to explore these features now, the Github ReadMe gives the control keys.

Happy coding!

Not sure if this is an easter egg or not, but I found an undocumented feature where if you press [stat], a popup box will appear of the next 256 bytes in the form of a 16x16 sprite. This could be useful for looking at or editing the icons in a program, which always(?) seem to occur after the byte D1, followed by an 01, presumably to indicate that an icon exists, 10, 10 (16x16 or the size of the icon sprite), then the 256 bytes of icon data and then the description, ending in 00, the null terminating byte.

Again, thanks for this great program, it’s about the most useful utility on the CE in my opinion.

EDIT- Looks like I was late to post this, but I would like to say that I found it by myself today without the help of Captain Calc’s post, and submitted it without reading through to make sure the solutions had been already stated (so I’m not cheating).

Congratulations on finding the easter egg!

I selected the [stat] key on purpose, thinking that if somebody was editing a file and they missed the left arrow key, they would hit [stat] by accident, making the window pop up.

Thanks! I found it by pressing random keys in the hope of finding one that did something interesting, and ended up finding the window that way. I imagine this could pretty easily be expanded to display a sprite of dimensions determined by the current byte and the next byte as well (just make a gfx_sprite_t pointer and set it to the address of the current byte, then display it with gfx_sprite or something else). That could form a sprite viewer of sorts, which could be pretty cool.

Another feature I’d like to see would be the ability to press [enter] instead of just [2nd] in the menus, as I usually tend to press [enter]. It’s probably good practice to have both of these be selection keys, to accommodate users that are used to one or the other.

Version 1.2.1 Release

This release incorporates both of epsilon5’s suggestions for [enter] key selection and for basing the sprite viewer on the gfx_sprite_t format. The sprite viewer automatically scales small sprites up to twice their original size and displays larger sprites without scaling. The program also automatically removes deleted files from the “Recent Files” list without the user’s intervention.

Version 1.2.2 Release

This release fixes a graphical bug in the RAM editor and ROM viewer. When the program attempted to erase the sprite viewer, it did not redraw the top bar. I also named the "ROM Viewer" and "RAM Viewer" whereas before they had been blank.

Here's a mystery for the C programmers here on Cemetech. The code below is supposed to search through all of the file types on the calculator and print them out, printing an asterisk next to the file whose name matches the name in the buffer.

Code:


When this code is run, it does not produce any output for the TI_PRGM_TYPE. So far the source of this bug has eluded me. Any thoughts?

Version 2.0.0 Release Pending

The next version of HexaEdit CE will be released in the first week of January. This version is a complete re-write of the program, making the back-end code less messy and more modular.

It also provides an interface for shell integration through a process called "Headless Start." When HexaEdit launches, it checks to see if a specially-named appvar exists. Depending on what kind of data the user writes to the appvar, HexaEdit can immediately open an editor anywhere in ROM, RAM, or a file. This process bypasses HexaEdit's main menu, so the program acts more like an extension of the shell than a separate program. When the user exits after a Headless Start, HexaEdit closes without returning to its main menu and deletes the configuration appvar, so the program can run normally the next time the user opens it, unless another configuration appvar is created.

Have you considered using the Ans var for this functionality?

No, I haven't. However, I think that is a better method than the appvar. Thanks for the tip!