LCD interrupt timing is a little bit off

[runer112]

I wrote a program to measure the number of cycles between LCD interrupts. I noticed that, although the total time spent on a frame seems right, the exact timing of the different LCD interrupts is not.

The program prints 5 numbers. They measure the number of cycles between the vsync (vcomp) interrupt and:

1. (next) vsync
2. back porch
3. active video
4. front porch
5. base address update

There is some additional overhead captured in the measurement as well, but that wouldn't explain the difference observed. Apart from some small deviations in the first measurement, the other measurements are consistent across runs on both hardware and CEmu.

Results on real hardware (default TI-OS timing):

Results on CEmu:

If you'd like to test this yourself, following is the source code for the program I created. Assemble with spasm-ng.

.nolist
#include "ti84pce.inc"
.list

.db tExtTok,tAsm84CeCmp
.org userMem

    call _HomeUp
    ld bc,(lcdPwr|lcdBgr)|(lcdIntVcomp)
loop:
    push bc
    call test
    pop bc
    ld a,b
    add a,1<<4
    bit 6,a
    ld b,a
    jr z,loop
    ld c,lcdIntLNBU
    call test
    call _usb_ResetTimer
    jp _GetKey

test:
    di
    ld a,(lcdPwr|lcdBgr)>>8
    ld (mpLcdCtrl+1),a
    ld hl,tmr1CountUp
    ld (mpTmrCtrl),hl
    ld de,17
    ld h,d
    ld (mpTmr1Counter),hl
    ld hl,mpLcdIcr
    ld (hl),lcdIntVcomp
waitforstart:
    ld a,(mpLcdRis)
    and a,lcdIntVcomp
    jr z,waitforstart
    ld a,tmr1Enable
    ld (mpTmrCtrl),a
    ld (hl),c
    ld l,lcdCtrl+1
    ld (hl),b
    sbc hl,hl
wait:
    add hl,de
    jr c,timeout
    ld a,(mpLcdRis)
    and a,c
    jr z,wait
    ld hl,(mpTmr1Counter)
    call _DispHL
timeout:
    jp _NewLine

[mateoconlechuga]

Are you sure that this isn't caused by usb dma? It appears in the first screenshot that the calculator was plugged into the computer.

[runer112]

Rerunning the program on hardware with the USB cable disconnected gives the same results.

[mateoconlechuga]

So these numbers: 41 36 -6 -6 -66 correspond to the differences. When added together and accounting for difference, this results in 0. It does show that the time spent in each frame is correct; there just appears to be a number that is skewing these results. I believe this is more related to the timer issues than LCD issues.

[adriweb]

Tried the program today on latest CEmu master (with SPI), here's a comparison from @runer112's value on the left:

February	June

So apparently, some got better and some got worse.

On calc (rev E), got the same numbers as @runer112 ; screenshot here again for easier comparison: