It's certainly not impossible to build your own program editor. However, there are lots of OS calls that would assist in providing functionality of the OS editor that you don't have access to in Axe. Namely, you'd have to handle input entirely yourself, translating keypresses to tokens and making your own menus.

If there are any specific problems you're running into, ask directly about those.


By the way, if you simply wanted a small font program editor to use, there's a version of zStart that replaces the OS editor with one. It was released in a mostly completed state when the developer was more or less stopping calculator development, so there may be a few things wrong with it that won't be fixed. But I think it works for the most part. And zStart provides other nice features, especially for Axe developers, so you should have some version of it anyways. If you're interested, grab the proper version attached to this post (the first is for the 84+ and the second is for the 83+).

Isn't that what the Asm( token is for?

Asm(HEX)   Native assembly code written in hexadecimal is inserted at the current position.

Yes, I am trying to convert compiled asm code to hex to run in Axe.
I just used to power off feature as an example.
I am also just trying out different commands. I never know when this knowledge might be useful! 

Then you'll want to use this tool to "unsquish" the program into the hex bytes.

I think only the specific version that Runer112 linked to has that feature.

If you're interested, grab the proper version attached to this post (the first is for the 84+ and the second is for the 83+).

I loaded it in wabbitemu and the version numbers are the same.

Since the small font editor version was not actually officially released, I think the author didn't increment the version numbers. Perhaps the easiest way to know if you have this version or not is that all previous versions of zStart are only one page (16834 bytes) large, while the version with the small font editor is two pages (32768 bytes) large. Also, you can't actually turn the small font editor off, so you'd certainly know if you had it.

Also, through the getcalc( command is is possible to create self modifying code assuming you knew what you were doing?

Self-modifying code is certainly doable in Axe if you know what you're doing. But I'm not sure how GetCalc() would factor into it without knowing more about your intent.

I am writing a program to restore some of my files (after RAM clear thanks to zStart) and I am using the copy command.

I'm skeptical that zStart would actually cause a RAM clear unless it was abused a bit... but anyways, you should really keep all your source code archived to keep it safe, since zStart lets you edit archived programs.

Does the size command {pointer-2} not work of files? It works fine if I just manually input the size but otherwise it just copy's one bite.

As far as I know, that works for files. Make sure you're reading a 2-byte value by appending ^r to the closing brace. If this isn't the issue, I can't immediately offer any ideas to fix it.

On a different subject is there a way to run already compiled programs (including the ability to call subroutines) to bypass the compiled code limit?
I know about axioms to circumvent this need but I would like to not have to use them.

I know you said you'd like not to use Axioms, but there's really no easy way to do what you're specifying without one. Specifically, the RunPrgm Axiom lets you run external assembly programs. If you wanted to run specific subroutines, you'd need to create your own convention, but that shouldn't actually be that hard.

But before turning to this, there may be a few less radical ways to solve this problem. If the issue is that you're running into the executable code limit, which is about 8KB, try compiling your code as an application or using the Fullrene Axiom. Both remove the executable code limit, although the total size of your code and data combined is limited to 16KB for applications and however much RAM the user has available (you can generally expect about 20KB) for programs using Fullrene. Also, Fullrene is known be a bit unreliable.

If the issue is that your application or program is too large due to containing lots of data, try externalizing data into appvars to keep the size of your actual program to a minimum. There's no clear/documented way to do this, but if you'd like to, ask and ye shall receive help.

For self modifying code what numbers correspond to which command tokens?

If you're aiming to change more than just a numeric value in code, SMC is probably not the way to go, because code can vary wildly in size and format based on what it's doing. In what context are you imagining using SMC? I'd imagine that there's probably a more reasonable solution.

SMC generally means modifying the currently-running executable, which is different from the source code. So even if you did this, the results would not be visible later. Simply displaying information like this is the easiest (and the sane) way to go.