Does anyone with a TI-84+CE and a TI-84+CSE have a ruler and/or a scale handy? A comparison of the dimensions and weight with (and without) the slidecase would be greatly appreciated.

Weights in grams.
With slide case:
82 - 246
84+SE - 294
84+CSE - 261
84+CE - 201

Without slide case:
82 - 208
84+SE - 252
84+CSE - 221
84+CE - 163

Okay, I've updated the WikiTI page with information about the keypad controller; but I appear to be having some issues with timings or somethings similar. Keep in mind if you run the following; you will need to use the reset button:


Code:


When it runs, it correctly registers the Arrow Keys, however, if I hold a key not in the arrow group, it causes it to register occasionally in the wrong group. Any ideas?

I believe this might be happening because _PutC can reenable interrupts (specifically when the screen scrolls). I don't get the problem happening until that point with my own program that prints only when the value changes.

Edit: I actually have a good explanation for this. TI leaves the keypad in different modes depending on the current state of the keypad. Here's basically what they do:

Code:


The problem this causes is that the keypad is left in mode 1 if no keys are pressed. That means the data registers are in an undefined state (I personally think that all rows are enabled and thus they read the OR of all keys in the column). So, if no keys are pressed, you end up with phantom keypresses if you read a data register after a key is pressed and before the next actual scan occurs.

Just to interject for a second, should we start coming up with some universally-recognized names for these memory-mapped port equates? I feel like that would simplify some of these discussions, and I'm a staunch hater of magic numbers in code.

Ok so I managed to get some parser stuff running and made a small tilemap demo:



The entire map is redrawn each frame and the scrolling is 8-pixels at a time. The code an be optimised for more speed as well.

Very encouraging when compared to the CSE!

What resolution and color mode is this running at?

Looks to me like it is running in 8bpp mode.

Anywho, looks like rst 20h is no longer _Mov9toOP1, so just use the call instead for now.

This may be pretty important, but it seems like register B no longer holds the archive status of a variable in the same way when using _ChkFindSym. Going to try and figure it out...

EDIT: In addition, the accumulator no longer holds information about the variable.

I just want to update that I've documented some more hardware.

The 6000 port range, which we thought was a general-purpose timer, is actually a watchdog timer. Not as useful as we were hoping, though it is good for resetting the calculator and/or triggering NMIs! (Or it can be used as a timer without triggering interrupts, I suppose.)

Thankfully, the 7000 range actually contains not one, but three general-purpose timers! These can be used to generate interrupts, and are a good bit more flexible than the timers we had previously.

Sure; what do you think of this list for keyboard equates:

Code:


Also, great find calc84! This is even more fantastic news; now interrupts can be even cooler!

How do you figure all of this stuff out? I'd have no idea how to go about documenting the timers, for example.

Also, what is the purpose of the watchdog timer? I looked it up on Wikipedia and it appears they're used to keep a computer from permanently freezing by rebooting it if the timer doesn't get reset before reaching zero, but i can't really imagine what the use of something like that would be here, especially with a reset button available.

tr1p1ea: the tilemapping demo definitely looks promising.

The use would be the same here -- imagine the interrupt resetting that timer, but if you run an assembly program that disables interrupts and locks up, the watchdog timer can reset for you. That would be useful in situations where you can't press the RESET button (don't have anything that can press it, controlling it remotely, etc.).

Those keyboard equates don't follow convention. In code, the key names are not all capitalized, e.g. skMode and kMode.

The watchdog timer could be used to prevent us from running programs with interrupts disabled, by forcing an NMI at regular intervals. If the port range were protected, it would be extremely annoying.

calc84 IDed the watchdog timer, I think by just concluding that it was probably a watchdog timer, and then Googling for watchdog timer IP cores. He then noticed a resemblance to a general purpose timer from the same company, and an RTC. Then I checked if they had USB IP cores, and USB 2.0 OTG one matched. calc84 also found an interrupt controller.

Incidentally, the B0xx range (LCD backlight) looks similar to a port range on the Nspire. On the Nspire, there's also a 1-wire interface in that port range (used with the battery controller?). It looks like it might be there, but slightly different, and the OS never uses it.

We also may have found the testing LED, which also looks similar to the Nspire's. It seems to be write-protected, and yet memory mapped, so I'm totally confused about why IN and OUT are forbidden, and why the 00xx range doesn't appear to be memory mapped, if they still have a regular protected port system that could have protected the security registers without all this port access craziness.

Incidentally, the OS doesn't use memory-mapped I/O. It's weird, because it would get a slight speed boost from using it by not requiring all those double-checks on writes. (And the unmapped 00xx range can just use out0.) And of course, not needing those checks would make the code easier to write.

Actually, the way I found the watchdog timer was by Googling its default counter value (0x03EF1480) and a comment in a U-Boot driver showed up. It was quite a happy coincidence.

It certainly implies that the memory-mapped I/O is not intentional. Even if it was, they've screwed up the security on this thing pretty badly.

I've written up the results of some tests involving wait states. This is very useful to know for emulation or generally for optimization.

One very interesting thing is that the LCD controller has fewer wait states on read than RAM does, so its 1KB of cursor graphics memory could be quite useful for running critical code...

I believe the memory-mapped I/O is intentional.

Did you fix it and update Mateo's work?

That sounds really exciting for a shell-type program. The author of Doors CSE is keeping his ears open.

Do you have the name of the company, and the models of each of those IP components, so I can update our TI-84 Plus CE Information page? I probably should just look on WikiTI.

It's pretty hard to imagine an engineer doing that by accident. I think it's just the result of multiple parties writing requirements.

How do you plan on trapping the NMI. OS mod? I didn't think you endorsed that sort of thing.

Yes, you should.

Fixed and updated. Case isn't parsed with equates; but there were a couple that were named incorrectly. Oh wells.

Thank you so much for finding these! Would one of you mind updating our Tools pages with that information? I'll do it if no one else gets to it.