Axe Emulator

[Xeda112358]

Yeah, I noticed that the delay wasn't quite precise, but if you are adding that kind of delay, you should definitely make it possible to have a header that tells your programs to compile without restrictions o.o

Anywho, a few things I noticed: The compiled size is quite large compared to on calc (>400K, for the most part). Is there a way to reduce that? And is it simply because of a lot of header code or something? Also, about how easy is it to compile a source program in .8xp format to the computer executable? Is it a drag and drop kind of deal?

[jacobly]

I would like to have customizable delays, but keep in mind that currently the only delays are in DispGraph variants and Pause, so all code between these instructions run at full speed.

The files are that size because they are each statically linked so that there are currently no dependencies to worry about.  However, note that compiling an empty Axe program results in an executable that is 421,390 bytes.  This means that the unique code produced in, for example, TheQuest.exe is approx. 10,240 bytes, whereas the calc executable is 10,465 bytes (10,240 bytes includes L1, 15 variables, and code alignment).

Currently, compiling is slightly involved, but I should be able to automate most of this when I get around to it (Honestly, the only difficulty I foresee is linking, but I can always just automatically run another executable).  Also, if you drag and drop a file onto the exe, I plan to have it just run the program directly (compiling to an executable will more than likely require the use of the command line).

[Deep Thought]

Wow, that is really amazing. I can imagine it being really useful for testing Axe programs

[Yeong]

O.o very nice!

[Scipi]

Axe is finally coming to the computer!

I've been waiting for this. Now I might actually achieve learning it, lol

[alberthrocks]

Wow, this is seriously amazing stuff! Especially with leveraging SDL, using C, etc... you're crazy!

Not sure how hard it may be to extend this, since this *is* an emulator we're talking about. I think if there was a way to add color but still have the program run normally on a calc... bah, I think I'd stick to writing a parser for Axe PC Edition.

[DJ Omnimaga]

As I said on IRC when I tested this before you posted about it, this seems very promising and it might be quite useful for those who want to test a game without the need of a ROM or if it's in its current form, provide a quick executable of your game for quick testing (or even with the game on ticalc?).

There are some things I wonder, though:

-How does grayscale and motion blur work compared to the calc?

-Also ashbad on SAX chatroom a few minutes ago was being curious about how does the emulator or parser operates with Axe code. To me it seems to require the source code, rather than the compiled executable, but he was wondering how do you emulate the TI-OS and if you were actually including TI-OS code in the emulator (which I doubt you would do, since I'm sure you know copyright stuff very well) to allow the emulator to run Axe programs exactly as they are on a real calc. I myself think it is possible to do an interpreter that would mimic the calc screen behavior to a certain extent like you did, although Ashbad didn't seem so well convinced. He basically found the idea of an Axe emulator useless, which I disagree with (again, maybe it's just that he just has strong biases against everything Axe-related). However I'm kinda curious too, since your emulator emulates Axe programs surpringsly well it seems. Could you give a bit more info about how it manages to run without emulating any part of the TI-OS? In any case, if everything was written on your own and you really use the axe source rather than compiled executables, then that's even more impressive to me, especially that now we can play Axe games without even compiling them.

-How does it work for Axe programs containing multiple files, such as pictures, sub-programs, etc? Are they detected?

-Will in the future it be possible to have a version containing only the emulator, where you can choose the axe project to run, like in any other emulator, for those who have many Axe programs and want to save space? Of course standalone executables are awesome too, since now we can pretty much turn our Axe games into computer games.

-Will the language be expanded in the future so if, for example, below the Axe source header we put something like ANOVA("RES":320x240:Full), your exe file uses 320x240 full screen resolution instead of 96x64 windowed and ANOVA("COLOR":256) if one wants Pt-On/Off/Change to display sprite data in 256 color mode instead of 2 (monochrome) and to allow Line/pxl commands to be useable with colors too That would basically allow someone to create actual computer games by using Axe language, so they don't have to learn a new language if they ever quit calc stuff but still want to make old skool 2D games like Mario on the computer. TokenIDE/SourceCoder could still be used to write programs for the time being, although if both won't let people create 8xp files larger than 24 KB or even 64 KB, that might be annoying.

[jacobly]

-How does grayscale and motion blur work compared to the calc?

Because Axe uses high level commands for grayscale, I am able to just display it perfectly, without having to worry about dithering or blur.

-Also ashbad on SAX chatroom a few minutes ago was being curious about how does the emulator or parser operates with Axe code. To me it seems to require the source code, rather than the compiled executable, but he was wondering how do you emulate the TI-OS and if you were actually including TI-OS code in the emulator (which I doubt you would do, since I'm sure you know copyright stuff very well) to allow the emulator to run Axe programs exactly as they are on a real calc. I myself think it is possible to do an interpreter that would mimic the calc screen behavior to a certain extent like you did, although Ashbad didn't seem so well convinced. He basically found the idea of an Axe emulator useless, which I disagree with (again, maybe it's just that he just has strong biases against everything Axe-related). However I'm kinda curious too, since your emulator emulates Axe programs surpringsly well it seems. Could you give a bit more info about how it manages to run without emulating any part of the TI-OS? In any case, if everything was written on your own and you really use the axe source rather than compiled executables, then that's even more impressive to me, especially that now we can play Axe games without even compiling them.

The compiler program I wrote currently takes Axe source code and produces a computer executable.  This executable does not contain the original source, nor does it contain the executable that Axe would produce.  What it does contain, is native machine code compiled from the Axe source, and hand-written code for every Axe command that is currently supported (Also the calculator screen emulator).  The only thing that it has in common with TIOS is that it contains the data for TIOS's fonts and tokens (This data was created by hand).

-How does it work for Axe programs containing multiple files, such as pictures, sub-programs, etc? Are they detected?

I am already able to compile programs that use multiple program files.  I will definitely be able to support absorbing files, and I will probably be able to support reading and writing files.

-Will in the future it be possible to have a version containing only the emulator, where you can choose the axe project to run, like in any other emulator, for those who have many Axe programs and want to save space? Of course standalone executables are awesome too, since now we can pretty much turn our Axe games into computer games.

I plan to have a single executable.  By default, dragging & dropping an Axe program onto this file will just emulate that Axe program directly, without producing an executable.  However, using command line, I hope to allow you will be able to both produce small executables which require the Axe emulator executable in order to run, and larger stand-alone executables that run by themselves.

-Will the language be expanded in the future so if, for example, below the Axe source header we put something like ANOVA("RES":320x240:Full), your exe file uses 320x240 full screen resolution instead of 96x64 windowed and ANOVA("COLOR":256) if one wants Pt-On/Off/Change to display sprite data in 256 color mode instead of 2 (monochrome) and to allow Line/pxl commands to be useable with colors too That would basically allow someone to create actual computer games by using Axe language, so they don't have to learn a new language if they ever quit calc stuff but still want to make old skool 2D games like Mario on the computer. TokenIDE/SourceCoder could still be used to write programs for the time being, although if both won't let people create 8xp files larger than 24 KB or even 64 KB, that might be annoying.

I can't say for sure since I am currently focused on getting native Axe commands to work, but it is definitely possible.

[DJ Omnimaga]

Oh, right, I forgot you don't even need to get around LCD limitations for the grayscale. That's even better then.

And I see. That means it isn't really an emulator, though, right? Since to be an emulator, your software would have to interpret the axe source or a file containing it in its original form without having to convert it first. It's still nice, though. I guess  it might be more of an Axe Parser for the computer or something, unless I have my definitions of emulator wrong.

Good to hear it will support programs with multiple files. I worried it might only work with a few select Axe programs since a few complex ones use sub-programs.

And nice to hear.

And yeah at first you should make sure as original Axe it works. Just for the future it would be nice if there was a way to support different resolutions, color depths and maybe different default sprite sizes (such as 16x16).

In any case, good luck

[aeTIos]

TL;DR.
j/k I would abide you if you added color and size :O

[Sorunome]

Maybe if you extend it also make sure that you tell how large the pixel size is

[Hayleia]

Wow, that is really amazing. I can imagine it being really useful for testing Axe programs

True. My Pokemon game takes more than one minute to compile, and when testing, I can lose half an hour of coding just with this.
Awesome tool

[DJ Omnimaga]

Maybe if you extend it also make sure that you tell how large the pixel size is

Do you mean resolution?

But yeah if this was extended for non-calc programming, the essential stuff that would have to be added is 16x16 Pt-On mode, 8, 16 or 24 bit color mode (preferably 8 for size reason) and custom resolutions, to allow at least SNES-like game making.

[jacobly]

I finally got some more program working.

[jacobly]

Someone wondered if this was possible, and I was curious, so I tried it. Unfortunately, I don't think I will be able to this to an arbitrary program for a while.