I get 0, 0, 0, 0 on my 84+Thanks dude !
I want to test this but I can't do it without having the raw assembly to input onto my calc.Thanks.
Maybe this helps:
jsTIfied with TI-84+ Silver Edition OS 2.55MP gives me 65535, 65535, 65535, 65535
If you could would you send me code. I can convert it into Mimas code and do it on my real calc.
2.43 with some small tweaks to the certificate. Hardware revision F. I would also test with the 83+SE I have, but it's borked to the point of uselessness.I get 0, 0, 0, 0 on my 84+Thanks dude !
It appears i was actually right to be paranoid.
Those numbers are pretty unexpected, if you got them from actual hardware.
Basically, that means the delays i measured on my two 84+SEs aren't enough for the 84+, which definitely shouldn't be the case.
Which OS was it ?
2.43 with some small tweaks to the certificate. Hardware revision F. I would also test with the 83+SE I have, but it's borked to the point of uselessness.My tests were made under 2.43 aswell, so i guess that isolates the OS as a variable to explain the difference.
I got the same result on all 3 that I could find:Cool.
TI-84+ rev V OS 2.55MP
TI-84+ rev S 2.55MP
Prototype TI-83+SE VSC 1.18
21845,21845,21845,21845
EDIT : Is there a chance ALCDFIX was installed when you ran my program ?
I believe so.Your port $2A doesn't probably hold its default value then, which could explain everything.
It's reporting 39Damn, wrong lead then, since it's the default value.
Happy to run whatever you need to test :)It's reporting 39Damn, wrong lead then, since it's the default value.
Anyway, that's a good thing i had that idea, cause it reminded me i'll have to take port $2A into account in my tool.
I'll probably have 2 more programs for you to test, if that's ok.
Thanks again.
Thanks.
Should i understand that you have no way to send data from computer to calc ?
If yes, forget inputting the data by hand, the program is way too big for that.
Anyway, i added the source code on my original post, just in case.
And no, i'm afraid results coming from emulators are definitely irrelevant, cause port $2F isn't accurately emulated =[
You might want to look into https://ticalc.link/ (https://github.com/Timendus/ticalc-usb/)Thanks.
Should i understand that you have no way to send data from computer to calc ?
If yes, forget inputting the data by hand, the program is way too big for that.
Anyway, i added the source code on my original post, just in case.
And no, i'm afraid results coming from emulators are definitely irrelevant, cause port $2F isn't accurately emulated =[
Yah I have no way at the moment. I have a Chromebook for school use only.
My 84+ SE gave 21845, 21845, 21845, 21845What hardware revision?
My 84+ SE gave 21845, 21845, 21845, 21845Thanks !
Happy to run whatever you need to test :)Cool.
65535, 65535, 65535, 65535Happy to run whatever you need to test :)Cool.
This first program checks delays up to +16 cycles from what i originally posted, and only between IN A,($10) and IN A,($02) for now.
I hope that will be enough.
If everything goes well, you should get numbers in the form (2^n)-1.
65535, 65535, 65535, 65535Thanks.
65535, 30583, 65535, 6553565535, 65535, 65535, 65535Thanks.
Those numbers mean that your port $02 uses exactly 1 more clock cycle for its delays, which sounds weird, but isn't impossible.
EEEMS3.8xp should confirm it anyway (basically my original program but with +1 cycle on all 64 checks).
65535, 30583, 65535, 65535Those numbers suck, because they contradict the ones you got earlier =[
I reran P2FTEST1 and I'm now getting 21845, 21845, 21845, 21845. I did have a ram clear happen that I forgot about. After launching DCS7 and then running it again I'm getting 0, 0, 0, 0 in both P2FTEST1 and EEEMS3.65535, 30583, 65535, 65535Those numbers suck, because they contradict the ones you got earlier =[
I mean, they are the numbers you're supposed to get if you got four 21845 on P2FTEST, but definitely not if you got four 0 from it.
Could you please (re-)run P2FTEST1 just in case ?
It now includes a check that kicks you if port $2A is unusual, which actually could have been the case if ALCDFIX was installed when you tested P2FTEST, and if you performed a RAM clear before testing EEEMS1.
I reran P2FTEST1 and I'm now getting 21845, 21845, 21845, 21845.Great news.
After launching DCS7 and then running it again I'm getting 0, 0, 0, 0 in both P2FTEST1 and EEEMS3.DCS might include some code similar to what ALCDFIX does.
EEEMS2 now returns 32767, 255, 7, 0
.nolist
.org $9D93
#include "ti83plus.inc"
.list
;#################################### DATA #####################################
.db t2bytetok,tasmcmp
;#####
di
in a,($02)
rla
ret nc ; TI-83+
in a,($21)
and %00000010
ret nz ; TI-84+CSE
in a,($2A)
or %00000011
cp $27
ret nz ; port $2A unusual
in a,($2E)
or %00000001
cp $45
ret nz ; port $2E unusual
ld a,(currow)
ld (textshadcur),a
res apptextsave,(iy+appflags)
call keybclear
bcall(_clrlcdfull)
di
ld hl,$0000
ld (currow),hl
;Everything before this isn't exactly relevant.
in a,($2F)
ld c,a
and %11111100
out ($2F),a
ld a,$01
ld b,0
djnz $
out ($20),a
;16+ CC required here to avoid _putmap to enter endless loop
in a,($02)
rra
and %00000001
add a,'0'
ld b,a
ld a,c
out ($2F),a
ld a,b
bcall(_putmap)
;Everything after this isn't exactly relevant.
di
xor a
ld b,%00001000
out ($01),a
wait_key_pressed
in a,($01)
inc a
jr nz,key_pressed
in a,($04)
and b
jp nz,wait_key_pressed
key_pressed
xor a
ld (kbdscancode),a
res oninterrupt,(iy+onflags)
set apptextsave,(iy+appflags)
call keybclear_wait_keys_released
bit 5,(iy+$44)
jr nz,restore_mathprint
ld a,(flags+sgrflags)
rra
jp nc,restore_textshadow
bcall(_grbufcpy)
di
restore_textshadow
bcall(_rstrshadow)
di
ret
restore_mathprint
ld a,$03
ld b,64
ld hl,$DA7E
out ($05),a
bcall(_restoredisp)
di
xor a
out ($05),a
ret
;keybclear
;DESCRIPTION
;Waits until the keyboard is clear from any press.
;Includes a debouncing delay.
;IN
;interrupts : disabled
;OUT
;keyboard : all groups monitored
;a = ?
;f = %???????0
;bc = $0000
;stack : 2 bytes (call included)
keybclear
xor a
ld b,%00001000
out ($01),a
keybclear_wait_keys_released
in a,($01)
inc a
jp nz,keybclear_wait_keys_released
keybclear_wait_on_released
in a,($04)
and b
jp z,keybclear_wait_on_released
in a,($02)
ld bc,96
rla
jr nc,keybclear_wait_bouncing
in a,($20)
or a
jr z,keybclear_wait_bouncing
ld c,240
keybclear_wait_bouncing
djnz keybclear_wait_bouncing
dec c
jp nz,keybclear_wait_bouncing
ret
;###############################################################################
.endThis code causes _putmap to enter an endless loop, but as soon as you add at least 16 CC (don't ask me why) between OUT ($20),A & IN A,($02), it works fine.