I doubt I'm going to have a "Basic Mode". Its more likely that BASIC programs will be token data just like strings are text data and sprites are hex data and then there will be a command to execute that data.
fnOn and fnOff are the enable and disable interrupts commands since there is also the fnInt command and they just go together so perfectly for this.
To answer some of your questions. An MP3 player might be possible right now, but I think I will eventually add another sound command that reads raw data and plays something kind of like you're describing. I don't know how you would convert the sound into hex though, nor the compression ratio. It would suck to have to carry around 5000 extra bytes to play a 10 second clip.
Standard BASIC syntax would not be compatible with axe. What that feature would do is allow you to integrate regular BASIC calls into the program for some commands. It would be just as slow as regular BASIC when you do this, but it would make things like the Input command very handy. I haven't tried real-time token parsing yet so I don't know if its possible to do what I'm thinking, but based on my reading I think it can be done.
The reason I differ the syntax and programming style slightly from regular BASIC is becasue I set it up in a way that allows for executables that are smaller, faster, and more optimized that its predecessor. If I had used floating points for instance, it would have significantly increased program sizes and have huge slowdowns.
Scrolling to errors is something I'm for sure going to add later similar to how BASIC programs scroll to errors. The thing is I have to learn about parsing hooks, something I know nothing about, so I'm going to have to find a lot of information about and hopefully talk to some experts.
The source code for the compiler might be open once I completely finish it, however, the source code for the assembly routines is open right now so they can be improved and optimized by the public and people learning assembly can use these routines as templates like Axe does. I would love to make a computer compiler for axe since not only would it be able to generate the executables, it can translate directly into assembly language so it can be further optimized by hand. Its a really huge project though. It would honestly take about the same amount of time to write a computer compiler as has the original.
Hope I answered everything, feel free to ask if you have any more questions. I wish you luck on your programming endeavors!
I could compile it for an app fairly easily (an app that is just hex code and not signed). It would look just like a program, but unable to execute and you would have to extract the hex from that program on the computer and then sign it there and send it back as an app.
Is app signing on-calc really that hard? How does app signing even work? Isn't it just RSA encryption or something?
But most of those you can already do without needing assembly. Usually, you would compile some asm yourself and just read off the hex code. Its mostly if you want to make an Axe/Asm hybrid for improved speed/size/capabilities but still have the ease of use and on-calc programability.
I know I'm beating a dead horse here, but in case anyone is curious when you actually do use the sp register, I posted a little summary. I don't want to confuse anyone though, so no need to read this unless you have intermediate experience with assembly. It would be cool to have a lesson with tricks like these if you get to the advanced lessons (I don't know how far you plan to go since its for absolute beginners)
Spoiler For Spoiler:
Lets say you have a buffer with a bunch of 16-bit numbers you need to read through. You might have a loop that does this:
Loop: ld e,(hl) inc hl ld d,(hl) inc hl ;In total 26 Clock Cycles <do something with de> jp Loop Its way faster to use the sp register. Don't forget to have interrupts disabled.
Loop: pop de ;In total 10 Clock Cycles <do something with de> jp Loop
ld sp,(saveSP)
Same goes for storing numbers, but you use push instead of pop. The fastest way to clear the screen for instance is to load a zero into hl and then just push it 384 times when the sp register is on the graph buffer. That's only 4,224 clock cycles with pushing vs. 16,107 using ldir, which is 21 clocks per byte. Pushing is nearly 4 times faster in this case!
As you can see, the pattern here is that you usually use sp for speed critical processes becasue its generally a larger routine than the standard methods. Although, sometimes it is actually smaller when you have all the other registers tied up and you are doing this as an alternative to using a free ram location to hold the pointer.
That would be cool! Yeah, you just copy all the bytes down one by one. But remember this is asm, that takes about a millisecond. The hard part is the fact that you have to put the calculator in edit mode first and then keep track of the edit mode pointers. Basically, the calculator moves around all programs and variables so that your current program is last in the in line so expanding things to the end of it doesn't overwrite your other programs, you have the entire free ram to expand. Then when you're done expanding, you have to update the size bytes of the file and close the edit mode.
You're looking for the assembly bcalls "EditProg" and "CloseProg". Those require assembly input though, so even if you make it in Axe, you're still going to need some assembly. Also there are 4 other pointers that you need to keep track of in $84D3, $84D5, $84D7, and $84D9 which hold important information related to the editing.
Good luck! If you manage to get it working I would be very impressed. This gave me a lot of trouble when I was using this in Axe Parser to create the assembly programs. The TI-Developer's Guide is slightly wrong on some critical stuff so that really threw me off. Specifically, you need to update the program size manually, even though it says its done automatically.
[Pic1]->GDB1 EDIT: Also, does anyone know what DATA→NAME does? Use? Practical application?
You just used exactly what you're asking about in that example. [Pic1] is the "DATA" and GDB1 is the "NAME".
The problem with using an image in Axe is that unfortunately, the picture files only have 96x63 pixels, so it misses the last row. Usually what you want to do is just add 12 bytes of white pixels to the bottom or top. Here is how you display an image right now. I think I will automate this in the future:
:[Pic1]->Pic1 ;Store the picture in memory call it Pic1 :det(12) ;Add 12 zeros (96 pixels) to the bottom :conj(Pic1,L6,768) ;Copy all 768 bytes to the graph buffer :DispGraph ;Draw the buffer onto the screen
By the way, there is an even easier way to do it in 0.2.4 (not out yet) that I came up with. You can draw any buffer to the screen directly without having to copy it to the main buffer first by doing this:
:[Pic1]->Pic1 ;Store the picture in memory call it Pic1 :det(12) ;Add 12 zeros (96 pixels) to the bottom :Pic1->DispGraph ;Draw the picture directly onto the screen
EDIT: If anyone wants to do translations of any of the files that's fine. But they aren't done yet, so they would have to be re-translated in the future so keep that in mind.
Where do you come up with these wacky ideas? I literally laughed out loud at the title "Eat Nethams" and once I saw the screen shot. Quite a bizarre game. But nice job on this, it looks pretty good. Cool concept to use the ram as pseudorandom numbers.
I'm planning to eventually write an all purpose sprite editor for 8x8 and 16x16 sprites supporting monochrome, 3 color, and 4 color grayscale on-calc. It will be written in Axe itself, but I need to wait on it because I have to add reading and writing to the Ans variable so that the sprites can be imported and exported.
If anyone has any other good tools, particularly for the computer since I imagine many sprites will be drawn there instead of on-calc, please post them here. I am currently looking for a good program that can output z80 hex code for a 4 color gray bitmap, but I can't seem to find anything. I'm about to write one in C++ if I don't see anything soon, but I really don't have the time for that right now.
By the way, the standard and/or/xor still work as bitwise functions as long as the numbers you're dealing with are both single bytes. Only the double byte numbers require the new syntax.
What I meant by single characters is that it is more readable to write: "A*B" than it is to do "A times B" Similarly, "A&B" is easier to read than "A and B" (the ampersand is not the actual symbol, I'm just demonstrating)
Ya, smc would most likely not be supported. There is very little gain in terms of size or speed that you get with smc. I'm also not supporting using labels as numbers, becasue you have no idea how the code is going to compile and it can always change in the future when I start doing more optimizations. It would be too version specific becasue I anticipate changes in how the executables are made (not the syntax itself).
Those commands are still there, but they've just changed syntax. It makes the code more readable too because now you're using and/or/xor as single character operators just like addition, subtraction, multiplication, and the others.
Show Posts
