.Markku Reunanen.

PAL MSX screen aspect ratio

August 1st, 2016

I’ve been using various guesstimates throughout the years for the PAL MSX screen and pixel aspect ratios, but now there’s finally something credible instead (in contrast, NTSC machines have ~square pixels). According to this discussion thread, the pixels are as wide as 7:5 or, in other words, they are 1.4 times as wide as they are high. That’s pretty flat! I got almost same figures on my own Philips 1084S using a ruler, so they’re very likely correct. Other calculations:

• The pixel area of a 256×192 image is 5.6:3 — almost the same as a modern 16:9 screen
• That is a multiplier of 1.8666… for the image height to calculate the width
• In terms of square pixels 358×192 is very close, or with double pixels 717×384 even better

Viewing a borderless SCREEN 2 image fullscreen on a 16:9 screen gives a pretty good quick estimate of how it will look like. Two things to note are of course that people’s CRT displays are not perfectly calibrated, and that emulators do not use a correct ratio by default. In general horizontal stretching looks worse than vertical, which might be one reason emulators are a bit conservative with their aspect ratios; for example openMSX definitely produces a narrow image – even setting horizontal_stretch to its minimum value of 256 doesn’t make the image flat enough. Furthermore, Japanese Konami warez would appear unnaturally squeezed, even though that’s exactly how they were seen in Europe back in the day.

Square pixels vs. a corrected image:

edit: just as notes here some other numbers. Out of a 313 line full progressive PAL frame about 61.3% is spent on actual pixel lines, while the remaining 121 lines (38.7%) are for the border (113 lines) and vertical sync (8 lines). Dividing 3.58 MHz by 50 yields 71600 clocks per frame, but as a progressive frame is longer (49.92 Hz), the actual clocks are closer to 71700 per frame or 229 per scanline.

As shown by the IO demo, the exact cycles are not stable across machines, which makes it tricky to do splitting effects on an MSX1. IO uses a timing of 228 cycles/line or 71364 per frame, so those are probably the correct numbers on at least some machines.

edit2: Haven’t confirmed yet whether the MSX outputs 312 or 313 lines per frame, so the figures above are just estimates (there are some other possible error sources too). What is known is that the vertical blanking interrupt (VBI) takes place immediately after the last pixel line, not outside the screen. In addition, ideal Z80 cycles are not correct on real machines, as there are additional T-states introduced by memory access.

Filed under: demoskene,retro