# Omnimaga

## Calculator Community => TI Calculators => ASM => Topic started by: the_mad_joob on September 29, 2020, 06:38:45 am

Title: investigating port \$2F
Post by: the_mad_joob on September 29, 2020, 06:38:45 am
Welcome.

Long story short, i'm trying to code a new LCD tool that optimises port \$2F, so i used this page (https://wikiti.brandonw.net/index.php?title=83Plus:Ports:2F) as a reference.
For now, i'm only interested in the port's behaviour under CPU speed 1 (port \$20), and while having ports \$2A & \$2E holding their default values.

DELAYS

For my project, i need to know the exact amount of cycles during which bit 1 of port \$02 is reset, depending on port \$2F configuration.
But since i don't precisely know when a port is considered read|written during the instruction processing, i checked the amount between them (port \$10|\$11 read|write <> port \$02 check).
So, i was expecting smaller amounts than what's stated on the wiki (48,112,176,240).
Here are the results of my tests :

Spoiler For Spoiler:
port \$2F = %------00 :

clock cycles between IN|OUT and IN A,(C) :
40- : port \$02 = %------0-
41+ : port \$02 = %------1-
clock cycles between IN|OUT and IN A,(\$02) :
41- : port \$02 = %------0-
42+ : port \$02 = %------1-

port \$2F = %------01 :

clock cycles between IN|OUT and IN A,(C) :
104- : port \$02 = %------0-
105+ : port \$02 = %------1-
clock cycles between IN|OUT and IN A,(\$02) :
105- : port \$02 = %------0-
106+ : port \$02 = %------1-

port \$2F = %------10 :

clock cycles between IN|OUT and IN A,(C) :
168- : port \$02 = %------0-
169+ : port \$02 = %------1-
clock cycles between IN|OUT and IN A,(\$02) :
169- : port \$02 = %------0-
170+ : port \$02 = %------1-

port \$2F = %------11 :

clock cycles between IN|OUT and IN A,(C) :
232- : port \$02 = %------0-
233+ : port \$02 = %------1-
clock cycles between IN|OUT and IN A,(\$02) :
233- : port \$02 = %------0-
234+ : port \$02 = %------1-

notes :

IN|OUT : any read|write from|to port \$10|\$11
IN A,(C) : C register holding \$02
test performed at CPU speed 1, from RAM, and with ports \$2A & \$2E holding system default values
It's interesting to see that though the opcode used to interact with port \$10|\$11 doesn't affect the delay, the one used to read port \$02 does.

DISCOVERY : THE CRAZY BIT SYNDROM

We already know that port \$2F affects the behaviour of port \$02 bit 1.
Supposedly, only 2 events can alter the state of that bit :
1) Bit becomes 0 after interacting with a LCD port (delay counter reset).
2) Bit becomes 1 after the delay counter ended.
Well, apparently, the bit can change under other obscure circumstances :

CAUSE :

That occurs if not enough time was spent between A & B (in that order).
A : any write to port \$20, or any read|write from|to port \$10>\$13
B : any write to port \$2F

CONSEQUENCE :

After the write to port \$2F, bit 1 of port \$02 becomes unstable.
That means you cannot rely on it anymore as a LCD busy state checker.
That instability can take 2 different forms :

> The bit toggles by itself for an unknown duration, with no apparent reason.
It's similar to what you would expect from a bouncing behaviour.

> The bit becomes permanently reset.
That one will cause all codes that poll it to enter an endless loop.
That includes of course the famous lcd_busy routine, called by the OS before pretty much all interactions with the LCD.

HOW TO PREVENT :

The duration to wait between A & B can vary depending on several factors, and i'm afraid i don't have enough time to test that deep (anybody welcome).
From what i've experienced, it's way shorter than this, but since writes to port \$2F aren't really supposed to occur that often, i recommend the following each time you write to it :

ld b,0
djnz \$
out (\$2F),a
Title: Re: investigating port \$2F
Post by: Eeems on September 30, 2020, 12:40:42 pm
I get 0, 0, 0, 0 on my 84+
Title: Re: investigating port \$2F
Post by: NonstickAtom785 on September 30, 2020, 12:55:09 pm
I want to test this but I can't do it without having the raw assembly to input onto my calc.

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.
Title: Re: investigating port \$2F
Post by: the_mad_joob on September 30, 2020, 02:04:08 pm
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 ?

I want to test this but I can't do it without having the raw assembly to input onto my calc.

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.
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 =[
Title: Re: investigating port \$2F
Post by: Eeems on September 30, 2020, 03:28:46 pm
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.
Title: Re: investigating port \$2F
Post by: mrwompwomp on September 30, 2020, 04:15:22 pm
I got the same result on all 3 that I could find:
TI-84+ rev V OS 2.55MP
TI-84+ rev S 2.55MP
Prototype TI-83+SE VSC 1.18

21845,21845,21845,21845

Title: Re: investigating port \$2F
Post by: the_mad_joob on September 30, 2020, 06:52:53 pm
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.
The only explanation i see right now would be that the delay provided by port \$2F is somehow relative to the actual CPU speed (not just the CPU speed mode).
However, with what mrwompwomp just posted (see below), i'm not so sure about that anymore.
If i unlock enough time, i might create a different program that reveals which delays your calc uses, i need to know.
Thanks again.
EDIT : Is there a chance ALCDFIX was installed when you ran my program ?

I got the same result on all 3 that I could find:
TI-84+ rev V OS 2.55MP
TI-84+ rev S 2.55MP
Prototype TI-83+SE VSC 1.18

21845,21845,21845,21845
Cool.
21845 (actually 0101010101010101 in binary) is what to expect if the calc uses the exact same delays as on my original post.
That's the numbers i got on my two TI-84+SEs, and the fact that you got the same on both TI-83+SE & TI-84+ is great progress.
Thanks a lot !
Title: Re: investigating port \$2F
Post by: Eeems on October 01, 2020, 10:17:47 am
EDIT : Is there a chance ALCDFIX was installed when you ran my program ?

I believe so.
Title: Re: investigating port \$2F
Post by: the_mad_joob on October 01, 2020, 11:54:45 am
I believe so.
Your port \$2A doesn't probably hold its default value then, which could explain everything.
Could you please confirm that for me ? (Calcsys - port monitor, or attached program)
Title: Re: investigating port \$2F
Post by: Eeems on October 01, 2020, 11:59:32 am
It's reporting 39
Title: Re: investigating port \$2F
Post by: the_mad_joob on October 01, 2020, 12:08:41 pm
It's reporting 39
Damn, 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.
Title: Re: investigating port \$2F
Post by: Eeems on October 01, 2020, 12:34:42 pm
It's reporting 39
Damn, 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.
Happy to run whatever you need to test :)
Title: Re: investigating port \$2F
Post by: NonstickAtom785 on October 01, 2020, 02:47:43 pm
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.
Title: Re: investigating port \$2F
Post by: Eeems on October 01, 2020, 02:53:54 pm
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.

You might want to look into https://ticalc.link/ (https://github.com/Timendus/ticalc-usb/)
Title: Re: investigating port \$2F
Post by: E37 on October 01, 2020, 06:15:09 pm
My 84+ SE gave 21845, 21845, 21845, 21845
Title: Re: investigating port \$2F
Post by: Eeems on October 01, 2020, 06:25:37 pm
My 84+ SE gave 21845, 21845, 21845, 21845
What hardware revision?
Title: Re: investigating port \$2F
Post by: the_mad_joob 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.
Title: Re: investigating port \$2F
Post by: the_mad_joob 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.
Title: Re: investigating port \$2F
Post by: Eeems 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
Title: Re: investigating port \$2F
Post by: the_mad_joob 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).
Title: Re: investigating port \$2F
Post by: Eeems 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
Title: Re: investigating port \$2F
Post by: the_mad_joob 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.
Title: Re: investigating port \$2F
Post by: Eeems 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
Title: Re: investigating port \$2F
Post by: the_mad_joob 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 !
Title: Re: investigating port \$2F
Post by: the_mad_joob 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.
Title: Re: investigating port \$2F
Post by: the_mad_joob 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),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;###############################################################################.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.