Apple needs to get with the program. Even Nintendo recently allowed an app whose main purpose was implementing a programming language.

@DJ_O: Thanks for your warm welcome!

Also, since I fear it was buried, I'll reask (or rather bring attention back to) the concept of bi-directional save conversions. My question was if he could add a seperate utility binary that can transfer the save files used by emulators or dumped from actual carts to the Appvars used by Ti-boy and vice versa. A simple yes or no will do, but if Ti-boy stores the save data based on how it's saved (I think I'm saying that right, basically since it emulates the gameboy my logic seems to think) couldn't there be a way to do so?

Besides that, I am still quite impressed by the functionality of this Emulator. And since it is Beta, I'd like to point out the few little graphical glitches. (Wish I had already made screen-shots to show what I mean.) There are two with Kirby on my actual calculator (Hence, no screenshots ) first, when Kirby goes into water (such as in Castle Lololo) he appears to be rendered *behind* the water. Well at least that's my guess as to why I cannot see most of his sprite most of the time while in water, while sprite tracking still works so it *is* still playable, this seems to be a particularly troublesome glitch. I'll try today to get Wabbit up and going on this comp so I can provide more helpful examples. Then the smaller thing is the roughness of the sprite tracking. Can you set it to only track the center of the sprite? I'm not sure if that would help.

Yes, save conversions are one of the things on my to-do list.

As for Kirby rendering behind water, if that's what I'm thinking of (the "water" made up of a bunch of stars) it's actually a feature and not a glitch (that's how it appears on the Game Boy itself and it was fairly painful to implement).

The sprite tracking is imperfect by nature, because it tracks a certain sprite "slot" out of the 40 available in the hardware, and some games don't always keep the character in the same slot, and most games even have characters made out of multiple sprites because sprites are only 8 pixels wide (which is why it doesn't track the center of the character). A more effective sprite tracker would use the game's variables to tell where the main character is, but that's not something that can easily be automated.

You can change the background color around graphs, but who knows if you can do that (or even load a background image) via TI-Basic. I really hope they actually added all these features to TI-Basic as well. If they didn't for the sake of the barely existent backwards compatibility, then... well anyway, it seems the background images have at least 2x2 pixel blocks, so you wouldn't be able to show graphics like that using them. I wonder if they're keeping the Pic variables around, though...

Well, the real problem is that the game should get notified that the byte is received an exact amount of time (in clock cycles) after the data transfer starts, and TI-Boy doesn't even count clock cycles per instruction for performance reasons. I suppose I might be able to give it another try one of these days, though.

Hi, I get a Cartridge type unsupported error on a brand new TI-84 on Pokemon Blue and Super Mario 4. Any Ideas? Cheers 

Cartridge type unsupported usually means you're using a bad ROM, or maybe even a compressed ROM (i.e. still in a zip file), since makeapp doesn't decompress zips. Can you post the console output from makeapp for these files?

Well, unless all of the sound-related data in the ROM was at the very end, it would take a lot of work to both remove it *and* have the resulting ROM be smaller. Pretty much everything in a gameboy ROM relies on being located in an exact position.

Nope, it won't help at all. The apps are already as small as they can get, the Link's Awakening ROM even by itself can't fit on a TI-84+. 16KB is the smallest amount of space I can store the emulator itself in, and I don't exceed that.