Announcement!

I spent several hours today thinking about the logistics, difficulty, and maintainability of creating an "Axe Shell" and then started to code my ideas.  I am pleased to announce that it appears this may become a reality in the next version.  I currently have about half the commands working with more to come.  I will explain some of the logistic problems I faced later.  This will be a beta feature to give me a chance to stabilize potential errors I might have made.  It is not recommended to distribute the executable until it stabilizes.

So first of all, what am I talking about exactly?  Ion, Mirage, and Doors all have a GUI application to act as a shell but Axe does not and I'm not going to add one either.  What I'm referring to, is that instead of copying all the gigantic Axe routines into each program (such as DispGraph, Sprite drawing, Sound, Archive reading, and literally everything non-trivial) the program will use the Axe app itself to find and call the big routines.  This of course loses platform independence in a sense, but so do all the other shells.  This really isn't a shell though, its more of a framework.  Which is why I'm call this the Axe Framework or AXF.  With the bulk gone, this can reduce programs by up to 3000 bytes!  In general, I'm seeing 10-20% reductions in my testing suite.

Now for some logistics.  The way it works is that the program gets the standard ion header plus some extra code to locate the Axe app, show the message "Axe Required" if its not found, and do all the necessarily paging.  Its comparable in size to the DCS or App header.  This is both so that I don't have to actually create a shell and its small enough for a header anyway.  But the looming problem is to map the Axe calls to physical addresses in the app.  As I improve and optimize the Axe routines, the addresses will change, causing old executable to need to be recompiled to work.  Normally to fix this, the other shells provide a fixed jump table that then jumps from there to whatever moving code it eventually needs to reach.  But the problem with Axe is that many routines "hijack" other routines to skip parts of code rendering a fixed jump table unusable.  What's worse, the axiom system of replacing absolute and native jumps and calls makes it impossible to execute over it.

To solve both of these, I have a table of subroutine "segments" that have all the code that can be skipped over and then hijack the original routine.  Some routines I do have to make complete or partial copies of, but that's alright.  In those cases, I leave a bit of buffer for future optimizations and changes.  The only other issue I'm worried about is how Axioms will interact with the framework.  Most Axioms should work, but a few really complicated ones could fail if they jump into routines past the entry points.  But that is super hackish anyway.

Some other things on my mind:  I could speed up some routines since the size of the routines no longer matters.  Routines like multiplication are easy to unroll, but others like DispGraph are still limited by the screen driver.  Also, this framework is just as useful to assembly programmers!  I have doubts about how many would actually want to use it though, but nonetheless it is now possible to do that.

Thoughts and suggestions?

I see, so its mostly default options that this affects.  While I disagree that those settings are intuitive defaults in the example tilemapper, I can definitely see situations where it could be useful to provide default settings for options that rarely need changing.  There are several ways to do this:

• A specific ifdef command
• A isDefined() command
• A "Define if undefined" command

I'm guessing the last one would be most convenient for programmers since it's targeted at default values.  One idea for the syntax could be a double store arrow such as 8→→^oVar to mean "If Var is not already defined make it 8.  But if it was defined, keep it as it was".

I'm not so sure if I want an "IfDef" type command.  What's wrong with just defining a constant as 0 or -1 if its going to be unused?  Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.

Is "\\mystring/" the literal you typed in?  That will search for "\mystring/".  If you are specifically trying to regex out websites, you can try something like "www(\..+)*" for instance.

This looks great!

The reason your original code didn't work is because you compiled it to an app.  This means that all data in your program is read-only since the program is put in flash rom.  Now that said, you can still keep your program as an app, but you have to manipulate your levels in ram.

You were on the right track before when you did "Copy(K,L1,714)" to put the level data in ram then make changes like "5->{L1+20}" for instance.  The last statement where you copy it back to rom is not going to work though.  Instead, use "L1" as the pointer when you render the graphics instead of K since L1 holds the correct data with the correct modifications.  If you need L1 for other things though or you need more space than L1 can possibly provide, you can create an appvar in ram any size you want and use that pointer instead.

What Hayleia is talking about is that its generally a good idea to store data to static pointers instead of variables because the code optimizes better and uses less memory.

Also I saw on your Cemetech post that you had Dispgraphr in a loop with getkey.  If you want a better quality grayscale, you should not use the super slow "getkey" command.  Also you should turn interrupts off.  Using the direct getkey(#) is recommended instead.  This gives you consistant timing between frames.  You might even need to add some more pause back in.  I know on hardware the 4 level grayscale is almost completely out of sync if constantly updating unless a small pause is added.

That's basically A<<0 which is a highly optimized command to return 1 if its negative and 0 if its positive or zero.  That separates out the negative case.  Then !If A can extract the zero from the remaining case.

But if you need the exact number output, I think this is fairly uncommon so I don't think that a command for it is needed.  But here it is in optimized Axe code: A>=>=0?A?1,,-1

EDIT: The white rectangle thing I guess I can see useful, but each rectangle routine is over 100 bytes, which is much larger than making your own subroutine to do the same thing with the existing commands.  The only time it would be useful from a optimization perspective is if you only use 2 out of the 3 rectangle routines in your entire program at any point, or you are super super pressed for speed because you're drawing hundreds of white rectangles every second.  I will consider adding it though, just be warned it can easily bloat your code more than using the existing commands.

Wow thanks!  I was considering that, but I assumed the overhead would be large, not smaller!  Thanks!

Also, I could move the labels to the data section of the code to make it even faster!

 ld de,-range
  add hl,de
  jr c,default
  add hl,hl
  ld de,jumptable_end
  add hl,de
  ld e,(hl)
  inc hl
  ld d,(hl)
  ex de,hl
  jp (hl)
default:

Exactly