I think the speed results may not be what you expected. In the following table, DrwXX is a custom routine that draws the image as a series of 8x8 sprites using Pt-On(), and BmpXX draws the image using Bitmap(). The numbers under each of these columns is cycles taken (fewer is faster).


X       Y       Drw16   Bmp16   Drw24   Bmp24   Drw32   Bmp32   Drw64   Bmp64
0       0       3647    12881   9574    24981   14986   41013   75653   144460
1       1       6599    13799   13797   26814   20944   44068   89311   153035
7       7       11414   21017   18544   41256   29823   68137   89382   215672


As you can see, bitmap drawing is actually much slower than drawing a series of 8x8 sprites, because the routine has to keep track of more values, it uses a variable drawing mode, and other things. However Deep Thought raises a good point that there's no reason this should be slower than cobbling together a bunch of smaller sprites. I've made a note to attempt to vastly improve this routine.

Hmm, it seemed to work in my tests. The only reasons I can think of why it wouldn't work are bad name input (Str9), size input too large (L), the code being copied incorrectly, or a bad/old version of Axe.

If you can post the source 8xp and tell me what version of Axe you're using, or if you can post the compiled 8xp, I should be able to tell you if the problem is either of the latter two possibilities. The former two possibilities you could check. Alternatively, if you're testing this on your calculator and can't easily transfer files to a computer, if you've made no changes to my code and could tell me the size of the compiled program STR9PRGM in the memory management menu and your version of Axe, I may be able to tell you if the problem is one of the latter two possibilities, although I couldn't pinpoint a copying error.

I'm not sure how exactly you want your program to work, but I'll give you a few basic details that should provide most of what you need.

To get a pointer to an OS variable in RAM:
GetCalc("var_name")

To find the size of an OS equation, program, appvar, or string:
{pointer_to_var-2}?

To create an OS variable and get a pointer to it:
GetCalc("var_name",size)

To copy data from one memory location to another:
Copy(copy_from,copy_to,size)

Using these pieces of information, you should be able to create a simple Axe program that creates a program and copies the contents of Str9 into it. :)



If you'd like to see a simple Axe program to do this, I'll put two such Axe programs in spoilers. The first will be the normal version, which should be a bit simpler to understand, and the second will be the optimized version. But I feel confident that you won't need to peek to figure it out. :)

---

EDIT

So apparently I completely misunderstood the request. It was how to create a program whose name is in Str9, which makes a lot more sense. As an added detail, TiAddict added in IRC that he wanted the program to be created with a size specified by the OS variable L. Here's how I would do it. And don't worry about that hexadecimal number, that's just a free memory location that's well-sized for what we need and shouldn't be used by anything else, which I got from thepenguin77's excellent list.

.STR9PROG
?9D8A?°Name
'prgm'?Name
GetCalc("Str9")?S
Copy(S,°Name+1,{S+2}??Z)
 and 0?{Z+°Name+1}
GetCalc(°Name,float{GetCalc("varL")})

Just about a year ago, mrmprog asked how to get the calc ID in Axe, and the answer is using assembly. Here is my answer from a year ago.

---

Since you're asking about just using the ID for checking, you could use a smaller piece of assembly combined with a bit of Axe to do what you need. For example, this code would cause any calculator except mine* to freeze:
Asm(EF7E80)
While 1
End!If {?849C}?-?E198
*1 in 65,536 calculators share this value, but the chance of a classmate's calculator sharing this value are low enough that you probably don't need to worry about this.

?E198 is a 2-byte value I took from my calculator ID. Obviously if you wanted to use this protection method, you wouldn't want to protect your program so only I could run it, you'd want to protect it so only you could run it. To find the value of those 2 bytes in your calculator ID, run the following code, and then replace E198 with the output:
Asm(EF7E80)
Disp {?849C}??Hex


---

As a second line of defense, if you think these people are smart enough to grab your source code and find and remove the check above, you can get really tricky and obfuscate one or two constant values. It would make your program slightly larger, but it would certainly make the ID-based protection harder to circumvent. The more strange the constant value you're replacing, the harder it would be for someone to decipher the true value. For example, here's some code I wrote recently in which I have obfuscated two 2-byte values with a 2-byte value from my calculator ID:
ReturnIf +P?r? and ?DF-({?849A}?-?BCBE)*3·({?849A}?-?481F)

That could would only execute properly on my calculator. Because of what this specific piece of code does in the program, this would not cause a crash on other calculators, but the game it's a part of would be unplayable. The format of these obfuscated constant values is ({?849A}?-(id_value+real_constant)). Find id_value using the code two blocks above for finding the value of {?849C}? for your calculator, and just change that to {?849A}?. And make sure to calculate (id_value+real_constant) manually! If you can't easily calculate with the hexadecimal value of {?849A}?, you can change the code to find its value to display the value with ?Dec instead.

In Axe 1.0.0, a new optimization system was added: a peephole optimizer. Unfortunately, with it came quite a few bugs in its initial and few following releases of Axe. Axe 1.0.5 is one version which has a few bugs, one of which affects any program that contains a Copy() command for which the third argument is a constant (in this case, 64).

The best way to fix this would be to upgrade to the latest version of Axe: 1.1.2. Alternatively, you can fix this temporarily by disabling the peephole optimizer when compiling by pressing ZOOM to compile your program from Axe's list of source programs to compile instead of pressing ENTER.

Constants cannot be declared the first way because starting a line with an operator results in the assumption that what precedes the line can be anything, not just a constant. Constants also cannot be declared the second way, although because there's no line separating them, I feel like support for that could be added easily enough. Neither of those methods save space in the executable since constant definitions don't consume any physical data, but I can see how the second one would be useful for saving space in the source program. Maybe you should take that on over to the Features Wishlist.

Netham45, it looks like that mod only adds the canoical tag to pages in the normal view, meaning not imode, wap, wap2, or print preview. Which doesn't really solve the problem at all.

Optimized a bit. The largest optimization was removing end checking, because it's impossible for an application not to have a number of pages field. I also optimized the search loop by rearranging it a bit to remove the unconditional jump.

FindNumPages:
;Inputs:
;     The app base page is loaded in MemBank1
;Outputs:
;     A, (HL) is the number of app pages

     ld hl,4000h
     ld a,81h
     ld c,a
FNPLoop:
     dec a
     cpir
     inc a
     cp (hl)
     jr nz,FNPLoop
     inc l
     ld a,(hl)
     ret