Pixel aspect ratio?

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Pixel aspect ratio?

Post by Jubatian »

Hi!

Just discovered this nifty little piece of hardware, and, of course, I immediately started to brew grand (or not so grand) ideas on how to mess around with its graphics. Well, naturally, take the dive before even starting :) I studied the kernel provided modes for a while, and in general how it works, looks fun (like when I did graphics poking around fully VIC sync on the C64). I however only have access to emulators for now (no big hardware experience, PAL region, and I only have a little late 80's TV set used with the C64, not even having scart).

So anyway, I see that there are 1820 cycles for a line in there, and from that, comparing to NTSC C64 and its known pixel aspect ratio I deducted that using 4 cycles for a pixel would give almost square pixels on an average TV set (maybe a bit wider than tall, but reasonably square). 8 cycles then would make 2:1 wide pixels (like Multicolor on C64 or Enterprise 128K's 16 color mode). I sketched up some fun modes starting out from Mode 2 which I might try to actually implement later.

Are my assumptions here about the aspect ratio right?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Pixel aspect ratio?

Post by uze6666 »

Hey Jubatian, welcome to the Uzebox community! Always nice to see other assembler guys around. Making video modes is an art and very gratifying when it finally works. :)

For the aspect ratio, that is a good question, I just can't recall the calculation to make. But 4 or 5 cycles yields square enough pixels if I recall.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Pixel aspect ratio?

Post by Jubatian »

Then hope no problem musing a bit further around it ;)

The Commodore 64, well, that's "the" machine when it comes to retro 8 bit computing (Well, sure there are contenders, Amstrad CPC anyone?, but by games and demos its certainly a winner). Uzebox is NTSC, let's see what the NTSC C64 has in comparison.

On (most) of the NTSC 64's a video line takes 65 cycles (a few early 64's had a VIC which used 64 cycles / line, PAL is 63 cycles, annoying when doing cross platform VIC sync code). Of this 65 cycles, 40 cycles are used to output the 320 pixels wide main display area (or 160 pixels in multicolor mode). This alone doesn't reveal too much of the true aspect ratio since the 64 had quite thick borders. However there are a whole lot of VIC synced demos which remove those borders to expand the display area using sprites which the VIC would display there unless hidden by the border. One sprite is 24 pixels wide. Common usage is adding one sprite column to the left and one to the right, and an avid C64 fan watching demos makes sure that his TV set is capable to display those. This implies that a C64 demo compliant TV set displays 368 (or more) C64 pixels horizontally.

There is a great article on the C64's video output on PAL / NTSC here: http://hitmen.c02.at/temp/palstuff/
When I first posted this, I somewhere found the 0,936:1 figure, but thought it applied to NTSC. Apparently NTSC rather has 0,75:1 aspect ratio (pixels are a lot thinner than how tall they are), no wonder knowing how the PAL has more rows.

Anyway, back to Uzebox.

If I take the 65 cycle / line NTSC C64, one C64 tile becomes 28 Uzebox cycles. The normal 320 pixels wide C64 display would then take 1120 Uzebox cycles. On the avid C64 fan's TV set, properly aligned, 46 C64 tiles or 1288 Uzebox cycles worth of data should be minimally visible. One NTSC C64 pixel should be 3,5 Uzebox cycles.

From the 0,75:1 aspect ratio figure, to get square pixels (1:1 aspect ratio), 276 pixels should be output instead of 368, which then implies 4,67 Uzebox cycles for one pixel.

Then the 4 / 5 figure is right there :)

I wonder about the PAL variant (EUzeBox), but I guess for compatibility reason it also uses 1820 cycles for a line, so the kernel works unchanged. But that, due to the more lines on a PAL TV set flattens the pixels, so a thinner pixel would be closer to square there, suggesting using 4 cycles per pixel.

Mixing square and wide pixel modes in a clean manner (like split screen on a C64) is tricky. 9 pixels would work best for the wide pixel mode (a bit too thin on NTSC, a bit too wide on PAL). But that's not dividable by 2. Maybe alternate 4 / 5 cycle in output? (Shouldn't be much noticeable)

Programming details.

I already did some thought experiments spitting out drafts of assembly for some mode ideas which popped in my mind. 4 cycles / pixel is a beast. 1 cycle is needed for the out, leaving 3 cycles to do anything. A progmem line (3 cycle lpm), useless. With anything RAM based the problem is that just about every RAM accessing instruction takes exactly 2 cycles, so ending up wasting so many nops in there instead of interleaving worthy code.

The 4 / 5 alternating is a much nicer setup since you get a possibility of 3 RAM accesses while outputting 2 pixels, which opens possibilities for some playing around.

9 cycles / pixel is again a nice setup from the point of interleaving RAM code since there are 8 cycles (even) between two outs.

These viewpoints seem odd from the usual Uzebox graphics mode design principles where you load tiles from progmem directly for output (and using RAM tiles for sprite blitting), however I am attempting a different approach here, line buffer based ideas, interleaving the line buffer management code with pixel output, which needs lots of RAM reads / writes (so the many 2 cycle instructions to shoehorn in there).

Anyway, that's an other story of a more distant future, offtopic here.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Pixel aspect ratio?

Post by D3thAdd3r »

I believe there should be 1440 cycles that are not part of HSYNC and various televisions wont display perhaps 4-8 pixels of the left and right sides(for ie. mode 3 pixels at 6 cycles). Apparently many LCD/LED televisions do this overscan just like CRTs did, so my guess there is a minimum of 1344-1392 visible scanline cycles. I'd be quite interested to see how the mixed width pixels looks over composite. About every time I ever tried to do video mode stuff, I always wished for 1 extra cycle somewhere to avoid a NOP waste and it's easily the difference between not possible and possible. Who knows, if it looks OK, that could open up a new way of thinking about video modes.
Jubatian wrote:I wonder about the PAL variant (EUzeBox), but I guess for compatibility reason it also uses 1820 cycles for a line, so the kernel works unchanged. But that, due to the more lines on a PAL TV set flattens the pixels, so a thinner pixel would be closer to square there, suggesting using 4 cycles per pixel.
I never thought about that but it makes sense, interesting. Seems impractical to make separate versions of games and the cycle granularity probably does not allow anything to be done about pixel widths between them unfortunately.
Jubatian wrote:The Commodore 64, well, that's "the" machine when it comes to retro 8 bit computing
I recently bought a mint C128 w/ boxes/accessories/modems/games/etc to relive a great era I was slightly too young to enjoy sadly. I have to agree the C64 is about as legendary as anything can get, it's an amazing library, kind of retro dreaming of old school dialup Bulletin Board System stuff lately but that is a bit off topic :geek:
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Pixel aspect ratio?

Post by uze6666 »

I wonder about the PAL variant (EUzeBox), but I guess for compatibility reason it also uses 1820 cycles for a line, so the kernel works unchanged. But that, due to the more lines on a PAL TV set flattens the pixels, so a thinner pixel would be closer to square there, suggesting using 4 cycles per pixel.
The EUzebox just relies on the fact that TVs from the last 10+ years all understand NTSC natively. So no need to change the kernel or anything. With SCART, even the Video DAC is the same. :)

The highest usable resolution mode attained so far runs at 3 cycles per pixel (mode 6/80) for a 80x25 tiles mode with 6x8 pixel tiles. It uses tile data made of AVR assembly instructions.

For all trick of the trade discovered so far, you can check mode13 in the paletteMode branch. Of interest is the "getting out of loop by interrupt" trick by CunningFellow, rom & ram tables adressed at zero and the "X+" trick to quickly adress two packed pixels for the palette LUT.

As for the C64, yeah it's really a legendary piece of hardware. The graphics were nice but the sound really stole the show for me. It's unbelievable what they still manage to extract from it in the recent demo compos.
Post Reply