Ok, wygląda to tak, jakby faktycznie winę za niestabilne działanie
układu ponosiło przepełnienie stosu. Zamiast wywoływać funkcję
key_update() z pętli głównej, umieściłem tam odpowiadający jej fragment
kodu (cc65 na chwilę obecną jest dość ubogim kompilatorem, wśród jego
ograniczeń znajduje się m.in. brak funkcji inline). Wszystko zaczęło
działać.

Trochę mnie to dziwi, bo:
- Nie mam w tym kodzie głęboko zagnieżdżonych funkcji. Funkcje
key_update() była wywoływana bezpośrednio z pętli głównej, ona sama
wywołuje tylko funkcję millis() - wzorowaną na Arduino funkcję
zwracającą ilość taktów systemowych generowanych w przerwaniu (ze
względu na niskie taktowanie są one zwiększane co 20 ms, a nie 1 ms).
- Sprzętowy stos 6502 jest co prawda niewielki, ale cc65 generuje
własny, programowy stos.
- Pamięci jest sporo jak na taki układ (8kB) i jak na razie zbyt mocno
jej nie wykorzystuję. Najwięcej zużywają chyba bufory dla UART-a (2x 256
bajtów). Jest też kilka pomniejszych buforów i trochę zmiennych. Aż
sprawdziłem, czy przypadkiem łańcuch tekstowe podawane jako argumenty
funkcji nie trafiają przypadkiem do RAM-u, ale w generowanym przez
kompilator kodzie asemblerowym są oznaczone jako .rodata.

Gdyby kogoś szczególnie interesowała ta zagadka, to wrzuciłem kody
źródłowe na githuba,

To jest ten problematyczny:
https://github.com/marekw1986/RetroEG

A tutaj działający:
https://github.com/marekw1986/TalkingClock
(Definicja key_update w io.c)