Welcome.

While i was randomly testing stuff on a TI-83+ (real hardware), i came across a pretty unexpected behaviour.
I isolated what's relevant in a tiny program :
.db $BB,$6D
di
xor a
out (1),a
ld bc,0
wait_key_released
in a,(1)
inc a
jp nz,wait_key_released
retThat code does what it's supposed to do successfully.
When you press ENTER to start the program, it freezes until you release the key.
Then, when the key is released, you're back to the homescreen.

Now let's say you decide to use LD BC,1 instead.
In that case, you should expect the exact same behaviour, right ?
Well, in reality, the program exits right away, despite the key is still being pressed.
That basically means the loop is exited at some point (i suspect it's exited right away).
The very big problem i have with that, is that the LD BC,X instruction isn't supposed to have any influence on the condition check at all.
Any idea what's happening ?

EDIT 1 :

I suspected it had something to do with the proximity of the OUT & IN instructions, and i believe i was right.
Indeed, if the LD instruction is removed, the keypress is ignored aswell, probably because the TI-83+ keyboard is so slow that opening groups takes some time.
With a single NOP instruction, keypress ignored aswell.
However, 2 NOP instructions are enough.
But that doesn't solve the mystery yet, because that would mean that somehow, 2 NOPs (8 CC) take more time to process than 1 LD BC,X (10 CC).
And that still doesn't explain why the processing time of LD BC,X can vary depending on X.
Is my z80 drunk ?

EDIT 2 :

I officially entered the twilight zone.
I started to test the LD BC,X arguments, in hope of finding a pattern.
I didn't, but instead, i found out that it's even worse than i thought :
0 = keypress not detected
1 = keypress detected
WTF = RAM clear when key released

LD BC,X RESULT
$0000 1
$0001 0
$0002 1
$0010 1
$0011 0
$0012 1
$00F0 1
$00F1 WTF
$00F2 0
$00FF 0

Sweet baby carrots :0
Maybe the actual circuits bare degraded causing bits to linger on the bus or something? Other idea: it looks like the code might be missing the 01 in the "ld bc,**" instruction (01xxxx) because he LSB comes first.

Code: [Select]

$0000  1 nop \ nop
$0001  0 ld bc,xx00h (DB00 in your case)
$0002  1 ld a,(bc) \ nop
$0010  1 djnz $+0
$0011  0 ld de,xx00h
$0012  1 ld (de),a \ nop
$00F0  1 ret p \ nop
$00F1  WTF pop af \ nope (oof!)
$00F2  0 jp p,xx00
$00FF  0 rst 38h \ nop
Once the program is on your calc, if you could hex-dump it, then we could check if maybe it is missing the 01.

Thanks for your time.
I already hex-checked the program data using calcsys, since i couldn't believe what i witnessed, so it's not that.
I was actually suspecting the LD BC,X instruction was processed as multiple ones myself, and i was just finding that POP AF thing right before your post .
About the degraded circuits theory, that could be a lead, though i believe i would have noticed some significant bugs|crashes elsewhere.
However, now that i think of it, it could be that the problem is specific to the RAM area where the LD BC,X is located.

EDIT : It's a TI-83+VS from 1999, the only noticeable thing being a slightly damaged LCD.