Max pixel fill speed with OTIR

Original Here

One of the fastest practical ways to write arbitrary pixels (no 1-color rectangles) to the LCD is

with an OTIR loop copying pixel data directly from memory. That being said, I was wondering how many

pixels you could theoretically update per frame. As mentioned, this is theoretical. This does not

take into account the overhead of adjusting the LCD window, or any of the other logic you may have.

It also assumes that interrupts are disabled.

The code

The code I'll be using to calculate max fill rate is

I use JP in the loop to save a few extra cycles. When calculating the numbers below, I'm basing it

only on the runtime of the loop, and I'm not calculating the negligible setup time for the loop.

The numbers

The TI-84+CSE uses a z80 processor, which can be set to run at 15Mhz. This means that it has about

15,000,000 cycles (or T-States) per second. All instructions take more than one T-State to run. The

ones we care about are:

OTIR: (21 * (B - 1)) + 16

► If B == 0, evaluate B - 1 as 255

DEC D: 4

JP nz, ADDR: 10

Now, the hardware adds an extra 4 T-states to ever OUT to the LCD port, so

the TRUE cost of OTIR is

OTIR: (25 * (B - 1)) + 20

Based on those numbers, we can calculate the amount of T-states for any given

input of DE

When B = 0, the loop takes (25 * 255 + 20) + 4 + 10 T-States, or 6409.

Therefore if E == 0

f(D,0) = 6409 * D

Otherwise if E > 0

f(D,E) = ((25 * (E - 1)) + 34) + 6409 * D

To simplify calculations, I'm going to ignore the fact that 'D' can not be greater than 255. This

allows me to use the above equation for the dimensions of the entire screen, and get a reasonably

close estimate of how much time it would take.

The calculations

The screen is 320x240 pixels large. Each pixel is 2 bytes. 320 * 240 * 2 = 153600. 153600 / 256 =

600, so D = 600 and E = 0. 600 * 6409 = 3,845,400.

To update the entire screen with this method it takes 0.25636 seconds. Not very promising, but

here's a table of screen percentages vs how much time it takes to update. For any dimensions that

you want to calculate yourself, the simplest way would be to use this formula.

(WIDTH * HEIGHT) / (320 * 240) * 3845400

Divide 15,000,000 by the result to get framerate.

EDIT: Fixed my math

Original Here

One of the fastest practical ways to write arbitrary pixels (no 1-color rectangles) to the LCD is

with an OTIR loop copying pixel data directly from memory. That being said, I was wondering how many

pixels you could theoretically update per frame. As mentioned, this is theoretical. This does not

take into account the overhead of adjusting the LCD window, or any of the other logic you may have.

It also assumes that interrupts are disabled.

The code

The code I'll be using to calculate max fill rate is

**Code:**```
```

;Input: HL = data

; DE = Amount of pixels to output

; Generally this would be width * height

; This means that DE can never be the size of the ENTIRE screen,

; just 85.3% of it.

ld b,e

ld c,11h

;If B != 0, we need an extra iteration, so D needs to be incremented

dec de

inc d

_dispSprtLp:

otir

dec d

jp nz,_dispSprtLp

I use JP in the loop to save a few extra cycles. When calculating the numbers below, I'm basing it

only on the runtime of the loop, and I'm not calculating the negligible setup time for the loop.

The numbers

The TI-84+CSE uses a z80 processor, which can be set to run at 15Mhz. This means that it has about

15,000,000 cycles (or T-States) per second. All instructions take more than one T-State to run. The

ones we care about are:

OTIR: (21 * (B - 1)) + 16

► If B == 0, evaluate B - 1 as 255

DEC D: 4

JP nz, ADDR: 10

Now, the hardware adds an extra 4 T-states to ever OUT to the LCD port, so

the TRUE cost of OTIR is

OTIR: (25 * (B - 1)) + 20

Based on those numbers, we can calculate the amount of T-states for any given

input of DE

When B = 0, the loop takes (25 * 255 + 20) + 4 + 10 T-States, or 6409.

Therefore if E == 0

f(D,0) = 6409 * D

Otherwise if E > 0

f(D,E) = ((25 * (E - 1)) + 34) + 6409 * D

To simplify calculations, I'm going to ignore the fact that 'D' can not be greater than 255. This

allows me to use the above equation for the dimensions of the entire screen, and get a reasonably

close estimate of how much time it would take.

The calculations

The screen is 320x240 pixels large. Each pixel is 2 bytes. 320 * 240 * 2 = 153600. 153600 / 256 =

600, so D = 600 and E = 0. 600 * 6409 = 3,845,400.

To update the entire screen with this method it takes 0.25636 seconds. Not very promising, but

here's a table of screen percentages vs how much time it takes to update. For any dimensions that

you want to calculate yourself, the simplest way would be to use this formula.

(WIDTH * HEIGHT) / (320 * 240) * 3845400

Divide 15,000,000 by the result to get framerate.

**Code:**```
```

Percent of Screen | T-states | Theoretical Frames/Second | Dimensions

----------------- | -------- | ------------------------- | ----------

100% | 3,845,400 | 3.9 FPS | 320 x 240

50% | 1,922,700 | 7.8 FPS | 160 x 240 (Half Res)

5.3% | 205,088 | 73.13 FPS | 64 x 64 (Large sprite)

2.7% | 102,544 | 146.28 FPS | 32 x 64 (Large sprite Half Res)

EDIT: Fixed my math