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.
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.
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).
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.
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.
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.
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)
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 !
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 =[
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 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 :
Oh, thank you for adding this update! It's annoying that these new calcs don't work the same .__.
Definitely. TI probably invested in new LCDs or controllers, cheaper than the ones we had back in the days. However, no matter which new hardware TI decides to implement, it can't be slower than the delays used by the OS, otherwise they would need to update it. Following such logic, i inspected the latest TI-OS for each model (TI-83+[SE] : 1.19 | TI-84+[SE] : 2.55). Basically, the system always uses at least these numbers (total clock cycles between instructions). Note that these amounts are only valid while having ports $29,$2A,$2E,$2F holding default values. There you go :
TI-83+ : 73 TI-83+SE @ CPU speed 0 : 73 TI-84+ @ CPU speed 0 : 139 TI-84+SE @ CPU speed 0 : 139 TI-83+SE @ CPU speed 1 : 215 TI-84+ @ CPU speed 1 : 339 TI-84+SE @ CPU speed 1 : 339
Sorry for the necro, but it's a sticky thread, and random people ending up here might wanna know about this. Apparently, the method of checking bit 7 of port $10 isn't reliable on all hardwares anymore =[ That means, only the following methods remain :
# busy state check : all models except TI-83+ non-SE - CPU speeds 1|2|3 only Check bit 1 of port $02 (0=busy|1=ready). Note that though it doesn't mean the LCD is actually ready, the bit will always be set on the TI-83+ non-SE, or if using CPU speed 0. The busy state duration is defined through port $2F.
# automatic delay : all models except TI-83+ non-SE The delay duration is defined through ports $29|$2A|$2B|$2C (CPU speeds 0|1|2|3 respectively).
# manual delay : all models Actually the only remaining method for TI-83+ non-SE.
battchecka : now fully standalone battcheckb : slightly faster flashlocka : slightly faster flashlockb : slightly faster flashsize : now called romsizeb and now in romsize.z80 flashunlocka : slightly faster flashunlockb : slightly faster and now using the stack instead of a custom RAM location for backup font : $00>$1F and $7F now blank for accuracy purpose keybscan : slightly faster and more consistent romsize : now called romsizea romwritex : slightly faster sectcheck : now called secstate for accuracy purpose secterase : slightly faster
Application variants now come first in each file. Improved the documentation here & there. Everything is in one zip now.
https://wikiti.brandonw.net/index.php?title=83Plus:Ports:2F Quote : "After every write to the LCD bit 1 of port 2 resets for a certain amount of time based on the current cpu speed and if the calculator is in hi speed mode." It's actually working after every read aswell (tested with both ports $10 & $11).
https://wikiti.brandonw.net/index.php?title=Z80_Instruction_Set Quote : "POP Same syntax as PUSH. Copies (SP) to regLSB, increments SP, copies (SP) to regMSB, then increments SP again. The word based at the starting value of SP is zeroed." The last sentence is wrong and should be removed. Also, no matter how useful they are, the following instructions are missing : ld J,N ld ixh,ixh ld ixl,ixl ld iyh,iyh ld iyl,iyl
https://wikiti.brandonw.net/index.php?title=83Plus:OS:Raw_Flash_Commands In the example code of the "Writing" section, using a "bit 5,(hl)" instruction is actually wrong. Indeed, if the writing becomes successful after the xor (hl) instruction, reading (hl) again won't return status data anymore. In other words, such algorithm could return a failure where there isn't any. The right way to do it is to check both bits from a single reading. Unoptimised replacement code :
... programWaitLoop: ina, (keyPort) cp0BFh jrz, abortProgram lda, (hl) ldc, a xorb bit7, a jrz, programDone bit5, c jrz, programWaitLoop abortProgram: ... https://wikiti.brandonw.net/index.php?title=Category:83Plus:Ports:By_Address Quote : "All writes to mirrored ports are ignored." That is wrong and should be removed.
https://wikiti.brandonw.net/index.php?title=83Plus:Ports:2E It's worth noting that as far as bits 0 & 4 are concerned, the extra clock cycle is doubled if the instruction is prefixed. We can safely deduct that the port adds a clock cycle each time the R register is incremented.
https://wikiti.brandonw.net/index.php?title=83Plus:Ports:01 Quote : "While a key is in a state between pressed and released, it will repeatedly turn on and off." It's worth mentioning that such behaviour only occurs for keys that were just released, not pressed. In other words, a key that was just released can be detected as pressed right after, but not the other way around.
https://wikiti.brandonw.net/index.php?title=83Plus:Ports:20 In the "Examples" section, it's worth mentioning that the second method will switch to CPU speed 3, not 1. That speed may not be fully supported software-wise, most notably because the default delays provided by ports $29>$2C|$2E|$2F vary from one speed to another. Here is a jump-free method that switches to speed 1 instead : in a,($02) rlca and %00000001 out ($20),a
Updated my snacks, and finally managed to make each file standalone, as far as documentation & warnings are concerned. I prepared everything in 1 attached zip for the occasion, without the 3 files that aren't code. Thanks in advance for the boring ctrl+c|v job, we all know the feeling, i guess.
Show Posts
