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:
.nolist
#include ti84pce.inc
.list

 .org userMem-2
 .db tExtTok,tAsm84CeCmp
 di
 call _HomeUp
 call RestoreKeyboard

Scan:
 ld a,3
 ld (0F50000h),a   ; Resets Controller?

 ld a,(0F5001Eh)   ; Arrow Keys
 ld c,a
 call OutHex
 jr Scan
 
 call RestoreKeyboard
 ret
 
RestoreKeyboard:
 ld bc,0F50000h
 xor a      ; Mode 0
 ld (bc),a   ; %00000000
 inc c      ; 0F50001h
 ld a,15   ; Wait 15 APB cycles before scanning each row
 ld (bc),a
 inc c      ; 0F50002h
 xor a      ; %00000000
 ld (bc),a
 inc c      ; 0F50003h
 ld a,15   ; Wait 15 APB cycles before each scan
 ld (bc),a
 inc c      ; 0F50004h
 ld a,8      ; Number of rows to scan
 ld (bc),a
 inc c      ; 0F50005h
 ld (bc),a   ; Number of columns to scan
 ret
 
OutHex:
 ld a,c
 rra
 rra
 rra
 rra
 call Convert
 ld  a,c
Convert:
 and  $0F
 add  a,$90
 daa
 adc  a,$40
 daa
 call _PutC
 ret


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?
MateoConLechuga wrote:
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:
.nolist
#include ti84pce.inc
.list

 .org userMem-2
 .db tExtTok,tAsm84CeCmp
 di
 call _HomeUp
 call RestoreKeyboard

Scan:
 ld a,3
 ld (0F50000h),a   ; Resets Controller?

 ld a,(0F5001Eh)   ; Arrow Keys
 ld c,a
 call OutHex
 jr Scan
 
 call RestoreKeyboard
 ret
 
RestoreKeyboard:
 ld bc,0F50000h
 xor a      ; Mode 0
 ld (bc),a   ; %00000000
 inc c      ; 0F50001h
 ld a,15   ; Wait 15 APB cycles before scanning each row
 ld (bc),a
 inc c      ; 0F50002h
 xor a      ; %00000000
 ld (bc),a
 inc c      ; 0F50003h
 ld a,15   ; Wait 15 APB cycles before each scan
 ld (bc),a
 inc c      ; 0F50004h
 ld a,8      ; Number of rows to scan
 ld (bc),a
 inc c      ; 0F50005h
 ld (bc),a   ; Number of columns to scan
 ret
 
OutHex:
 ld a,c
 rra
 rra
 rra
 rra
 call Convert
 ld  a,c
Convert:
 and  $0F
 add  a,$90
 daa
 adc  a,$40
 daa
 call _PutC
 ret


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:
Set mode 1
Check if any keys are pressed using interrupt bit 2
If no keys are pressed, return
Set mode 3
Wait until the scan finishes using interrupt bit 0
Set mode 0
Check keypad data, return


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. Smile
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?
merthsoft wrote:
What resolution and color mode is this running at?

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

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... Cool

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

Courtesey of Calc84 wrote:
The new call is "_ChkInRAM equ 021F98h", which returns Z if RAM, NZ if in ARCHIVE.
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.
KermMartian wrote:
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. Smile


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

Code:
kbdMODE      equ   00h
kbdCNTRL   equ   04h
kbdINT      equ   08h
kbdINTMASK   equ   0Ch

kbdG1      equ   0F50012h
;-------------------------------
kbdGRAPH   equ   00000001b
kbdTRACE   equ   00000010b
kbdZOOM      equ   00000100b
kbdWINDOW   equ   00001000b
kbdYEQU      equ   00010000b
kbd2ND      equ   00100000b
kbdMODE      equ   01000000b
kbdDEL      equ   10000000b

kbitGRAPH   equ   00h
kbitTRACE   equ   01h
kbitZOOM   equ   02h
kbitWINDOW   equ   03h
kbitYEQU   equ   04h
kbit2ND      equ   05h
kbitMODE   equ   06h
kbitDEL      equ   07h

kbdG2      equ   0F50014h
;-------------------------------
kbdSTO      equ   00000010b
kbdLN      equ   00000100b
kbdLOG      equ   00001000b
kbdXSQURE   equ   00010000b
kbdXINV      equ   00100000b
kbdMATH      equ   01000000b
kbdALPHA   equ   10000000b

kbitSTO      equ   01h
kbitLN      equ   02h
kbitLOG      equ   03h
kbitXSQURE   equ   04h
kbitXINV   equ   05h
kbitMATH   equ   06h
kbitALPHA   equ   07h

kbdG3      equ   0F50016h
;-------------------------------
kbd0      equ   00000001b
kbd1      equ   00000010b
kbd4      equ   00000100b
kbd7      equ   00001000b
kbdCOMMA   equ   00010000b
kbdSIN      equ   00100000b
kbdAPPS      equ   01000000b
kbdXTON      equ   10000000b

kbit0      equ   00h
kbit1      equ   01h
kbit4      equ   02h
kbit7      equ   03h
kbitCOMMA   equ   04h
kbitSIN      equ   05h
kbitAPPS   equ   06h
kbitXTON   equ   07h

kbdG4      equ   0F50018h
;-------------------------------
kbdDECIMAL   equ   00000001b
kbd2      equ   00000010b
kbd5      equ   00000100b
kbd8      equ   00001000b
kbdOPENPAR   equ   00010000b
kbdCOS      equ   00100000b
kbdPGRM      equ   01000000b
kbdSTAT      equ   10000000b

kbitDECIMAL   equ   00h
kbit2      equ   01h
kbit5      equ   02h
kbit8      equ   03h
kbitOPENPAR   equ   04h
kbitCOS      equ   05h
kbitPGRM   equ   06h
kbitSTAT   equ   07h

kbdG5      equ   0F5001Ah
;-------------------------------
kbdNEG      equ   00000001b
kbd3      equ   00000010b
kbd6      equ   00000100b
kbd9      equ   00001000b
kbdCLOSEPAR   equ   00010000b
kbdTAN      equ   00100000b
kbdVARS      equ   01000000b

kbitNEG      equ   00h
kbit3      equ   01h
kbit6      equ   02h
kbit9      equ   03h
kbitCLOSEPAR   equ   04h
kbitTAN      equ   05h
kbitVARS   equ   06h

kbdG6      equ   0F5001Ch
;-------------------------------
kbdENTER   equ   00000001b
kbdPLUS      equ   00000010b
kbdSUB      equ   00000100b
kbdMULT      equ   00001000b
kbdDIV      equ   00010000b
kbdPOW      equ   00100000b
kbdCLEAR   equ   01000000b

kbitENTER   equ   00h
kbitPLUS   equ   01h
kbitSUB      equ   02h
kbitMULT   equ   03h
kbitDIV      equ   04h
kbitPOW      equ   05h
kbitCLEAR   equ   06h

kbdG7      equ   0F5001Eh
;-------------------------------
kbdDOWN      equ   00000001b
kbdLEFT      equ   00000010b
kbdRIGHT   equ   00000100b
kbdUP      equ   00001000b

kbitDOWN   equ   00h
kbitLEFT   equ   01h
kbitRIGHT   equ   02h
kbitUP      equ   03h


Also, great find calc84! This is even more fantastic news; now interrupts can be even cooler! Smile
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.
DrDnar wrote:
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.


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...
BrandonW wrote:
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 believe the memory-mapped I/O is intentional.

DrDnar wrote:
Those keyboard equates don't follow convention. In code, the key names are not all capitalized, e.g. skMode and kMode.
Did you fix it and update Mateo's work? Smile

Quote:
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.
That sounds really exciting for a shell-type program. The author of Doors CSE is keeping his ears open. Wink

DrDnar wrote:
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.
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. Wink
BrandonW wrote:
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.
It's pretty hard to imagine an engineer doing that by accident. I think it's just the result of multiple parties writing requirements.

KermMartian wrote:

That sounds really exciting for a shell-type program. The author of Doors CSE is keeping his ears open. ;)
How do you plan on trapping the NMI. OS mod? I didn't think you endorsed that sort of thing.

KermMartian wrote:
I probably should just look on WikiTI. ;)
Yes, you should.
KermMartian wrote:
DrDnar wrote:
Those keyboard equates don't follow convention. In code, the key names are not all capitalized, e.g. skMode and kMode.
Did you fix it and update Mateo's work? Smile

Fixed and updated. Razz Case isn't parsed with equates; but there were a couple that were named incorrectly. Oh wells.
merthsoft wrote:
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
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 2 of 7
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement