Welcome.

Long story short, i'm trying to code a new LCD tool that optimises port $2F, so i used this page 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 :

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

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.

Quote from: Eeems on September 30, 2020, 12:40:42 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.

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 !

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)

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.

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.

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