Calculator Community > ASM

investigating port $2F

<< < (6/6)

the_mad_joob:
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: ---.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
--- End code ---
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.

Navigation

[0] Message Index

[*] Previous page