Thinking of screenmodes

[Jeroen]

Hi

I'm new to the whole uzebox thing and reading as much as I can about it.
One thing I don't really understand yet is the screen modes.
For example video mode 3 without scrolling is 240x224 pixels, 53760 pixels / frame.
If I understand the wikipedia articel correct, NTSC uses 30 frames / second interlaced.
Interlaced costs only half of the data so 53760 * 30 / 2 = 806400 pixels / second needs to be drawn.
(for now I ignore the vsync and hsync signals)
The speed of the controller is 28.63636 MHz so every 28636360 / 806400 = 35 clocks a pixel is drawn.
An interrupt is used on which the pixel is send.
The interrupt itself costs 5 cycles to go to the handler and 5 cycles to return, the writing to the io-port costs 1 cycle.
So without setting the data ready to send to the io-port, this already takes 11 / 35 = 31.4% of the available cpu time.

Is this correct?

[uze6666]

Hi Jeroen,

Welcome to the Uzebox community. I guess your question is really about how much cpu is left? I'll try to answer that with a bit of background.

In NTSC there 30 frames second and a frame is made of two interlaced fields for a 60Hz refresh rate. Full NTSC have ~480 viewable lines, 240 on each field. The Uzebox video modes with resolutions of 240x224 in fact draw the 224 lines twice, one for each field. So the rate is really 240x224x60=3225600 pixels per second. Each pixel takes 6 cycles to produce, so direct rendering eats 3225600x6=19.4M cycles or ~68% of available CPU. In reality, it's higher than that since a field in rendered in one pass without returning control to the main program. There's also overhead for generating the VSYNC and HSYNC. Since there's 1820 cycles per scanline, that's 1820x229 (~5 extra lines for the overhead) = 25M cycles or ~87%. So from here you're left with the equivalent of about 33 scanlines per second of cpu.

So that was for rendering only. From that you must substract the sound engine mixer and music processing made during VSYNC and the sprites pre-processing for mode 3, joypad reading and other kernel things. All those takes about 20-25 scanlines worth of cpu. The rest is available for the main program. Not much at first sight, but 10 lines if well enough for most games.

-Uze

[D3thAdd3r]

Should also mention there are compile flags which allow rendering less vram tiles vertically, thus freeing massive cycles (and ram) for games with heavier logic. Almost crazy what can be pulled off in '644's "spare time" with a little creativity. To me an indispensable feature

[Jeroen]

Thanks Uze, thats clear to me now

D3thAdd3r, do you mean if for example I use a screen mode with 224 rows and have 10 rows of time left for the game but use a compile flag to don't use 8 rows, I get 18 rows of time for the game?

[uze6666]

D3thAdd3r, do you mean if for example I use a screen mode with 224 rows and have 10 rows of time left for the game but use a compile flag to don't use 8 rows, I get 18 rows of time for the game?

That's right. For example using mode 3, you have 28 vertical tiles for a total of 224 rows rendered. Setting VRAM_TILES_V=27 with render only 216 rows, giving you back 8 rows worth of CPU. This also free the RAM normally occupied by that tile row (30 bytes when not using scrolling). Note that since rev.191, the number of lines to render can be set dynamically (but RAM allocation stays static). That can be very useful when a temporary boost of CPU cycles is required, like for chess 4 uzebox, when the cpu is "thinking".

-Uze