General feature requests:

• Preserve the OS backlight setting
• Suppress final keypress on exit (I believe this can be done with a properly placed B_CALL(_GetCSC))
• Allow quitting from the main menu with CLEAR (and is that confirmation to quit necessary?)
• Cancel capability in data entry (CLEAR?)
• Backspace capability in data entry (DEL?)
• Everything CalcSys does that MicrOS still doesn't *runs* (mainly VAT interaction)

Hex editor feature requests:

• Use a unified representation for pages (ports 06/0E/07/0F, port 05, and the cursor location all use different notations)
• Make the string find location default to the location VARS jumps to
• Make a string length specification of 0 enable auto length (partially a feature, partially because 0-length strings don't make sense)
• Allow hex string data entry (lets the user just keep entering data until they press a key to stop)
• Allow searches to wrap

Hex editor bug reports:

• Pressing VARS or G to goto an address doesn't actually put the cursor on that address. The address occupies the first address in view as expected, but the cursor stays in the relative spot on the screen it was before.

Readme issues:

• "Go some free RAM you can use for the string find feature"
• Add a mention that ON halts searching

With 84+SE calculators manufactures less than about 6 years ago or so, TI cheaped out and cut the amount of RAM inside them from 128KB to 48KB to probably save a tenth of a cent per calculator. 48KB was never enough for Pokemon, so for a long time, newer 84+SE calculators simply didn't support it.

However, with the latest version, Pokemon has been partially supported for new 84+SE calculators. The reports I've heard say that the game almost entirely works, except for one moderately annoying flaw. Changing PC boxes doesn't work correctly, because each Pokemon has a fairly large amount of data tied to it and the extra RAM used by Pokemon games was to store all the data for Pokemon saved on the PC.

Getting a second set of eyes can greatly increase debugging ability. Sometimes you're just completely blind to a certain error for no apparent reason.

Sorry for asking a lot of questions here but I think its better than making new threads. So I was wondering about a few things:
1. Are axe programs in the Full 15mhz mode by default
2. Is using things like rotC, flipH and flipV instead of making sprites for different angles better (speed/space wise)
3. I heard that separating if statements (If A:If B) is faster than combining them (If A and B), is this true? Which one uses less space also
and finally
4. Whats the risk of using L3 for data, or is it safer to just use a pseudo list (L2+250 being the start of it) if you know the data in L2 wont extend that far
edit:
Oh yea does sound with the freq command play synchronously (meaning if its told to play for 1 second will it wait 1 second to go to the next command or does it play as stuff is happening)

(also this is what I have so far for my game thing, ignore the completely terrible explosion sprites and stuff)

1. Nope, all assembly programs should start at 6MHz.

2. Using the sprite rotate/flip commands will always be slower than not using them. flipV() takes 339 cycles, flipH() takes 1908 cycles, and rotC() and rotCC() take 2661 cycles. All four rotate/flip subroutines take up 73 bytes of space in total, so if you only have a few sprites that have rotated versions and the extra data isn't much larger than that, it would probably be smaller (and faster) to just include the rotated sprites as data. With more sprites, it begins to become more of a trade-off between size and speed. But if you want the speed of not using flip/rotate commands when sprites are drawn without the size of including extra copies of lots of sprites, you can still get the best of both worlds. Just include one copy of each sprite and then producing the flipped/rotated copies at startup time and save them in a static RAM area like L?-L? or a temporary OS variable.

3. In that direct comparison, separating the if statements does not save space. In fact, it costs 2 bytes. However, it does have two advantages. The first is that by breaking multiple conditions up into multiple if statements, if any condition is not true, none of the following conditions are even reached, thus saving time. The second advantage, and probably the more common reason why this is done, is that it works when one or more of the conditions doesn't actually depend on a boolean being zero or one, but on an integer being zero or nonzero. The and operator is an 8-bit bitwise AND, which works just like a logical AND for boolean values. But it doesn't work like a logical AND for integer values. (In case bitwise AND needs a bit of explanation, here's the wikipedia entry for it)

4. The Commands.html file included in Axe releases explains fairly well how large and how "safe" the L?-L? areas are. If you don't use any grayscale drawing commands or StorePic/RecallPic, L? should be safe to use.

5. The Freq() command in Axe is fairly primitive, so program execution doesn't continue while the tone plays. Having notes that play in the background requires fairly complicated interrupts and timing logic, so it hasn't been enough of a priority to find its way into Axe. However, I'm keeping an eye on Iambian's interrupt-based audio solution, which seems quite good. It might eventually be available as an Axiom (an external library for Axe programs).

Quote from: Runer112 on August 02, 2013, 02:32:52 pm

To edit archived programs, I would highly suggest using thepenguin77's zStart instead of CalcUtil.

Ok thanks for the suggestion I'll try when my calc will work

Quote from: Runer112 on August 02, 2013, 02:32:52 pm

Regarding the unknown error, I'm fairly confident I know what causes that and a fix for it is in the pipeline.

Ok, then I'll check for updates every day (or more)

I'm not sure the next version of Axe will be coming out that soon. there are still things I want to add still, and with the things I have added so far I've broken things and need to debug them. So there's still work to be done.

To learn if there's a new version of Axe released, there's a much simpler way than checking the thread manually. Go to the Latest Updates thread, and above the first post, click on the "Notify" button. All new versions of Axe will be posted in that thread, and the notify feature will send you an email the instant a post is made.

Yes, this is the right place to ask. I didn't actively debug the code, but I suspect the problem has to do with the bullet logic. My suspicion is that, as the result of a few code issues, the number of bullets is getting decreased when it's already zero, wrapping around from 0 to 65535 and then causing a great big mess. Here are the three culprits that appear to me:

• For(I,0,B : This loop will parse one more "bullet" than you want: the "0th" bullet. The fix for this is simply to increase the lower bound of the loop to 1.
• Copy(J,K,3)ʳ : Copy() copies data from the first pointer argument to the second, but you want to copy from K to J, so they need to be switched around.
• When a bullet is removed during the bullet processing loop by copying a bullet from the end of the list over it, the copied bullet still needs to be processed, but the loop counter will increase for next iteration and skip it. The usual way to fix this is to decrease the loop counter by one when a bullet is removed/overwritten to negate the next iteration's increase.

Here's your bullet processing code with the above fixes applied:
For(I,1,B
I*3+L1->J
{J-2}-1+{J}->{J}
If {J}=57 or ({J}=0
B*3+L1->K
Copy(K,J,3)^^r
B-1->B
I-1->I
End
End

I quickly tested plugging that into your code, and it seemed to work great. I've also attached the working source program; not that it's really needed, because the changes made were quite minimal and should be easy to apply directly to your copy of the source.

Good luck expanding this code out, I'd love to see a full-fledged game result from it! If you have any other questions with your project in the future, you can always post them back in this thread and they should hopefully be answered swiftly as well.

That idea has crossed my mind before, but I never really thought about how it could be implemented. Now that I think about it, it's definitely a useful feature, one that I've wanted myself sometimes. After a bit of pondering, I came up with a syntax that I believe should work well from both the appearance and underlying implementation standpoints. To specify a target, you would put a store arrow immediately after the name in the header, followed by a letter, like this:

• :.THING      (Default target)
• :.THING→N    (No shell program)
• :.THING→I    (Ion program)
• :.THING→M    (MirageOS program)
• :.THING→D    (DoorsCS program)
• :.THING→A    (Application)
• :.THING→F    (Axe Fusion)
• :.THING→V    (Appvar)

How do you guys feel about that syntax? Also, note the additional Appvar shell. I thought that was a good idea as well. It's another thing I've wanted in the past but for some reason never thought about actually adding.

Right off the bat, I'm not going to be showing people a hex view. To me, it's not productive at all and discourages actual use. If you want to see hex, you can anyway by switching the view mode, but what you will see instead of hex is a pitch notation A-G, prefixed by which octave it is. For example:

Code: [Select]

CH1 CH2 CH3 CH4 TIME
0A. 1A. 3G. 3C. /16
The time code only really makes sense if you've defined a tempo earlier. In the example above, I defined a sixteenth note. The dots in the pitch notation is to show that it is not showing a hex value, which *can* happen if the hex underlying the pitch value doesn't correspond to anything the program knows. As for timing, it'll make a best guess if the time value is off, tho display "" if it simply can't figure it out.

How will sharps/flats be represented? It seems to me that it would be best to use an extra character to specify when note values are hexadecimal, making hexadecimal values always three characters, and then using the third character in letter notation to display sharp/flat when necessary.

Also, notes with octave values attached traditionally have the octave following the note letter and sharp/flat symbol. What do you think about representing notes more like this, then:

CH1 CH2 CH3 CH4 TIME
A♯0 $1F G♭3 C3  /16