Oh I didn't know the clock used Crystal timers. I was sure it was an extra thing added to the calc.

I'm not sure what you mean by that. It uses the same frequency reference, a single generic 32768 Hz crystal, but is an entirely separate circuit from the three timers. It would have been silly for TI to build a calculator with four identical crystals. Well, at least my calculator only has one physical crystal in it. (If you open up your calculator or watch, the crystal can be found in a metal cylinder less than 0.5 cm in diameter and less than 2 cm long, with two wires coming out of it.) Almost all quartz-crystal-based clocks, both "analog" and digital, use a 32768 Hz crystal as their time reference. The power of 2 makes it easy to make a counter that increments or pulses once a second.

I guess Apple's prohibition against "3rd party runtimes" doesn't apply if you're a big company with lots of money. I would have thought that if Apple forbids C64 emulators, there would be no chance of a Lua interpreter.

If you want to define a constant, the syntax is as follows:
symbol = valueThere is no macro support.

-Add a turn calc off function to zStaxe. It would quit the program then turn the calc off "completely" and "truly". I mean not an APD and not a low-battery trick, but a power down that would trigger the 8scale picture and the startup program at startup.

The only to truly turn off a calculator is to remove all four AAAs and the backup battery. The calculator requires about 70 microamps to maintain RAM contents and to be able to sense when the ON key is pressed. The OS itself uses the same "low-battery trick" you speak of. Some really old programs may not do it correctly, but I doubt that's a problem anymore. (The correct code should be located on WikiTI.)

More technical information: During a normal power-down, writing to a port configures the ASIC to enter a special low-power mode when it sees the CPU core enter the HALT state. Hardware-wise, there is no difference between the OS doing it and a RAM program or application doing it. In both cases, pressing ON issues an interrupt that terminates the HALT state, and the ASIC exits low-power mode. The CPU then continues executing instructions from where ever it left off.

So why does removing a battery when in a RAM program cause a RAM reset, but no reset happens when the OS does it? It's a bit of a long story: Disconnecting the main AAAs will cause the ASIC and the CPU to hard-reset---except for RAM, which continues to be powered from the backup battery. When power is restored, the CPU is immediately hard-reset, and the boot code boots. It sees that the OS is valid, and transfers control to the OS after initializing some hardware. Now, when the OS turns off normally or APDs, it calculates a checksum for RAM. So, after you reinsert the AAAs, the OS sees that the RAM checksum is still valid, and that RAM should not be reset.

Cool fact: The calculator boots immediately after restoring main power. The OS (or boot code, if no OS is present) checks the state of the ON key after booting; if it isn't being pressed, it immediately does a normal power-off, as mentioned above.

Also, if you remove a battery at the homescreen with the blinking cursor, the calculator actually stays on for a split second, during which time an interrupt (HW timer 2) fires. The OS, seeing the power outage, changes the RAM checksum to a special value to signal that a RAM reset should be not performed after power is restored. This behavior is activated by a particular flag, which assembly programs should not normally use due to a memory-leak issue. (Specifically, CPU control is not returned to the running program; it's just like doing JForceCmdNoChar.) Although, I suppose a custom OS could take a few microseconds to save the CPU state. Actually, that should be a zStart feature: improved RAM-reset prevention for compatible programs. (It won't work if the interrupt handler is not called, which can be either because interrupts are disabled or the current program is using a custom interrupt.)

Could someone make a plugin for Mimas that's basically the Asm in 28 Days tutorial, so I could read asmin28days on-calc and on the go/at school with no computer?

Moody's Flash Book app is, perhaps, the best e-book reader for the TI-83+ series.

BTW is Mimas bootstrapped? Just wondering...

No, Mimas is written for ZDS. I don't think Mimas could build a 2-page app at once due to memory limitations. It also doesn't support directly writing to flash. It's certainly possible to build and sign apps on-calc, but he seems unlikely to implement such functionality since he seems to think screwing with flash is too dangerous.

I would expect more from what I have to assume they made as a prizm competitor. They have the native asm support, but I'd hope for specs that were close to matching the prizm. It has about 1/5th the RAM of the prizm. I still think this is an interesting calc for how it should be a very easy/popular transition for schools.

Based on the spec saying that the calculator has 21 K of user RAM, it seems reasonable to conclude that the OS is largely based on previous OSes, especially the parts of it not related to the user interface. Ergo, the OS and boot code required for OS and app transfers is already valid. It just doesn't make sense to write an entirely new protocol. It's possible that TI will modify the computer-side 8xk format to prevent people from trying to send a TI-84+CSE app to a regular-series calculator, but I highly doubt any major changes in the protocol.

Well, I feel snubbed. I.Q. Joe gets to beta test the calculator---or at least the new SDK---but nobody from the community does.

Price: $130 USD from SchoolMart. I specifically mention them because they're within driving distance for me.

How advanced is the class? What sort of data structures are you supposed to be working with? There are plenty of good guides to basic Java syntax, and Google is your friend for finding out about the Java API.

A dictionary is an abstract data structure in which each unique key maps to one output. For the first problem, you would want a dictionary in which the key is a String (do .toLowerCase() before adding) and the output is an Integer. For each word in the list, check if it is in the dictionary and set the associated Integer object to 1 if not; otherwise, increment the Integer by 1. When you're done, collect the word-number pairs into an array (e.g. by making a new WordPair class which implements Comparable<WordPair> and filling it by iterating over the HashMap<String, Integer> or whatever) and sort it (java.util.Arrays.Sort()). Remember that Comparable<T> is a useful interface.

For the second problem, use a regex. Remember that underscores are a special case; specifically, the regex needs to include the clause that after each underscore, there needs to be one of the allowed characters or nothing at all (that is, an underscore can be at the end of an identifier). Or just iterate over the characters using a for(...){...} loop, checking if the char is valid using a switch{...}.