Captain Calc wrote:
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?

I only skimmed the code, but it appears you're not resetting your VAT seek every time you change the type of var you're looking for.
You probably want the following line of code inside your outer-most for() loop:

Code:
void *detect_str = 0;
Yes, that was it! Thank you so much!
Great progress on this! I noticed you talked earlier about a “headless start” system, and I’d like to have VYSION support that. Will it just need to store the file name in Ans, and how will you differentiate between appvars and programs of the same name?

Looking forward to seeing more updates on this, so I have a few more suggestions as well (some a restatement of things I’ve already said):
-being able to press [enter] to select things
-differentiating between protected TI-Basic and ASM programs (check the start of the file for 0xef7b, and it’ll be ASM)
-customizable color schemes (?). If you’d be interested in making this program enhanced with VYSION later on as well (that functionality has yet to be announced), there will be an include file you can use to get these colors, to have the same appearance as the shell.
-load all programs and appvars before creating the menu in a dynamic array of structs that stores the name, type, and size of the program. It appears to me, based on this code that every loop, the files are redetected, which is needless overhead and results in the list scrolling more slowly towards its end. If you just load all this beforehand by detecting the files at program start, you’ll get consistent and faster speed regardless of the number of programs or the offset in the list.

That’s all I have right now, keep up the work on this great project!
Thanks for the feedback! Smile

Where did you notice the lack of [enter] support? I believe I carried all of dual button support over from the 1.2.2 version, but there could be a spot I missed. I don't think color customization is a high-priority issue right now because I want to keep the program from growing too much further, but I am considering adding additional configuration data to the Headless Start that will allow other programs to override the default color scheme. I like your idea of differentiating between the different kinds of protected programs and the pre-loading of the file data into dynamic structure arrays. The main menu cursor speed was always an Achilles' heel for HexaEdit.

I forgot to mention that this version also supports a theoretically infinite number of undos. The actual number is roughly 5000, but this should be ample unless you are writing an entire assembly program using hexcodes. Razz
Progress Update

I have finished basing the main menu backend on the dynamic file data arrays and am working on rewriting the functions that manage the Recent Files list. The Headless Start now supports a "color theme" override that allows the calling program to decide how the editor will look. The configuration data for the Headless Start is split up into four structures: a general header, a color theme override, a memory (RAM/ROM) editor configuration, and a file editor configuration. I will include a guide to the Headless Start API in the program download.

For the first release at least, HexaEdit will use an appvar to store the Headless Start data. I did some experimenting with the Ans variable but did not figure out how to store non-integer values (pointers, etc.) to it. Looking at the documentation for Ans, it looks like it can only store integer values, unless KryptonicDragon found some hacky way to make it hold other data. Wink

Unless something unusual occurs, I hope to release version 2.0.0 in the next couple of days! Smile
Version 2.0.0 Release

HexaEdit 2.0 is now available for download!

This version features a reworked GUI for both the main menu and editor, an upgraded file search that can search both appvars and programs, and a Headless Start API that allows the program to be run from other C or ASM programs.

Many thanks to all those who encouraged HexaEdit's development and helped improve it! Smile
Looks pretty good indeed, and the feature set is definitely nice - keep up the good work Smile
It reminds me of Command Post Plus and TICT's Tools Suite handle explorer (tthdex), both for the TI-68k series.
Thanks a lot! Smile

I am hoping to release a small update to HexaEdit tomorrow that will fix a bug in the Headless Start routine, make some minor tweaks to the input system, and fix some memory management issues in the main menu. I have at KryptonicDragon's request added a switch for the offset/address column on the left-hand side of the editor that allows the user to switch between offsets (calculated from the start of the file, RAM, etc.) or RAM/ROM addresses. The [mode] button toggles this switch.

HexaEdit 2.0.1 also offers a feature suggested by Lionel Debroux: a phrase finder for the editor. This function allows the user to search for a 16-character phrase in ASCII characters or an 8-character phrase in hexadecimal. This function is very fast for files, reasonable in RAM, and very slow in ROM (~90 seconds to find all occurances 2-character hexadecimal string in over 4 million bytes). Although it does remove the satisfaction to know that there are exactly 3 occurences of "\xab\xcd" in the entirety of ROM, I will probably cap the search range to around 300K bytes in order to provide a decent response time unless enough votes come in to make it an option. Wink
Version 2.1.0 Release

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

This version introduces a shortcut to a file's VAT location and makes the phrase search algorithm 6x faster than the previous version! Now, when the user selects a file in the main menu and presses [mode], HexaEdit will open a RAM editor at the file's VAT location, saving them the trouble of remembering the VAT address, opening the RAM editor, and typing it into the Goto function.

I rewrote the phrase search code in assembly and now it only takes a little under 15 seconds to search the entirety of ROM instead of the 90 seconds the C algorithm took. Searching all RAM is even faster: only 1 second! This performance boost made the custom search range superfluous, so I removed it but left the option for other programs set custom search ranges by modifying the settings appvar.

Hope you enjoy it! As always, any feedback would be greatly appreciated! Smile
It looks great except that the file scrolling is really slow! Maybe if the program didn't update the time every time a file was scrolled it would be faster. Also, since the primary users of this program are developers, and developers' calculators' ram usually resets pretty often, you might think about just cutting the time viewer entirely. However, I use this program all the time and it is really great otherwise!
Thanks for the comment! Smile

Removing the clock sounds like a good idea. All the shells for the CE have clocks, so HexaEdit's clock is sort of redundant. You made a good point about the constant RAM resets, too. Rolling Eyes Setting the clock back up after each reset is a hassle.
Captain Calc wrote:
Thanks for the comment! Smile

Removing the clock sounds like a good idea. All the shells for the CE have clocks, so HexaEdit's clock is sort of redundant. You made a good point about the constant RAM resets, too. Rolling Eyes Setting the clock back up after each reset is a hassle.


Since your removing time displaying, what would you be placing in the empty space "where the time used to be"?
Just nothing would be fine, I think. One thing I would say though is that as I said earlier, the call to get the OS battery status is very slow (the clock too, most likely). Just having it run every 30s or so would fix the problem, I think.
epsilon5 wrote:
Just nothing would be fine, I think. One thing I would say though is that as I said earlier, the call to get the OS battery status is very slow (the clock too, most likely). Just having it run every 30s or so would fix the problem, I think.


I would not display the battery at all, and center the program's name. Also, this would dramatically increase the program's speed.
Alvajoy123: I had not thought about replacing the clock with anything, but I am toying with the idea of using the space for extra versioning information, like the Git branch for the build.

Alvajoy123 and epsilon5: I made a test build without the battery indicator and it greatly improved the cursor speed. With a few tweaks to slow down the table tab switching, the main menu will be much more responsive than the last release.

I have also implemented a "superuser" lock that prevents the user from writing to certain RAM address that would crash the calculator. To toggle the superuser mode, you press the [^] key while in the editor.

The "Ports" area of the calculator (0xE00000 - 0xFFFFFF) is now supported, per jacobly's request. I am busy rewriting sections of the editor code that have potential variable overflows because of the unique upper bound of the "Ports" section. Note: It is possible to crash/freeze the calculator by writing to certain bytes the "Ports" area.

Thanks for the comments! Smile
  
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
Page 2 of 2
» 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