Goto A would jump to Lbl A. Repeat getKey(15):End waits until the user presses clear.
As for the code, A is always increased, not just when a key is pressed. What might work is checking if the byte is non-zero, after the byte is stored. Also I would change lines like this If K=36:7→{N+A}End to If K=36:7→{N+A}:End. There's more optimized ways to handle it, but the way you have it works enough. Btw numbers in axe/asm can only be up to two bytes. trying to make a three-byte number won't work.
Axe is a lot less complicated than asm, but has some of the same concepts (pointers, data, etc)
* Darl181 wrote mine not in one minute, but two...?
Personally I prefer not to go into the ascii art and stuff, normally I open a readme to figure out how to use something I've drafted a few "MSD8X-friendly" readmes (because the new msd8x can only view the first graphscreen-sized page of a txt, which is about the second the second line of this post ) which just jump right to the important parts.
Just as a curiosity, is this the same thing as the MODE ALPHA S self test (just started differently, from boot rather than called by OS) or is it more thorough somehow?
Squidgetx made that routine, so idk really But iirc what length() does is it goes through data until it reaches a zero, then returns that number. If this is looped and used properly one could skip a definable number of [00]s, which the programmer could put in to separate strings and such.
Something to remember: Axe and basic are completely different. The only thing they share are the editor and the tokens. So a good part of the stuff that works in basic won't work in Axe, and vice-versa.
So waht you're trying to do with this is just have one number be put in, or a string of numbers? Because the code above will only store one number to the variable. (actually I don't see the point of using length() in this, what are you trying to do with it?)
Ok, it's hard to tell what's wrong with this, but Axe 1.0.X has some major glitches. Avoid.
Try this. Take out a battery. Press and hold DEL. While holding Del, put the battery back in. It should say it's waiting for an OS. At this point try re-sending the OS using TiLP or TI-connect.
See if that works...
EDIT: what did you run beforehand that you think might have caused this? Axe 1.0.X? Some OS-modding program that went haywire?
Paint.NET It should be somewhat the same process in gimp... Here's now in a nutshell:
Spoiler For lots of text:
1. Find a color scheme you like--be it blue, LOPN pink, or something as simple as gray. Pick out three different colors, the base/normal color, one somewhat lighter (as if lights hitting it), one darker (as if it's in shadow)
2. Draw the sprite, on an 8*8 (or whatever) canvas. Resize to 4x original size (32*32, normally) using "nearest neighbor" as resampling (keeps the blockiness).
3. Say 1 is the base color, 0 is the dark color and 2 is the light color. So if you have 1111 1111 1111 1111 beforehand, edit it so it's like 1222 0112 0112 0001 Basically, use the pencil to draw the light color on the top and right, dark color on the left and bottom. Or change accordingly if you want the light to come from somewhere else. For the lighting I have in these, leave the corners meeting in an up-left manner (and down-right) gray. Look at the pictures above for examples.
If you're using the brush, make sure antialiasing is off btw. Also make sure the background color is transparent or distinct from the three chosen colors, you'll need to differentiate them later.
4. Now re-size to what will be the final size, 128*128 or whatever. Select everything but the background color that's hopefully different than the three colors in the pic.
5. Gaussian blur, fiddling with the radius until you like the result.
6. Make any finishing touches (transparent background, extra cropping, noticing mistakes and ctrl+z'ing back to step 3 to fix it, etc
Input is really buggy, personally I'd only use it as a last resort. You'd probably be better off making your own input routine (or use one from the routines thread, such as this from the routines thread)
.ATEST .[00000000000000000000000000000000]→Str1 Zeros(32)→Str1 .Zeros() does the same thing, but it's easier to code in in this case :P .worked with initial bunch of 00s as well "0123456789-+/*^,()"→Str0 For(I,0,15) {rand^18+Str0}→{Str1+I} .counting from zero is usually more efficient, in this case the -1 is omitted End ClrHome Disp Str1 Repeat getKey(15) .wait until clear is pressed Pause 10 EndWorked without a problem for me.
It probably isn't displaying the string because it crashes before it gets to the code to display the string.
EDIT: {Str1+2I-2} ? That would make it work with two-byte numbers if you had the r. Just for the record, two hex digits (ie [00]) make one byte, not two.
EDIT2: The code from before you edited it, meaning the code with {Str1+I-1}, works correctly. What might have happened is it displayed the string and quit so fast you didn't see it? Try putting a Pause 1900 at the end (pauses for about a second) and then see what happens.
Just as a hint/rule of thumb, you can count from zero--so that would be For(I,0,15). Also iirc parenthesis, for the most part, should be closed.
At what part does it crash? What might help figure out what's going on (because frankly I'm kind of confused at this point as well, I'll prolly have to test it or something ): put in some Disps so you can tell how far it gets into the code before it goes.
Is this the entirety of the code, or is there something else in the program that might be messing with it?
7: One into which a person (who's a complete newb at RPG's) can enter and won't be lost from the beginning, wondering what "mana" or whatever is. 8: Different difficulty levels (read: easy =P)
Show Posts
) which just jump right to the important parts.
(read: easy =P)