File Hex Editor for X16

[voidstar]

X16HXD is a file hex editor.

Version 1.3 updates
- Can press ESCAPE during first character of HEX edit in order to cancel the edit
- Fixed missing fclose, so can now re-open same file after multiple runs (without having to power cycle)
- Help will keep you at same location instead of going back to HOME.

Version 1.2 updates
- Tests available memory (low memory), max editable file ~20KB (reported at startup)
- Wrap around left/right movement
- GOTO feature (go to a specific offset)
- Start in 80x30 mode (instead of 40x30)

Other features:
- Can INS/DEL bytes (add/remove)
- Just start typing hex values to modify
- H for command list help
- "***" indicator at bottom left indicates file buffer is modified (use W to write it back to disk)
- Top right is total file size
- Bottom right is current file offset of cursor position

Written using cc65. Hybrid use of conio.h and some direct assembly for the main table updates.

Mostly cc65 helped with the file I/O routines, I was surprised they all worked "out of the box" for its C standard library implemented for the X16 R44.

I think X16HXD is usable enough to start sharing this with others, but as a reminder: make backups first of any files you modify just in case.

The yellow numbers at the bottom center are the last keyboard code and key modifies (if any) that were last pressed.

Still lacking many features, such as: no Search, no Bulk Fill. Also, not sure how case-sensitive the file input prompt at the beginning is (across Linux and Windows).


Main next focus is adjustments to being able to modify files larger than the first BANK. Bit of a challenge since I want to support the INS/DEL feature, and modifying the file in memory before saving back to disk.


Source at: https://github.com/voidstar78/X16HXD


A short video preview is here: https://www.youtube.com/watch?v=fTP-gpYEN3I

[voidstar]

Source at:
https://github.com/voidstar78/X16HXD

Added GOTO feature, can now quickly get to end of file.
Increased editing capacity to ~20KB.

[voidstar]

1.3 updates:

- Fixed where EOF is no longer read as an input character to the buffer
- Fixed a missing fclose after fopen (this prevented same filename from being re-opened across runs)
- Returning from HELP now returns to the same position (instead of going back to HOME)
- Can press ESCAPE to abort an initial (first character) edit of a byte

[Sarasaworks]

The file prompt seems to be very fickle about finding the file name you enter in. Sometimes it opens just fine, however, most of the time it acts as if the file does not exist.

X16HxD not locating file

Sarasaworks_X16HxD_ss00.png (57.56 KiB) Viewed 427 times

I'm currently operating under R48.

[voidstar]

I agree and recall having issues with that. It may depend on which character set you are in when starting the program (I notice in your example, it is showing lower case characters - which should be fine, but it is not the default startup character set or font).

I don't think it is an Rxx version issue. I think the issue might be the standard libraries of cc65, which means there isn't too much we can do about it (I mean in the short term, longer term it would mean retro-fitting all our own version of the file prompt {I probably used sscanf for that).

I do like the editor, it has potential- just haven't had time to come back to evolving it.

[Sarasaworks]

I notice in your example, it is showing lower case characters - which should be fine, but it is not the default startup character set or font

That seems to be a bug with X16HxD. When I first boot up, everything is set to defaults. But as soon as I run the program, all the characters on screen convert to lowercase. After X16HxD returns to BASIC, the character change persists until a reboot or power off command is initiated. Then the BASIS returns to the start up defaults.

It's got potential, I do plan on using it for hand assembly. Maybe the more familiar I get with the X16, I may be able to help with some bug fixes. Until then, goodwork. Bugs aside, it's a lot of fun to poke around with.

[ahenry3068]

I notice in your example, it is showing lower case characters - which should be fine, but it is not the default startup character set or font

That seems to be a bug with X16HxD. When I first boot up, everything is set to defaults. But as soon as I run the program, all the characters on screen convert to lowercase. After X16HxD returns to BASIC, the character change persists until a reboot or power off command is initiated. Then the BASIS returns to the start up defaults.

It's got potential, I do plan on using it for hand assembly. Maybe the more familiar I get with the X16, I may be able to help with some bug fixes. Until then, goodwork. Bugs aside, it's a lot of fun to poke around with.

Did you try the shift/alt key combination to change the character set ?. That CAN be disabled so if that doesn't work then use the following command

PRINT CHR$($8F);CHR$($8E) (may have to be in lower case if your in mixed case mode)

[voidstar]

It's a "bug" (or feature) of the cc65 runtime - it changes to that lower/mixed character set as a standard part of its startup before the end-user "main" gets invoked. And as I recall, cc65 runtime also has issues in returning back to BASIC - not a full clean state. They might disable the SHIFT+ALT also as a standard part of the runtime (not sure, but the user app could re-enable it). But this is mainly why I left HXD in the SD EXPLORE\APP folder (at least originally) rather the \APP since it wasn't quite ready for primetime (though it does work, and I did like the color highlighting it does in the UI). The github link is in its readme.txt file.

But ya, I don't really like using cc65 runtime as an excuse for all this. I stopped dev on HXD after David did the ROM hex-editor, and that one does work but has a different set of quirks (like you need to remember the length of the file you're dealing with). This might be a good time to migrate HXD over to nxBASIC or prog8, where we can have more influence on any startup runtime code, and also tackle managing banks to support modifying large files.


Or, what about a purpose-built 65c02 "real-time" assembler? I think even BASLOAD could handle that (I mean developing a program that would do this, not BASLOAD itself handling it). I feel like elsewhere in the forum someone had done something like this - MajorAssembler maybe? not sure if that was exactly the same intent.
viewtopic.php?t=6725

[Sarasaworks]

I mean... runtimes can get in the way sometimes. So, no judgement... I've been known to rip apart runtimes to suit my needs. Had StackExchange foaming at the mouth over my blatant disregard for how GBDK2020 was supposed to handle. But I mean, it's defaults we're standing in my way.

I'm definitely interested in seeing what makes a hex editor tick, so I'll be checking out the github for sure.

As far as assembler options, looking at the file based assembler in the downloads, but haven't had a chance to install it to my SD Card image. Though, I may as well throw the MajorAssembler in there to see what fits me best. The reason I want a hex editor for assembly is to help me memorize the associations between instructions and opcodes. The Autistic mind has an interesting way of learning, you see...

I definitely appreciate David's vision on the ROM Hex editor. It's a whole toolbox. Which for a ROM based tool, is perfect. My problem is: I have a task that really only needs one good hammer to get the job done. HxD, for all it's current hiccups, does that one job well...

Provided it complies with opening my file...

[Sarasaworks]

So, I got cute and decided to do a little tinkering. Added a toUpper function just above void main(void)

Code: Select all

void toUpper(char *str){
	char temp;
	while(*str) {
		temp = *str;
		temp = toupper((unsigned char)temp);
		*str = temp;
		str++;
	}
}

And then appended the function to your file prompt:

Code: Select all

	printf("MAX FILESIZE [%d] BYTES\n", int_value);
	// TBD: file selection		
	printf("INPUT FILE: ");
	scanf("%s", &main_program_state.input_filename);	
	toUpper(main_program_state.input_filename);
  // OPEN AND READ THE FILE CONTENTS INTO RAM	
	f = fopen(main_program_state.input_filename, "rb");

But of course, cc65 is throwing a fit over VIDEOMODE_80x30, VIDEO_MODE_40x15, and this little section of code:

Code: Select all

unsigned char display_state[][] =
{
	//   dec                                 col col col
	//sp ofs d1  d2  d3  top bot wi  hi  bpr key mod byt
	// -------------------------------- MODE 1
	{ 3, 59, 10, 34, 58,  2, 58, 80, 60, 16, 40, 44, 72},  // 80x60
        { 3, 59, 10, 34, 58,  2, 28, 80, 30, 16, 40, 44, 72},  // 80x30
	// -------------------------------- MODE 2
	//{ 2, 28, 10, 27, 36,  2, 58, 40, 60,  8, 20, 24, 32},  // 40x60  (was hard to read, removed support for this mode)
	{ 2, 28, 10, 27, 36,  2, 28, 40, 30,  8, 20, 24, 32},  // 40x30
	{ 2, 28, 10, 27, 36,  2, 13, 40, 15,  8, 20, 24, 32}   // 40x15
};

X16HXD   git:(main) ✗ cc65 --target cx16  source/main.c 
source/main.c(261): Error: Size of data type is unknown
source/main.c(344): Error: Undefined symbol: 'VIDEOMODE_80x30'
source/main.c(365): Error: Undefined symbol: 'VIDEOMODE_40x15'

I'm running Arch, so I adapted your batch files as best I could. Even hard included the x16 header files into the main.c file. I'm a fiddle with it some more... Right after I take a nap. (Before my daughter wakes up from hers)