010A.key is a key that only works for the 84+.  0104 (which is included in the rabbitsign binary) works for both the 83+ and 84+.

Easier than calling SetExSpeed, you can set the speed yourself:
 in a, (2)
  add a, a  ; check if on a TI-83+ BE
  jr nc, is_a_ti83p
  ld a, 1
  out (20h), a
is_a_ti83p:

or use MichaelV's method, which works because port 20h is the same as 0 on the 83+ BE (so this also resets the link port):
 in a, (2)
  rlca
  and 1
  out (20h), a

But if you're writing an Ion/MirageOS program, you need to be sure to set the speed back to 6 MHz (write zero to port 20h) before exiting, since otherwise the shell and other programs won't work correctly.  In particular, depending on the shell, the ionFastCopy routine may not work correctly at 15 MHz.

Oh, and:

4) http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:put8x8sprite I tried to copy the first routine into Mimas, but it seems like Mimas cannot handle the line LD  D, (IX) ôo. Does anyone know what the problem is?

Yeah, that's a known issue with Mimas.  You have to write "LD D, (IX+0)" instead.

Somebody made a "Guitar Hero" type game a while back (with, if I remember correctly, 2-bit sound), so it's not out of the question to do sound and other stuff at the same time.  It's not easy, but it can be done.

For many games, it might be acceptable to freeze the action for a few tenths of a second (or display some simple animation while playing a sound effect.)  And with programmable timer interrupts on the SE, you could play simple sound effects in the "background", fairly effectively.  You'd just have to be careful to base your frame rate on a separate, consistent time source (e.g., the port 3 timers or one of the other programmable timers.)

For his purpose of parsing, during which key inputs aren't checked, it won't matter if he overwrites that. Although if he didn't want to overwrite it, I'm sure 1,093 bytes would be just as good. I've filled these 1,094 bytes of RAM with random data a few times before to see if it affects anything, and the calulator runs fine. I've actually been using the calculator to do other stuff since then, with this area of RAM having been filled with garbage, and no side affects have cropped up.

EDIT: Or, just to be safe, I remembered that Iambian mentioned something about this on IRC a while ago (here) when I was considering using this area as temporary storage:

Quote

[22:19:28] <Runer112> yeah, appdata is 8000h
[22:19:29] <Iambian> You're free to use that area regardless.
[22:19:44] <Runer112> appdata is completely safe for my purposes? whether or not i'm running an app?
[22:19:52] <Iambian> Thought you were talking about something that looks more important, like baseAppBrTab or something.
[22:20:21] <Iambian> Either way, this magic romcall that (I think) BrandonW found recovers most of it before you want to exit. bcall($5011) it is.
[22:20:52] <Iambian> It was noted in my source as "restores first 1087 bytes in RAM"

If you don't have a solid understanding of what a RAM area is used for, when it's used, and what the consequences might be of modifying it, how can you say whether it's "safe" for your application?

(Experimenting and finding things that seem not to crash is really not a substitute for this level of understanding.  To wit: I can infer from your comment above that either you have an 84+, or you never use Flash apps.)

"Restores first 1087 bytes in RAM" is cute, but wrong, and frankly, kind of a dangerous thing to go around telling people.

The term "safe" is meaningless without context: what is safe depends both on what type of program you're writing - i.e., the context in which it will be executed - and on what your program is going to do.  By safe, we generally mean that
 (1) a RAM area is not going to be modified by any system or library calls we intend to perform, or by the system interrupt routine, and
 (2) the RAM are is not already in use at the time our program runs (so altering the data there will not have any effect on the system), or more specifically, it won't be expected to contain valid data at the time our program exits.

In some cases we may also want to consider areas where the RAM is already in use, but
 (a) it can be easily reset to its default settings,
 (b) we can reliably ensure the reset routine does get called, regardless of when or how our program terminates, and
 (c) the user won't mind us trashing his or her data.

In brief: the RAM areas between 8000h and 843Dh (I'm going to go ahead and assume you didn't mean to include kbdScanCode and friends) are used by a lot of different system routines under a lot of different circumstances.  As far as I know, all of this memory except for baseAppBrTab is scratch memory (it satisfies condition 2 for most execution environments), but whether it satisfies condition 1 is dependent on what system routines you're using, what hooks those routines might call, whether APD is possible, and whether silent linking is possible.

As for baseAppBrTab, it does not satisfy condition 2 at all, and it is absolutely essential that the table be correctly populated when your program exits.  Realize that the primary purpose of the table is for performing application B_CALLs - so really, it ought to be correctly populated at any time when a hook might be called, or in a shell program, at any time when a shell library might be called.  In practice, using that area is so dicey that I would not feel comfortable doing so at any time when any code outside my control might be executed.

It says it's from China.

It looks fine to me.  Though, it looks like you probably would run into the apps-getting-deleted issue I was talking about, if you could actually get Axe to compile apps.

But it sounds to me like for whatever reason, the Flash unlocking code isn't working correctly.  The problem is, the way Brandon's method works involves sending some invalid commands to the Flash chip, and different chips may respond differently.  The method used in the program I posted above should be somewhat more robust, although I haven't tested it on all the possible platforms yet.

(By the way, my 83+ BE is even older - 1199A - and Brandon's method seems to work fine.  So, who knows.)

It is possible, I guess, that you have something weird going on in the certificate page.  If you send me a copy I could take a look - I think BrandonW has tools for backing up and restoring the certificate.

Edit: Yes, he does: http://www.brandonw.net/calcstuff/certtools.zip

An update for those who care: my app signing code works, and works pretty well; the remaining difficulties are with the practical side of writing and erasing signatures in existing apps.

Compiling apps with Axe seems to be a little flaky...

- Sometimes the application is deleted as soon as it's created.  I'm not entirely sure, but I think what is happening is that the "app-installed" bit isn't getting cleared, or isn't getting cleared soon enough.  At some point, Axe calls _Arc_Unarc (or maybe some other archive-related routine), and somewhere deep inside that routine, a routine is called that checks the app-installed bits, and deletes any apps that don't have their corresponding bits cleared.

(In case you weren't aware: For an app whose base page is (16h - k), (2Ah - k), or (6Ah - k), depending on the model, the app-installed bit is bit (k % 8) at address 5FE0h + (k / 8) or 7FE0h + (k / 8), depending on which certificate sector is in use.  Thus, if the 4000h sector is in use, bit 1 of 5FE0h always corresponds to the first installed app, regardless of the calc model.  If that's a one-page app, bit 2 of 5FE0h corresponds to the second installed app.  And so forth.)

So, you should be sure to clear the bit as soon as you write the app header and before you make any other OS calls, particularly anything archive-related.

- Sometimes, rather than an all-zeroes signature, the signature contains the bytes 02 0D 40 (not quite correct, as we discussed above) followed by a bunch of apparently-random data.  I'm actually not 100% sure this is Axe's doing, though, as it's proving difficult to reproduce.