### Author Topic: investigating port $2F (Read 9580 times) 0 Members and 1 Guest are viewing this topic. #### Eeems • Mr. Dictator • Administrator • LV13 Extreme Addict (Next: 9001) • Posts: 6250 • Rating: +318/-36 • little oof ##### Re: investigating port$2F
« Reply #15 on: October 01, 2020, 06:25:37 pm »
My 84+ SE gave 21845, 21845, 21845, 21845
What hardware revision?
/e

• LV6 Super Member (Next: 500)
• Posts: 346
• Rating: +47/-0
##### Re: investigating port $2F « Reply #16 on: October 01, 2020, 07:05:04 pm » My 84+ SE gave 21845, 21845, 21845, 21845 Thanks ! Pretty fixed delays so far, except for Eeems' haunted calc. What if TI hardcoded higher default delays on models with the infamous Novatek display driver ? That would make sense, considering the OS only polls port$02, and port $2F setting for CPU speed 1 is already maxed for the 84+ & 84+SE. « Last Edit: October 01, 2020, 07:26:15 pm by the_mad_joob » #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 346 • Rating: +47/-0 ##### Re: investigating port$2F
« Reply #17 on: October 02, 2020, 03:32:14 am »
Happy 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.
« Last Edit: October 02, 2020, 03:55:18 am by the_mad_joob »

#### Eeems

• Mr. Dictator
• LV13 Extreme Addict (Next: 9001)
• Posts: 6250
• Rating: +318/-36
• little oof
##### Re: investigating port $2F « Reply #18 on: October 02, 2020, 09:41:56 am » Happy 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, 65535 /e #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 346 • Rating: +47/-0 ##### Re: investigating port$2F
« Reply #19 on: October 02, 2020, 11:40:57 am »
65535, 65535, 65535, 65535
Thanks.
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). #### Eeems • Mr. Dictator • Administrator • LV13 Extreme Addict (Next: 9001) • Posts: 6250 • Rating: +318/-36 • little oof ##### Re: investigating port$2F
« Reply #20 on: October 02, 2020, 11:43:57 am »
65535, 65535, 65535, 65535
Thanks.
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, 65535 /e #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 346 • Rating: +47/-0 ##### Re: investigating port$2F
« Reply #21 on: October 02, 2020, 12:16:25 pm »
65535, 30583, 65535, 65535
Those 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. #### Eeems • Mr. Dictator • Administrator • LV13 Extreme Addict (Next: 9001) • Posts: 6250 • Rating: +318/-36 • little oof ##### Re: investigating port$2F
« Reply #22 on: October 02, 2020, 12:48:25 pm »
65535, 30583, 65535, 65535
Those 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. 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. EEEMS2 now returns 32767, 255, 7, 0 /e #### the_mad_joob • LV6 Super Member (Next: 500) • Posts: 346 • Rating: +47/-0 ##### Re: investigating port$2F
« Reply #23 on: October 02, 2020, 01:17:05 pm »
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.

EEEMS2 now returns 32767, 255, 7, 0
DCS might include some code similar to what ALCDFIX does.
However, it makes little sense, now that the updated P2FTEST1 kicks you if that's the case (instant return to TI-OS, you shouldn't see any number at all).

Anyway, i came with a more reliable algorithm idea for my project, that won't rely on reference delays.
And making it compatible will ALCDFIX or similar will add to the challenge.

You've been of great help, sir !

• LV6 Super Member (Next: 500)
• Posts: 346
• Rating: +47/-0
##### Re: investigating port $2F « Reply #24 on: October 04, 2020, 07:23:02 am » Holy moly... Looks like i figured out most of the inconsistencies. It appears some of the opcodes i used in my test programs take longer to process than i thought. More specifically, EX (SP),HL actually lasts 20 cycles instead of 19, and PUSH AF lasts 12 instead of 11. The culprit is port$2E, which by default adds 1 cycle to every write in memory.
With that in mind, i'm gonna write a new delay tester, hoping not to find more surprises.

EDIT :

Post#1 updated with the new delay values, which are way more consistent.
I also added a few more details on the inconsistencies i discovered, code examples soon to come.
« Last Edit: October 05, 2020, 08:04:20 am by the_mad_joob »

##### Re: investigating port $2F « Reply #25 on: December 22, 2020, 08:18:08 am » Alright, it seems what i believed to be LCD crashes actually aren't. In short, it appears that in some specific contexts, writing to port$2F can cause bit 1 of port $02 to become permanently reset. The nasty consequence is that all codes that poll that bit before interacting with the LCD (basically all OS display routines) enter an endless loop. Here is a program that shows what i'm talking about. It supposedly displays the state of port$02 bit 1, and waits for any keypress before exiting :
.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),await_key_pressed in a,(01) inc a jr nz,key_pressed in a,(04) and b jp nz,wait_key_pressedkey_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) direstore_textshadow bcall(_rstrshadow) di retrestore_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),akeybclear_wait_keys_released in a,(01) inc a jp nz,keybclear_wait_keys_releasedkeybclear_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,240keybclear_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. I believe what specifically causes the bit to become static is the too close proximity between OUT ($20),A & OUT (\$2F),A, but i'm not entirely sure yet.