TilEm 2.1 will support both sound and external/virtual link cables.  It's basically finished at this point (the current version in SVN is quite stable and usable); I haven't officially released it mainly because it'll take some work to track down and compile all the libraries needed for the Windows version, and also because Lionel keeps thinking of new things to be done before releasing the new libti*.   We're almost there, though.

As far as I can remember there wasn't anything wrong with OS 1.17.  I think, however (and this might be what you're thinking of) that OS 1.17 was released at around the same time as TI switched to a different LCD driver, which runs slightly slower than the LCD drivers used in earlier calculators, and therefore broke a lot of existing programs.  So any calc that had OS 1.17 on it (especially since it was never released on the Web) was likely to have problems with some assembly programs, even though those problems had nothing to do with the OS.

Some existing BASIC programs will be compatible; no existing assembly programs will be (although some very simple assembly programs will simply need to be re-assembled with a new header file.)  Put it this way: there was more backwards compatibility between the TI-83 and 83+ (or even, arguably, between the TI-82 and 83+) than between the 83+/84+ and 84+C.

It's great that you're interested in writing a new plugin!  What do you want it to do?

It's true that all the documentation is in the code.  The documentation of individual routines is extensive (and where should it go but in the code?)  What I haven't written, and probably should, is a high-level "introductory guide to hacking Mimas" - doing that hasn't been a priority.  I am, of course, always willing to answer any questions you have.

As far as the actual process of writing a plugin - first of all, there aren't any general-purpose hooks that new plugins could attach themselves to.  You could write a new plugin and build it against Mimas 0.4, but it wouldn't do anything.  So to create a new plugin, you'll first need to figure out where in the app those hooks need to be added.  You'll need to decide on the inputs and outputs for the plugin.  Assign it a plugin ID in defs.inc.  Depending on what the plugin does, it's likely that you'll want to call Mimas routines that aren't part of the current API - to do that, add them to plugapi.dat.

So, #define (as used in tasm/spasm) has two fundamentally different purposes:

- "Expression-like" macros:
    #define SUM(x,y) (x + y)
    #define PC ($)

- "Instruction-like" macros:
    #define CP_HL(reg) or a / sbc hl,reg / add hl,reg
    #define CRASH rst 00h

I probably won't implement the former type unless there is huge demand.  But as DrDnar points out, often macros of this sort are really just constants, and an equate would do equally well.  (I suppose it's also worth mentioning that since Mimas is a true multi-pass assembler, you can use equates in ways that wouldn't work in spasm or tasm.)


As far as instruction-like macros, I've thought quite a bit about them since I first started the project.  There are several ways that they could be implemented:

 - Call by value: arguments to a macro must be constant numeric expressions, which are evaluated before calling the macro.  This would be the easiest to implement but also very limited (registers can't be used as arguments; symbols used as args can't be modified; the behavior of PC, @B, and @F would be unlike the way macros are expected to work.)  Many folks would rightly say that this isn't really a macro.

 - Call by reference: arguments could be either constant expressions or literal symbols.  The bookkeeping gets a little bit more complicated than call-by-value; this would allow a macro to define symbols that are passed as arguments.

 - Call by name: arguments could be any expression not involving a register, and would be evaluated at the point in the macro where they're used (so PC would work the way you'd expect, and arguments that aren't used wouldn't be evaluated.)

 - Any of the above plus special support for registers: I could add special syntax that would let you choose a register by number.  For example, CP_HL above could be written as "OR A / SBC HL,R#(reg) / ADD HL,R#(reg)", and to call it you could write "CP_HL(\BC)" (note the backslash), or equivalently write "CP_HL(8)" (8 being the internal code for BC.)  (Obviously the exact syntax is up for debate.)

 - Call by syntactic substitution: arguments could be any valid expression (including registers), and would essentially be pasted into the syntax tree at the appropriate location.  This would require special syntax for parameter names (such as "SBC HL,{reg}") so that Mimas knows not to fully parse the instruction until compile time.  This would be a PITA to implement (especially if macros defined in one source file can be called from a different file, which I think is important to support.)

 - Call by textual substitution: take the text of the argument and paste it into the text of the macro, then parse the result.  This is, I think, less semantically "correct" than syntactic substitution (you lose symbol scoping) and possibly also a bit slower than the other options, but is arguably closest to the way tasm does it.  Like syntactic substitution, this would require special syntax for parameter names within the body of the macro.


Mostly unrelated to the above, I've also considered having macros use numbered parameters rather than named ones; e.g., you'd have to write CP_HL as "or a / sbc hl,#1 / add hl,#1" - sort of like function parameters in a shell script.  This would be considerably easier to implement than named parameters, plus would offer the possibility of variadic macros - the downside would be decreased readability.  In fact, the easiest way to implement this would be for all macros to be variadic, but then you lose error checking.

What do you folks think?  What do you typically use macros for, and how do you intuitively expect them to work?

Indeed, all of that space (up to 822Fh) is used as scratch space by the OS; there's nothing wrong with using it for your own temporary storage.  But as Xeda says, many system routines will use ramCode themselves, and could be overwriting your data.

Seeing that it's only for calculators with 32MB of memory it would be a bit unhandy to have two of TI's large OSes on it. But the possibility by itself is cool

Might it not be possible to store only one version of the OS plus a patch file?  I assume that after removing all the layers of compression & encryption, the bulk of the OS is actually very similar from one version to the next, so the patch file would be much smaller than the complete OS.  Of course this would make it slower to start up, but maybe not by much.