Calculator Community > ASM
investigating port $2F
the_mad_joob:
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 :
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 valuesIt'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
Eeems:
I get 0, 0, 0, 0 on my 84+
NonstickAtom785:
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.
the_mad_joob:
--- Quote from: Eeems on September 30, 2020, 12:40:42 pm ---I get 0, 0, 0, 0 on my 84+
--- End quote ---
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 ?
--- Quote from: 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.
--- End quote ---
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 =[
Eeems:
--- Quote from: the_mad_joob on September 30, 2020, 02:04:08 pm ---
--- Quote from: Eeems on September 30, 2020, 12:40:42 pm ---I get 0, 0, 0, 0 on my 84+
--- End quote ---
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 ?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version