Although we know a lot about the TI-8x ASICs, there still remains significant work to be done. Recently, I have discovered something new that needs to be confirmed. You can help confirm this by typing in the following program and posting your results. This test can be performed by TI-83+SE, TI-84+, and TI-84+SE users; the TI-83+ is not relevant. If you have a MathPrint OS, disable MathPrint before trying this and clear the homescreen. The information from this test relates to port 27h and is related to accessing the extra RAM pages. It may be of use to operating system writers, assembly programmers, and Axiom writers.


Code:
:AsmPrgm
:DB156F2600
:EF0745EF2E45
:F31E801686
:0E052100C173
:ED51723EFF
:D327463CD327
:ED79FB260068
:EF0745EF2E45
:C9

(Assembly for the experts:)

Code:

; Yes, I know you can optimize this by at least two bytes.
   in   a, (15h)   ; DB15      
   ld   l, a      ; 6F      
   ld   h, 0      ; 2600      
   b_call(_DispHL)      ; EF0745
   b_call(_NewLine)   ; EF2E45
   di         ; F3
   ld   e, 80h      ; 1E80
   ld   d, 86h      ; 1686
   ld   c, 05      ; 0E05
   ld   hl, 0C100h   ; 2100C1
   ld   (hl), e      ; 73
   out   (c), d      ; ED51
   ld   (hl), d      ; 72
   ld   a, 0FFh      ; 3EFF
   out   (27h), a   ; D327
   ld   b, (hl)      ; 46
   inc   a      ; 3C
   out   (27h), a   ; D327
   out   (c), a      ; ED79
   ei         ; FB
   ld   h, 0      ; 2600
   ld   l, b      ; 68
   b_call(_DispHL)      ; EF0745
   b_call(_NewLine)   ; EF2E45
   ret         ; C9


Run this like a regular assembly program. It should print two numbers. The first will is the ASIC ID and will be either 51 (TI-83+SE), 68 (TA2), 69 (TA3), or 85 (TA1, what all new calcs have); the second will be either 128 or 134.


If you don't mind causing a RAM reset, there's a second test you can perform. This test is related to custom interrupts. The test will cause a crash, hang, freeze, or otherwise errant behavior if it fails; if it passes, the busy indicator will keep scrolling until you press CLEAR (give it half a minute or so). If the above code printed 69 for the first number, this should pass if I'm right. If I'm right, all other values will cause a crash. Do not use any shells. Doing so is likely to cause a false negative. The test is simply this:

Code:
:AsmPrgm
:FBED46FD3421
:10FBEF1840
:FE0F20F1
:ED5676C9
Assembly = _: ei \ im 0 \ inc (iy+asm_flag1) \ djnz $-3 \ b_call(_GetCSC) \ cp skClear \ jr nz -_ \ im 1 \ halt \ ret

If this test passes with the first number from the above test being anything other than 69, let us know; it could provide a great optimization for Axe.
For the first run, I got 85 and 128; for the second test, it did not crash. What does this mean?
That's quite interesting. First, the Wiki is wrong about port 27. Port 27 is not capped to 13h, at least not on the new TI-84+s/SEs. Ports 27 and 28 can be used to perform partial page swaps, which is potentially useful, since they let you keep core variables and the stack in RAM, while swapping RAM/RAM in 8000-FFFF.

At least as interesting is the second test. The lack of crashing suggests that the TA1 actually also sends FF when interrupts occur, eliminating the need for a giant IVT. However, runer told me long ago that a similar test failed on the TA2, so it's not universal to all TI-83+SE/TI-84+/SEs, only the newer ones.
I screwed up the code for the second test. For some reason, I need to flush pending interrupts before quitting. So run the second test again, please.
the first run gave the numbers 68 and 128 on my 84SE. if you switch to classic on an MPOS, then your good. you dont have to clear the screen.

the second test did crash the calc, causing the screen to instantly turn off.
Here's a new test, one that WON'T CLEAR RAM.

Code:
:AsmPrgm
:F33E20D310
:AFD330D333D336
:210080118181
:0600732310FC
:368221ED9D0E03
:EDB0
:11818221F09D
:0E07EDB0
:3E80ED47ED5EFB
:ED5EFB
:1C7BD311
:DB04E60820F3
: ED56 FB76C9
:41414152474821
:00
:E1ED56FB76
:21D99DEF0A45
:C9
:C3E19D
:08AFD30208FBC9
Assembly!
   .org   blah
   .db   blah, blah blah
Start:
   di         ; F3
   ld   a, 20h      ; 3E20
   out   (10h), a   ; D310
   xor   a      ; AF
   out   (30h), a   ; D330
   out   (33h), a   ; D333
   out   (36h), a   ; D336
   ld   hl, 8000h   ; 210080
   ld   de, 8181h   ; 118181
   ld   b, 0      ; 0600
_:   ld   (hl), e      ; 73
   inc   hl      ; 23
   djnz   -_      ; 10FC
   ld   (hl), 82h   ; 3682
   ld   hl, ISR      ; 21ED9D
   ld   c, ISR2-ISR   ; 0E03
   ldir         ; EDB0
   ld   de, 8281h   ; 118182
   ld   hl, ISR2   ; 21F09D
   ld   c, ISR_end-ISR2   ; 0E07
   ldir         ; EDB0
   ld   a, 80h      ; 3E80
   ld   i, a      ; ED47
   im   2      ; ED5E
   ei         ; FB
loop:   
   im   2      ; ED5E
   ei         ; FB
   inc   e      ; 1C
   ld   a, e      ; 7B
   out   (11h), a   ; D311
   inc   a, (4)      ; DB04
   and   8      ; E608
   jr   nz, loop   ; 20F3
quit:   
   im   1      ; ED56
   ei         ; FB
   halt         ; 76
   ret         ; C9
strARGH:
   .db   "AAARGH!", 0   ; 4141415247482100
ARGH:
   pop   hl      ; E1
   im   1      ; ED56
   ei         ; FB
   halt         ; 76
   ld   hl, strARGH   ; 21D99D
   b_call(_PutS)      ; EF0A45
   ret         ; C9
ISR:
   jp   ARGH      ; C3E19D
ISR2:
   ex   af, af'      ; 08
   ; During the six hours it took me to come up with this, I discovered the right way to acknowledge interrupts:
   xor   a      ; AF
   out   (2), a      ; D302
   ex   af, af'      ; 08
   ei         ; FB
   ret         ; C9
isr_end:

This will show garbage on the left side of your screen until you press ON, unless it first says AAARGH!, in which it's considered to have failed. Once again, this has been specifically coded not to clear your RAM. It very carefully differentiates between FF and not FF.
I ran the CPU Test on the new calc, would that code work on an 84+CSE if you changed the start token to Asm84CPrgm?

The output from the CPU Test was:
Quote:
13705 33130 33149 33146
TheStorm wrote:
I ran the CPU Test on the new calc, would that code work on an 84+CSE if you changed the start token to Asm84CPrgm?

The output from the CPU Test was:
Quote:
13705 33130 33149 33146
Yup, another calculator topping out at 15MHz. :/ I'm wondering more and more if there's a pin on the ASIC or pad on the PCB that might be involved in enabling a faster mode.
Ok I ran the first on my 84+SE and got the same as LuxenD 68 and 128, and the second program crashed my calc hard.

The program in the later post gave me AAARGH! so I'll assume that means it failed.
  
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
Page 1 of 1
» 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