The only good option for using rechargeables in your calculator are rechargable alkaline batteries. The only other option I can think of would be lithium-based batteries, which operate at around 3 V, and so would either require using specially shaped batteries or dummies.

For the record, the TI-84+/SE's maximum current draw without USB is about 30 mA, which happens during flash write/erase operations; the typical current draw is 16 mA max in other circumstances, 5-12 mA typical, and 2 mA on the homescreen with no hooks. For comparison, when a USB device is initially connected, it can draw up to 100 mA, and up to 500 mA if authorized by the computer. The USB port on the TI-84+SE is a USB-On-the-Go port, and supplies a maximum of 100 mA to a connected peripheral.

The TI-83+/SE/84+/SE family of calculators test the batteries by reading the voltage with the CPU in a busy-loop (which raises the current draw). The TI-83+ was originally based on 5.0 V logic, and the CPU specifically tests for voltages around this level. The newer TI-83+s and the SE/84+ series of calculators are based entirely around 3.3 V logic, but the OS still expects at least 5.0 V, even though the hardware (except for the USB port +5 V power rail) technically does not need it.

The calculators use linear voltage regulators, which convert the extra voltage supplied by the batteries into waste heat. Consequently, the calculators are fairly flexible with respect to the voltages they can accept. The maximum voltage you can supply to your calculator is dependent upon the load and design of the regulators TI uses. We experimentally know they will accept up to 9 V; the maximum is probably between 12 to 15 volts. Because the OS specifically looks for around 5.0 V, you should not supply less than 5.0 V. Due to various issues like voltage losses in the USB cable, a USB port might actually supply slightly less than 5.0 V. Alkaline batteries supply 1.5 V for between 250 and 1200 mAh; rechargeable batteries typically supply 1.2 V, with a similar capacity range, though usually lower. Because rechargeables supply a lower voltage, they can easily fail to meet the OS's voltage expectations.

Generally, it is perfectly acceptable to run a calculator from a generic power supply. However, a poor-quality power supply may permit excess AC noise to reach the calculator, causing stability issues. Adding a capacitor may help filter out noise. For a USB port, a capacitor may stabilize the voltage output, as changes in the calculator's load can cause transient voltage drops with a poor-quality USB power supply.

Edit: I created an official power-related Wiki page.

Quote from: thydowulays on February 13, 2012, 10:37:34 pm

This isn't the best thing to use though, because it lets you take "shortcuts", such as doing something like xpos = appBackUpScreen instead of xpos .equ appBackUpScreen. It's your choice though.

I didn't even know Mimas allowed equates But = is a pretty standard substitute for .equ, and it's defined in many versions of ti83plus.inc.

It's in the readme. Besides, how do you expect to define variables?

No, thepenguin's archive cleaner would fix that. Though it might be worth it to check for a garbage app.

Also, the full memory clear I suggested above can be done using the boot code self-test: remove a battery, hold MODE, replace the battery, and turn the calculator on.

For reference, here are the timings for the routines from Z80 Bits.

Rolled:
; Ref Worst Best
MultHbyE:
ld l, 0 ; 7 7 7
ld d, l ; 4 4 4
sla h ; 8 8 8
jr nc,$+3 ; 12/7 12 7
ld l,e ; 4 4
ld b, 7 ; 7 7 7
_: add hl,hl ; 11 11 11
jr nc,$+3 ; 12/7 7 12
add hl,de ; 11 11
djnz -_ ; 13/8 13 13
; -5 -5
; 327 284

MultAbyDE:
ld hl, 0 ; 10 10 10
ld c, l ; 4 4 4
add a,a ; 4 4 4
jr nc,$+4 ; 12/7 7 12
ld h,d ; 4 4
ld l,e ; 4 4
ld b, 7 ; 7 7 7
_: add hl,hl ; 11 11 11
rla ; 4 4 4
jr nc,$+4 ; 12/7 7 12
add hl,de ; 11 11
adc a,c ; 4 4
djnz -_ ; 13/8 13 13
; -5 -5
; 385 312

Unrolled:
MultHbyE:
; L and D must already be 0
sla h ; 8 8 8
jr nc,$+3 ; 12/7 12 7
ld l,e ; 4 4

add hl,hl ; 11 11 11
jr nc,$+3 ; 12/7 7 12
add hl,de ; 11 77
; *7 *7 *7
; 223 180

MultAbyDE:
; HL and C must already be 0
add a,a ; 4 4 4
jr nc,$+4 ; 12/7 7 12
ld h,d ; 4 4
ld l,e ; 4 4

add hl,hl ; 11 11 11
rla ; 4 4 4
jr nc,$+4 ; 12/7 7 12
add hl,de ; 11 11
adc a,c ; 4 4
; *7 *7 *7
; 278 205

AND maskmasks out all bits except the two in question. If the remaining two bits are the same, either there will be 8 zeros and no ones, or 2 ones and 6 zeros. Thus, the parity will be even. However, if the remaining two bits are different, 1 will be zero, and 1 will be one. Thus, the parity will be odd.

My calculator doesn't really show the center of screen fading more wildly than the outside. It could be due to a difference in the driver. However, if it's true that the left is getting only 0s, then it is quite funky that the center columns are somehow lighter. Obviously, there's an unavoidable difference between your update frequency and the driver's. My guess is that the memory isn't properly double-ported or something, so that the driver ends up trying to read data at the same time you're trying to write it, and that's happening for multiple frames.

One thing is for sure, however. Runer112 has created an abomination of assembly, Axe, and hex, and is therefore a mad calculator-scientist.

That's possible on the TI-89T.