Author Topic: investigating port $2F  (Read 5605 times)

0 Members and 1 Guest are viewing this topic.

Offline Eeems

  • Mr. Dictator
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6234
  • Rating: +318/-36
  • little oof
    • View Profile
    • Eeems
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

Offline the_mad_joob

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 342
  • Rating: +47/-0
    • View Profile
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 »

Offline the_mad_joob

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 342
  • Rating: +47/-0
    • View Profile
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 »

Offline Eeems

  • Mr. Dictator
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6234
  • Rating: +318/-36
  • little oof
    • View Profile
    • Eeems
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

Offline the_mad_joob

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 342
  • Rating: +47/-0
    • View Profile
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).

Offline Eeems

  • Mr. Dictator
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6234
  • Rating: +318/-36
  • little oof
    • View Profile
    • Eeems
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

Offline the_mad_joob

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 342
  • Rating: +47/-0
    • View Profile
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.

Offline Eeems

  • Mr. Dictator
  • Administrator
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 6234
  • Rating: +318/-36
  • little oof
    • View Profile
    • Eeems
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

Offline the_mad_joob

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 342
  • Rating: +47/-0
    • View Profile
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 !

Offline the_mad_joob

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 342
  • Rating: +47/-0
    • View Profile
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 »

Offline the_mad_joob

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 342
  • Rating: +47/-0
    • View Profile
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 :
Code: [Select]
.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

;###############################################################################

.end
This 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.

EDIT :

After having inspected multiple code contexts, i believe i finally managed to isolate most of it.
See my first post for details.
« Last Edit: December 22, 2020, 09:29:02 pm by the_mad_joob »