I stumbled across a few TIMXT-related posts while browsing the forums today and it got me thinking about the ugly challenge I ran into, where the RS232 interrupt handler periodically dropping characters. The problem seemed to start sometime after adding the Ubergrom UART code and the PETSCII interpreter code to the core routines.
Having not looked at the program source for some time, I started walking through the TIMXT rs232 routine. Everything looked fine. On whim I cracked open "TI Intern", thinking maybe I was missing something related to the ROM interrupt handler.
While reviewing the ISR ROM source I noticed that during a VDP interrupt, the ISR re-enables the 9901's VDP interrupt mask. The TIMXT routine expects this mask to be disabled, so as to trick the ISR into handling a PEB external interrupt as a VDP interrupt, forcing execution of the user interrupt routine, which in turn promptly services the RS232 interrupt.
It seems that when I added nanoPEB support, I commented out a CRU instruction to disable the 9901 VDP interrupt mask. I suspect I did this to account for the extra CRU instructions needed to enable and disable the nanopeb ROM cru bit. (The nanopeb incorrectly requires its RS232 rom to be enabled before enabling the 9902). At the time I did not notice any problems and since I had shifted to implementing the ubergrom UART I eventually forgot about the change.
Once I returned to using the PEB RS232 I started experiencing lost characters, usually when connected at slower speeds or to slower BBSs. When the TI ISR and TIMXT hndler capture an incoming character the VDP interrupt mask is re-enabled, and the ISR immediately fires off a second time to service the still-active VDP interrupt. The TIMXT interrupt handler doesn't find a pending RS232 interrupt so it defaults into thinking there was a spurious interrupt, disables the 9901 prioritization bit/VDP mask, then exits the ISR. (This 'safety measure' explains why the ISR is not stuck in an endless loop after the first character is received). When the next RS232 character is received the whole cycle begins again - the ISR is called, RS232 interrupt is handled, control is returned to the caller, and the ISR is called an unnecessary second time.
Depending on the timing of other routines, such as the keyboard scan and reception speed, rs232 characters are randomly dropped.
Although I am not able to fix the routine program at the moment, I am hopeful the fix will eliminate what has been a very annoying and difficult problem to figure out.
I'm not sure why the test release for the ubergrom UART drops characters as all of my usage seemed pretty flawless. I'll revisit that at another time as well.