Well, yeah, that has to be our primary focus; in order to be useful for debugging, it needs to be as faithful as possible to the real hardware.  But, if people wanted to have a virtual calculator with 2 MB of RAM and a 100 MHz CPU, that would be easy enough to do, and maybe useful for some purposes.

Now this is a curosity question, since writing to flash is dangerous...does the routine work on all operating systems?

If you're talking about Brandon's write-to-user-Flash routine - yes, I think it works on all current operating systems.  Whether it'll work on future OSes, of course, is anybody's guess, but one of the things that bothers me about Brandon's routines is that they don't do any sanity checks to see whether the OS will work or not; they have no failure mode except to crash.

Ooh, that actually makes me wonder if emulators should have a way for some programs to detect if it is an emulator... That way if it isn't, you could make your programs not execute certain code

Seems like that would be a bug in the emulator, don't you think?

(There are various seldom-used aspects of the hardware that most emulators don't properly handle; you could probably find one of those to exploit.  But don't be surprised if later emulators fix those holes.  One of my personal goals for TilEm 2 is to eliminate as many of them as possible.)

Is there an Axe command to halt the CPU?  It's a good idea to do so while you're waiting for user input.

If you wanted to use the auto-repeat mode as I've described (i.e., timer keeps running and fires every N ticks, regardless of what the CPU is doing), then you'd want to:
- select the desired frequency (ticks per second) using port 30
- set port 31 to 3
- set port 32 to the desired number of ticks per interrupt period

Then, each time a timer interrupt occurs, you'd write 3 to port 31 again.  You wouldn't touch ports 30 or 32 after that, except to turn the timer off when your program finishes, and perhaps you might want to read port 32 to determine precisely how much time has elapsed.  If port 31 bit 2 ever gets set, you're probably doing something wrong.

If you wanted to use the non-auto-repeat mode (i.e., timer fires N ticks after the previous interrupt was acknowledged), then you'd want to:
- select the desired frequency using port 30
- set port 31 to 2
- set port 32 to the desired number of ticks until the next interrupt

and do that again each time an interrupt occurs (though you could omit the re-initialization of port 30 if you like.)

I think that's basically all there is to it.  There's also some weirdness (seemingly a hardware bug) where the programmable timers won't generate interrupts if you turn off regular timer interrupts (port 3 bit 1) and the CPU is halted.  Don't do both of those things at once, and you should be fine.

There are two independent "layers" here, which are often confusingly lumped together.

First, we have the routines EditProg and CloseProg.  These routines are documented in the SDK guide.  EditProg allocates all free RAM into a given variable; CloseProg reverses the effect.  In order for this to work, the iMathPtrs are used to remember which variable is "open" for editing.  You shouldn't ever modify iMathPtr1, iMathPtr3, or iMathPtr4; you'll presumably need to modify iMathPtr2 in order to change the size of the variable.

Second, we have the "edit buffer" layer.  An edit buffer is a region of RAM that stores text for the user to edit.  The buffer might be allocated using EditProg (which is what the OS often does, e.g. when editing a program or equation), or it might be a static buffer that you create in safe RAM somewhere.  Or it might be allocated in some other way; it's up to you.  The edit buffer routines have nothing to do with the iMathPtrs; they use only the pointers (editTop), (editCursor), (editTail), and (editBtm).

An edit buffer consists of three parts: "head", "gap", and "tail".  The head contains the tokens that come before the insertion point, the tail contains the tokens that come after the insertion point, and the gap contains all of the free space.  These three areas are defined by the four pointers I mentioned above:
   tokens          free space            more tokens
|***************|.....................|*****************|
^               ^                     ^                 ^
(editTop)       (editCursor)          (editTail)        (editBtm)
This arrangement means that all of the usual editing operations take constant time.  Moving the insertion point "right", for instance, means copying a byte from (editTail) to (editCursor), then incrementing both pointers.  Inserting a token means writing it to (editCursor) and incrementing (editCursor).  Deleting a token means simply incrementing (editTail).  (Of course, if you're dealing with BASIC tokens, you also need to consider the possibility of 2-byte tokens, but you get the idea.)  On the other hand, it's not random access: you can't just start editing at an arbitrary place in the buffer; you first need to "move" the insertion point to that location.

You can see from the above diagram that:
- (editTop) ≤ (editCursor) ≤ (editTail) ≤ (editBtm); all of the system routines will assume this is true, and will most likely crash if it's violated.
- If (editCursor) = (editTop), the insertion point is at the "beginning" of the buffer.
- If (editTail) = (editBtm), the insertion point is at the "end" of the buffer.
- If (editCursor) = (editTail), the buffer is "full".

Weird.  Have you tried installing any official apps from TI?

Oh, and maybe this is a silly question, but did you edit the application header to use the correct key ID?  I've never worked with TI's 68k development tools, but they presumably default to using the 14F03 key (a special key that's only accepted by their emulator and isn't used on any real calculators.)

I was wondering about that. I'm guessing that the 0109 key is like the 010A key in terms of usefulness and popularity. Speaking of which, why isn't USB8X signed with it?

Maybe because usb8x was last updated in 2007? 

Maybe try using the 0103 key instead?  Unless you're doing stuff that specifically requires the Titanium hardware or OS 3.x, older 89 users will thank you.   In any case, I don't think I've ever seen any apps in the wild that used the 0109 key.

Great.  Thank you!