Omnimaga
Calculator Community => Other Calculators => Topic started by: DrDnar on March 12, 2013, 07:57:19 pm
-
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 (http://wikiti.brandonw.net/index.php?title=83Plus:Ports:27) and is realted to accessing the extra RAM pages. It may be of use to operating system writers, assembly programmers, and Axiom writers.
:AsmPrgm
:DB156F2600
:EF0745EF2E45
:F31E801686
:0E052100C173
:ED51723EFF
:D327463CD327
:ED79FB260068
:EF0745EF2E45
:C9
(For assembly experts:)
; 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:
: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 \ retIf 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.
-
I have a TI-84+SE, purchased a little less than a year ago. I suppose that makes it a "new calc". More specs in case it's helpful: Originally boot code 1.03 and OS 2.55; downgraded to 1.02 and OS 2.41. zStart is installed.
The first program returned:
85
128
So I guess that means it has a TA1?
The second program sent me to a new line, nothing else. I noticed no changes after running it... So it passed and the first number wasn't a 69.
Hope this info helped!
EDIT:
I tested the new code. It froze up and Defragmented after battery removal and reset nearly everything in the archive :/
-
For my 84+ (it has 8 RAM pages), it returned 69,128. The second program crashes the calculator.
For my 84+SE (3 RAM pages), it returned 85, 128. The second program caused the calculator to freeze on the homescreen after displaying Done.
EDIT: With the new code, both calcualtor's pass.
-
That's really neat. It'd be nice to get some TA2 results. I'm using IM 0 as an easier-to-code proxy for IM 2 behavior. I'll work up a more thorough test tomorrow to verify that IM 2 on the TA1 really doesn't require the full 257-byte IVT we've always used with the TA2 and the TI-83+.
Quick edit: Actually, come to think of it, I think I already wrote that test. I'll have to dig through my flash drive later to find it.
-
My 84+SE:
85
128
The 2nd test crashed the calc, but i had to disable zStart first ;)
-
68, 128, freeze
-
I'll post results from my ti-84 + se and my ti 83+ se later today. I'll have two more calculators to post results for by the end of this week/early next week.
-
With my old TI 84+ SE : 69 and 128, and with the second test my calc just freeze (if I launch it with Noshell or not).
-
84+:
85
128
Fail(hang)
84+ SE:
85
128
Fail(hang)
83+SE:
51
128
Fail (hang)
Ti-84+ SE:
68
128
Fail (hang)
-
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.
-
I edited my first post. Both calculators passed.
-
Now the second test gives me an instant "RAM cleared".
-
EDIT: I had posted another here but it's broken and I don't know why. :/
Now the second test gives me an instant "RAM cleared".
Are you sure it says 69? Double check that you typed in everything correctly.
-
Edited my post with the new results. I'll have one more to add tomorrow.
-
The new-new test works for both of my calculators :)
-
I can't be more sure, I've copy-pasted it in TI-Graph Link and just to be sure I've also type it by hand.
And it sure says 69 (it's an old TI 84+ SE, I got it in 2006 if I remenber correctly, and I'm using OS 2.55MP).
But now with this new test it seems ok (no RAM cleared or AAARGH!, it just quits when I press Clear).
-
My 84+SE (84/128) works fine with the second test, now. What is the purpose of using im 0? Does it have any practical use? Also, is it properly emulated by emulators?
Interrupt Mode 0
When an interrupt is requested, the Z80 reads a byte from the data bus and executes it. This can be a single-byte instruction or the start of a multi-byte instruction; for speed reasons commonly RST $nn is used to start processing an interrupt handler due to it's compact encoding.
If no external device is driving the bus, the Z80 will read a garbage value. In systems with pull-up or pull-down resistors on the bus, the value read will be $FF (RST $38) or $00 (NOP) respectively.
-
As far as I know, no emulators emulate this quirk. IM 0 is useless, because the TA3 appears to have pull-up resistors and consequently functions exactly like IM 1. Anyway, here's a new test, one that isn't broken and WON'T CLEAR RAM.
EDIT: There was a typo on the line below that I put spaces into. It read ED5E when it should have read ED56. The assembly listing below had the right hex codes; I made a mistake while copying. This could error cause it to crash or print AAARGH on exit.
: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
in 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! Once again, this has been specifically coded not to clear your RAM. It very carefully differentiates between FF and not FF.
-
For me (84+SE: 84/128) it fills up the left side of the screen and then prints AAARGH! I've attached a .8xp file for anyone who doesn't feel like typing all that into the calc and probably typing it in incorrectly ;)
EDIT: And i assumed the "inc a,(4)" was supposed to be "in a,(4)"
-
Well, this new test says "AAARGH!" now... Strange :/
-
AAARGH! It doesn't do that to me. Mine's a TA3 (port 15=69d/45h).
Also, you're right chickendude about the typo. The hex code by that instruction, however, is correct. Unfortunately, there was a different error in the hex codes; see above for the correction.
-
It still prints "AAARGH!".
-
on the first one, I got 85 and 128. on the second one, I did not get AARGH or anything. it just exited quietly.
-
When I get home, I'll send them to my calculator and give you information! I'm excited :) I don't like copying all the code. :P
-
TI-84 Plus (non SE), rev G, TA3 chip (confirmed by actual inscription on hardware).
First test : 69/128
Second (chickendude's 8xp) : Garbage on the left then argh.
Second (pasted the code in your last post in SourceCoder) : same.
When I fix my 83+ SE I'll tell you what it gives. ;)
-
I'm retracting my claims about IM 2. I ported the program to my new TI-84+CSE (which has the same ASIC) and it AAARGHs!s.
-
Sorry for the semi-necropost. What exactly is this for?