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

Eeems · « **Reply #15 on:** October 01, 2020, 06:25:37 pm »

Quote from: E37 on October 01, 2020, 06:15:09 pm

My 84+ SE gave 21845, 21845, 21845, 21845

What hardware revision?

the_mad_joob · « **Reply #16 on:** October 01, 2020, 07:05:04 pm »

Quote from: E37 on October 01, 2020, 06:15:09 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.

the_mad_joob · « **Reply #17 on:** October 02, 2020, 03:32:14 am »

Quote from: Eeems on October 01, 2020, 12:34:42 pm

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.

Eeems · « **Reply #18 on:** October 02, 2020, 09:41:56 am »

Quote from: the_mad_joob on October 02, 2020, 03:32:14 am

Quote from: Eeems on October 01, 2020, 12:34:42 pm
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

the_mad_joob · « **Reply #19 on:** October 02, 2020, 11:40:57 am »

Quote from: Eeems on October 02, 2020, 09:41:56 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 · « **Reply #20 on:** October 02, 2020, 11:43:57 am »

Quote from: the_mad_joob on October 02, 2020, 11:40:57 am

Quote from: Eeems on October 02, 2020, 09:41:56 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

the_mad_joob · « **Reply #21 on:** October 02, 2020, 12:16:25 pm »

Quote from: Eeems on October 02, 2020, 11:43:57 am

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 · « **Reply #22 on:** October 02, 2020, 12:48:25 pm »

Quote from: the_mad_joob on October 02, 2020, 12:16:25 pm

Quote from: Eeems on October 02, 2020, 11:43:57 am
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

the_mad_joob · « **Reply #23 on:** October 02, 2020, 01:17:05 pm »

Quote from: Eeems on October 02, 2020, 12:48:25 pm

I reran P2FTEST1 and I'm now getting 21845, 21845, 21845, 21845.

Great news.

Quote from: Eeems on October 02, 2020, 12:48:25 pm

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 !

the_mad_joob · « **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.

the_mad_joob · « **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.

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

Eeems

Re: investigating port $2F

the_mad_joob

Re: investigating port $2F

the_mad_joob

Re: investigating port $2F

Eeems

Re: investigating port $2F

the_mad_joob

Re: investigating port $2F

Eeems

Re: investigating port $2F

the_mad_joob

Re: investigating port $2F

Eeems

Re: investigating port $2F

the_mad_joob

Re: investigating port $2F

the_mad_joob

Re: investigating port $2F

the_mad_joob

Re: investigating port $2F