congratz on the feature!

btw, program execution is a little complicated, but the main problem I have with it is Grammer being a program causes some issues for people like me who use Axe a lot and get RAM clears often. 

Yeah, I can see that and I do plan to eventually turn it into an app when I have time I personally am one that likes things like Grammer to be an app, but the advantage to having it as a program is for people who make games and don't want to send an app with it. When I do make the app version, I will have to change some things around (especially the SMC code :O ) and I will probably throw in a few features (like a menu to run programs from and executing archived programs).

This is awesome and congrats for the feature and interview. I think this definitively deserves Omni front page news as well. (along with Zelda 68k revival)

Yeah, there were parts that I had planned to copy to RAM anyway (to TempSwapArea, though, or whatever it is called), so I will probably copy any heavily used, small routines there or just copy it like the OS does (copy the calls to RAM as needed). Thanks!

Thanks guys Okay, I will see if I can add at least something today (maybe a screen scrolling method?)

Thanks
Also, I didn't notice this yesterday:

I know I'm a little late to respond here, but your local Radio Shack should have a 2.5 mm to 2.5 mm male to male cable.  This is what the calc uses, and if you really want one, there's one there.
Or you can be like thepenguin: Make an 84 transfer to an 83 from the 84's usb, through a silverlink, and into the 83 to remotly fix his Certificate.

My vote is for these routines to work over the I/O port.  This will ensure 83+SE and 83+ compatibility.

I actually now have a cord for the serial port, but my other calculator is on loan, now I can still play around with WabbitEmu, though!

Also, I have the screen shifting working (I am using Tangent( for now). I should be able to come up with a tunnel game soon, now!

Sorry for the triple post?

Okay, so here is another example, this time with up to 16 objects bouncing around. There is no collision detection, but I have gotten the idea to make a built in physics engine to Grammer This would speed things up, especially once I get to the special things like collision detection.
Question: What token should I use for accessing extended command sets?
Question2: What token should I use to pass arguments to extended command sets?
This way I can make a separate program that is a physics engine instead of bloating up Grammer with things not everybody will use.


So in this example, you can open up the source and change the number of added objects to bounce around (do not set N greater than 15 or less than 1). Otherwise, controls are the same as the previous example

As a note, there are 256 bytes of data in the program that are used for the objects, that is why there can be at most 16 objects at a time. Also, set Full1 for 15MHz mode and Full0 for 6MHz mode

I sure can What you can do is when you press enter to run the program, keep holding enter, and then hold mode, then release enter (while still holding mode briefly). This will reset the score


-so when the game starts, make sure you are holding enter (you have to press enter to run it, so just keep holding it
-at the same time, hold mode
-release enter, then mode