Memahami Desain Sistem Video Super Nintendo
(fabiensanglard.net)- Video SNES dirancang dalam batasan TV CRT dan sinyal NTSC pada awal 1990-an, dengan layar 256x224, frame rate 60,098Hz, serta interval blanking yang disesuaikan
- CRT bukanlah kisi piksel; ia menggambar garis pindai dengan electron gun, sinyal RGB, dan HSYNC/VSYNC. Perbedaan antara progressive dan interlace juga ditentukan oleh posisi sinyal sinkronisasi
- Karena SNES tidak dapat memiliki osilator video terpisah, ia membagi master clock 21,47727MHz untuk membuat dot clock 5,3693175MHz, lalu dengan kombinasi 262 baris dan 341 dot mencapai 60,098Hz, berbeda dari standar NTSC 59,94Hz
- Mode dasar terdiri dari 224 baris tampilan dari total 262 baris dan 38 baris VBLANK, serta 256 dot tampilan dari total 341 dot dan 85 dot HBLANK, sehingga memberi waktu bagi PPU untuk mengerjakan sprite line buffer
- PAL SNES menyediakan osilator berbeda dan mode overscan 240 baris agar sesuai dengan lingkungan 50Hz dan 312,5 baris, tetapi karena sebagian besar game berbasis 224 baris, pita hitam dan eksekusi 17% lebih lambat menjadi hal umum
Titik ketika TV CRT membatasi desain
- Target utama keluaran video SNES adalah TV CRT standar, dan TV saat itu menerima siaran analog NTSC melalui antena atau video eksternal melalui input AUX
- Input tambahan pada TV umum terdiri dari konektor composite video kuning serta konektor audio stereo putih dan merah
- CRT dapat dipandang sebagai perangkat penggambar garis kelas 15kHz yang mampu menggambar sekitar 15.000 garis per detik
CRT bekerja dengan garis pindai dan sinyal, bukan piksel
- Di dalam CRT terdapat tiga electron gun, dan elektron dibelokkan ke atas-bawah serta kiri-kanan oleh magnet vertikal dan horizontal
- Elektron itu sendiri tidak memiliki warna; mask memastikan elektron dari tiap electron gun mengenai strip fosfor warna yang benar
- CRT tidak memiliki piksel, dan slot juga bukan piksel
- TV beresolusi tinggi memiliki slot yang lebih kecil sehingga dapat merepresentasikan sinyal warna yang sama secara lebih akurat pada arah horizontal
- CRT menerima lima sinyal melalui empat kabel
- Sinyal Red, Green, Blue masing-masing terhubung langsung ke electron gun
- Jika tidak ada sinyal pada tiga kabel RGB, elektron tidak ditembakkan sehingga warna hitam ditampilkan
- Kabel putih adalah Composite Sync(CSYNC) yang membawa HSYNC dan VSYNC sekaligus
- CRT tidak membuat VSYNC; ia menerima sinyal sinkronisasi yang dikirim sistem eksternal untuk menyelaraskan posisi electron gun
Perbedaan progressive dan interlace
- CRT menggambar satu baris dari kiri ke kanan, lalu ketika menerima HSYNC, kembali ke sisi kiri layar pada X=0
- Ketika menerima VSYNC, ia kembali ke bagian atas layar pada Y=0
- Saat electron gun bergerak ke kanan, ia mengikuti jalur yang miring ke bawah, sehingga baris berikutnya setelah HSYNC digambar di bawah baris sebelumnya
- Jika VSYNC terjadi pada saat yang sama dengan HSYNC terakhir, field digambar di posisi yang sama dan menjadi pemindaian progressive
- Jika VSYNC terjadi di antara dua HSYNC, garis-garis field berikutnya masuk di sela-sela field sebelumnya dan menjadi interlace
- Interlace menggandakan resolusi vertikal, tetapi refresh rate tiap baris turun menjadi setengahnya
- NTSC mengirimkan dua field pada sekitar 30Hz, sehingga CRT menyediakan jarak antargaris untuk interlacing; ketika digambar secara progressive, terlihat celah scanline hitam
Spesifikasi NTSC dan batasan rancangan sederhana
- Desain SNES harus mendekati nilai yang dapat diproses TV NTSC
- Rasio aspek: 4:3
- Jumlah baris per field: 262,5
- Jumlah dot per baris: 341,25
- Frekuensi field: 59,94Hz
- NTSC hitam-putih awalnya 60Hz, tetapi NTSC warna menurunkan frekuensi sebesar 0,1% dalam proses menambahkan warna sambil mempertahankan kompatibilitas mundur untuk menghindari artefak
- Secara sederhana, bisa saja dipilih progressive 262 baris, 350 dot, dan 59,94Hz, yang membutuhkan dot clock 5.496.498Hz
- Namun desain ini tidak cocok untuk SNES sebenarnya
- Karena batasan biaya, tidak bisa ada osilator khusus untuk sistem video, dan subsistem harus memakai hasil pembagian dari master oscillator
- CRT dapat terus menembakkan elektron bahkan saat layar kembali ke posisi awal, sehingga diperlukan overscan dan pemrosesan blanking
Blanking dan pemilihan resolusi vertikal
- Jika elektron terus ditembakkan saat posisi electron gun di-reset secara horizontal atau vertikal, artefak yang terlihat akan muncul
- TV melakukan overscan, yaitu menampilkan gambar yang sedikit lebih besar daripada layar, dan tingkatnya berbeda-beda pada tiap TV
- Setelah VSYNC dan HSYNC, posisi electron gun sempat bergetar, sehingga diperlukan waktu untuk menghentikan penembakan elektron sampai garis lurus yang stabil diperoleh
- Interval penghentian penembakan elektron setelah VSYNC adalah VBLANK
- Interval penghentian penembakan elektron setelah HSYNC adalah HBLANK
- Sistem pesaing pada masa itu juga menggunakan blanking
- Capcom CPS-1: 262 baris, VBLANK 38 baris, tampilan 224 baris, 59,6294fps
- Sega Genesis: 262 baris, VBLANK 38 baris, tampilan 224 baris, 59,9227fps
- Neo-Geo AES: 264 baris, VBLANK 40 baris, tampilan 224 baris, 59,18fps
- SNES membagi 262 baris menjadi 224 baris tampilan + 38 baris blank
- 224 habis dibagi 16, sehingga cocok dengan pipeline grafis berbasis tile 16x16
Resolusi horizontal dan 60,098Hz
- SNES membagi master clock 21,47727MHz dengan 4 dan menggunakan dot clock 5,3693175MHz
- Frame rate, jumlah baris, jumlah dot per baris, dan dot clock saling terhubung
- Jika memasukkan target frame rate 59,94Hz dan 262 baris, hasilnya sekitar 342 dot per baris, tetapi karena artefak carrier pada keluaran composite, engineer Nintendo harus menggunakan 341 dot
- Dengan kombinasi ini, frame rate SNES menjadi 5,3693175MHz / (341 * 262) = 60,098Hz
- 60,098Hz berbeda dari 59,94Hz milik NTSC, tetapi bekerja dalam rentang toleransi CRT
Mengapa layar dasar menjadi 256x224
- Tidak mungkin memakai seluruh 341 dot dalam satu baris sebagai area tampilan; diperlukan HBLANK untuk menyembunyikan guncangan, artefak, dan overscan TV
- Lebar tampilan yang mendekati 4:3 pada 224 baris adalah 224 * 4/3 = 298 dot
- Pipeline tilemap memakai tile 16x16, sehingga nilai yang mungkin adalah 304, 288, 272, 256, 240, dan seterusnya
- 304 dot adalah nilai yang mendekati tanpa distorsi layar berarti
- Ada juga batasan bahwa PPU harus mengisi sprite line buffer selama HBLANK
- Jika memilih tampilan 304 dot, HBLANK hanya 37 dot, sekitar 7µs
- Kemungkinan diperlukan waktu lebih panjang untuk mengambil data hingga 128 sprite
- Pilihan akhirnya adalah 256 dot tampilan + 85 dot HBLANK
- PPU memperoleh sekitar 16µs selama HBLANK
- Rasio aspek area tampilan bukan 4:3 melainkan 8:7, sehingga muncul sedikit distorsi saat ditampilkan di CRT
Kompromi mode resolusi tinggi
- Konfigurasi video dasar SNES adalah resolusi overscan 341x262, resolusi tampilan 256x224, dan frame rate 60,098Hz
- 99% game menggunakan konfigurasi ini, tetapi SNES juga memiliki mode resolusi tinggi yang menggandakan resolusi vertikal atau horizontal
- Resolusi vertikal 448 baris dapat dibuat dengan mengirim VSYNC pada titik setengah baris setelah HSYNC terakhir untuk membuat frame interlace
- Dalam kasus ini, satu baris diperbarui pada 60,098/2 = 30,049Hz
- Terjadi flicker dan tampilannya kurang baik, tetapi resolusi vertikal meningkat
- Menggandakan resolusi horizontal lebih sulit karena tidak ada dot clock yang dibutuhkan
- SNES menggeser field kedua sedikit secara horizontal agar titik-titiknya berada di antara titik-titik field sebelumnya
- Hasilnya adalah frame rate setengah dan color bleeding yang besar
- fullsnes.txt merangkum contoh penggunaan resolusi tinggi di berbagai judul
- Logo Nintendo di Donkey Kong Country 1: 512x224, BgMode5
- Layar pengaturan Seiken Densetsu 2: 512x224, BgMode5
- RPM Racing: intro dan dalam game 512x448, BgMode5+Interlace
- Kasus Ranma 1/2 sebenarnya 256x224, tetapi interlace tidak sengaja aktif sehingga menimbulkan flicker yang tidak perlu
PAL, SECAM, dan masalah SNES versi Eropa
- TV Eropa menggunakan PAL, bukan NTSC, dan Prancis juga menggunakan SECAM
- Lingkungan PAL mengharapkan tepat 50Hz dan 312,5 baris per field
- PAL SNES memasang osilator 17,7344750MHz, bukan 21,4772700MHz milik NTSC
- Chip S-CLK melakukan pemrosesan 6/5, lalu dibagi lagi /4 untuk membuat dot clock 5,32034250MHz
- Jika hanya memakai grafis 224 baris, muncul pita hitam besar di atas dan bawah area tampilan
- Untuk menguranginya, tersedia mode overscan yang menambah baris tampilan menjadi 240
- Tambahan 16 baris setara dengan tinggi satu tile
- Dalam praktiknya, sebagian besar judul dibuat untuk 224 baris sehingga mode ini hampir tidak digunakan
- Hanya total 12 judul yang menggunakannya
- Super Mario World menanganinya dengan memperluas jangkauan pandang vertikal pada PAL
- Karena NTSC dan PAL sama-sama memakai rasio aspek 4:3, gambar PAL sedikit lebih terkompresi secara vertikal dibanding NTSC
- Banyak kode game tidak memperhitungkan bahwa VSYNC terjadi pada 50,00697891Hz, bukan 60,098Hz, sehingga game berjalan 17% lebih lambat dari yang dimaksudkan
Sinyal keluaran dan konektor AV
- Sinyal RGB dan sinkronisasi yang dibahas sebelumnya adalah sinyal murni untuk menggerakkan CRT secara langsung, tetapi sebagian besar TV sebenarnya tidak bisa menerima sinyal langsung ke CRT
- Banyak TV hanya memiliki input composite kuning di bagian belakang, dan beberapa model kelas atas menyediakan input S-Video
- SNES mengonversi sinyal untuk CRT menjadi composite dan S-Video
- Konektor AV menyediakan beberapa metode keluaran tanpa membuang sinyal
- Red, Green, Blue
- C-Sync
- S-Video berbasis Luminance dan Chrominance
- Composite Video
- +5V DC
- Ground
- Left Audio, Right Audio
- TV Eropa, terutama TV Prancis, sering memiliki konektor SCART, dan metode ini memungkinkan pembuatan kabel yang memasukkan sinyal ke CRT secara lebih langsung
- Akibatnya, pengguna Eropa dapat menikmati game yang 17% lebih lambat dan memiliki pita hitam dengan fidelitas gambar yang tinggi
1 komentar
Komentar Hacker News
224 kemungkinan besar bukan angka yang dipilih secara acak. Angka itu habis dibagi 16 (224/16=14), sehingga cocok dengan tilemap dalam pipeline rendering grafis
Saat kecil, ketika mencoba belajar pemrograman game dan mengutak-atik berbagai hal, saya baru memahaminya jauh belakangan, dan saat itu semuanya terasa sangat masuk akal. Pada CGA/EGA/VGA, mode 320x200 umum digunakan, sementara NES dan SNES memakai 256x224, yang pada dasarnya lebih merupakan batasan TV
Sebaliknya, arcade Pac-Man memakai 288x224, sehingga klon Pac-Man di PC tidak pernah terlihat “benar”, dan bahkan Pac-Man versi NES buatan Namco pun tidak pas. Tile peta menjadi lebih kecil sehingga karakter terlihat raksasa, atau dunianya menjadi bergulir seperti versi Game Boy/Tengen, atau ada kompromi seperti distorsi dan peta yang tidak orisinal, sehingga saat mencoba memainkan game “arcade” di rumah rasanya aneh dan membuat frustrasi
Setelah mempelajari struktur mesin dan cara kerja sprite, saya mendapat pencerahan besar ketika akhirnya sampai pada kesimpulan bahwa memang tidak ada pilihan lain. Jika ditambah fakta bahwa pada resolusi PC tersebut pikselnya bukan persegi, masalahnya jadi lebih rumit lagi
Sejak itu, setiap kali melihat port atau klon Pac-Man, saya langsung memperhatikan ukuran dunia, ukuran tile, dan ukuran sprite
Namun overscan ini berbeda-beda antar-TV, dan TV modern atau emulator biasanya menampilkan seluruh 240 baris
Resolusi vertikal SNES dapat diatur ke 224 baris atau 240 baris seperti disebutkan dalam artikel. Sebagian besar game memakai 224 baris karena waktu vertical blanking menjadi lebih panjang, sehingga ada lebih banyak waktu untuk mentransfer grafis ke PPU
Tulisan Rodrigo Copetti tentang arsitektur SNES juga layak dibaca: https://www.copetti.org/writings/consoles/super-nintendo/
Benar bahwa 59,94Hz adalah angka yang aneh, tetapi sejauh yang saya tahu tidak ada jaringan listrik 30Hz. Amerika Utara dan beberapa wilayah lain tempat NTSC dirancang menggunakan jaringan listrik 60Hz
https://en.wikipedia.org/wiki/Mains_electricity_by_country
Frekuensi tertinggi yang dihasilkan pada TV hitam-putih adalah laju pemindaian horizontal, yang merupakan kelipatan dari frame rate. Ketika sinyal warna NTSC dengan carrier 3,579545MHz ditambahkan, frekuensi tertinggi di dalam TV menjadi jauh lebih tinggi, dan untuk menjaga perangkat keras tetap sederhana, frekuensi-frekuensi yang lebih rendah tetap diselaraskan sebagai pembagi dari frekuensi tertinggi tersebut, yaitu carrier warna. Hasilnya, frame rate menjadi 59,94 field per detik
Bagian tentang game di wilayah PAL yang tidak disesuaikan ke VSYNC 50.00697891Hz sehingga berjalan 17% lebih lambat daripada acuan 60.098Hz benar-benar terasa dekat
Ini bukan cuma soal Super Nintendo, tetapi mengingatkan saya pada saat pertama kali melihat atau memainkan Sonic the Hedgehog di Mega Drive (Genesis). Rasanya lebih loyo dan lambat dibanding versi Master System, jadi tidak terlalu mengesankan; baru setelah YouTube populer saya sadar bahwa perbedaan kecepatan antara NTSC dan PAL itu sangat besar. Bukan hanya kecepatan game, musiknya juga terdengar mengerikan di PAL
Pada era 16-bit pun saya tahu soal PAL dan perlunya “black box”, tetapi tidak tahu perbedaannya sebesar itu. Seingat saya, majalah konsol saat itu kebanyakan bilang perbedaannya kecil di sebagian besar game; pengecualiannya DooM versi SNES, yang layar versi NTSC-nya lebih besar
Waktu kecil saya cukup jago Punch-Out versi NES sampai bisa mengalahkan Mr. Dream atau Mike Tyson di ronde pertama, tetapi kalau dipikir sekarang, saya ternyata memainkan versi PAL. Kalau ikut turnamen di AS, saya pasti dihancurkan di ronde pertama, dan mungkin akan yakin ada yang menjebak saya
Misalnya, pada frame rate yang lebih rendah, Samus dan proyektil bergerak lebih banyak piksel dalam satu frame sehingga lebih mudah menembus objek; glitch gerbang ini hanya mungkin di PAL: https://www.youtube.com/watch?v=RvyIwtO_qgM
Konstanta fisika dan timing animasi Samus disesuaikan untuk frame rate baru, tetapi musuh, cutscene, dan elemen lingkungan lain tidak. Jadi di PAL, Samus bergerak dengan kecepatan yang sama seperti NTSC, sementara dunia lainnya bergerak lebih lambat. Karena itu, pemain bisa mengambil Bombs lalu keluar dari ruangan tepat sebelum pintu terkunci dan melewati miniboss: https://www.youtube.com/watch?v=R3t8TIIj7IM
Skip yang sama di versi NTSC membutuhkan persiapan rumit dan puluhan input berurutan setingkat frame, dan sejauh ini baru satu orang yang berhasil melakukannya: https://www.youtube.com/watch?v=jcKUMk5g8Wk
Ada juga perbandingan speedrun tool-assisted tercepat antara NTSC (kiri) dan PAL (kanan): https://www.youtube.com/watch?v=KD_-thqcB5s Kedua run memakai rute yang hampir sama sampai nyaris akhir, dan versi NTSC lebih cepat di hampir semua ruangan, tetapi persiapan arbitrary code execution-nya sama sekali berbeda sehingga PAL akhirnya selesai lebih dulu. Run NTSC harus melakukan urutan pause/unpause yang sangat lambat untuk melewati pintu tanpa mengaktifkannya, keluar dari batas, lalu menyebabkan korupsi memori. Sebaliknya, versi PAL bisa mencapai arbitrary code execution sepenuhnya di dalam layar dengan memanfaatkan race condition pada sistem animasi game. Ini adalah race antara timer knockback dari spike dan animasi mendarat Samus; hanya timing Samus yang diperbaiki untuk PAL sementara spike tidak, sehingga di PAL muncul timing yang hanya bisa dieksploitasi dalam konteks ini
Saat Dreamcast muncul, untuk pertama kalinya ada game yang memungkinkan beralih antara 50Hz dan 60Hz asalkan TV mendukungnya. Pada game yang tidak mencerminkan perbedaan ini dengan benar, kita juga bisa mengembalikannya ke 50Hz agar menjadi lebih mudah; seingat saya Crazy Taxi jauh lebih mudah di 50Hz
Rasanya aneh game yang sebegitu berbeda dijual begitu saja, tetapi saya sepenuhnya mengerti kenapa pilihan itu diambil. Waktu kecil, saya menganggap sudah pasti Mario adalah Mario di mana pun, dan Sonic juga Sonic di mana pun
Saya penasaran apakah perbedaan seperti ini berakhir pada era konsol 3D. Sejak saat itu, rendering dan logika game sebagian besar tidak lagi terikat sepenuhnya
Sepertinya ada salah ketik di teks asli. Rasio aspek disebut 8:6, padahal itu sama dengan 4:3, dan menurut perhitungan seharusnya 8:7
Sepertinya bagian bahwa 256x224, yaitu resolusi output 8:7, direntangkan menjadi sekitar 4:3, tepatnya gambar 64:49, terlewat
Dot clock SNES sekitar 5,37MHz, lebih lambat daripada kecepatan piksel persegi sekitar 6,13MHz yang didefinisikan standar ATSC. Tepatnya lebih lambat sebesar 8/7, sehingga piksel melebar secara horizontal sebesar 8/7, dan resolusi 8:7 direntangkan menjadi (8/7)(8/7)=64/49, mendekati 64:48=4:3
Perhitungan “agar rasio aspek mendekati 4:3, diperlukan 224(4/3)=298 dot yang terlihat” menjadi memiliki faktor (4/3)/(8/7)=7/6 jika unsur di atas diperhitungkan. Maka diperlukan 224*(7/6)=261,33... dot yang terlihat, jauh lebih dekat dengan 256 yang benar-benar dipilih
Saya memakai switch box pada output RF untuk bergantian memilih antara SNES dan antena TV
Setelah kemudian menjadi insinyur video, saya bisa menertawakannya, tetapi untungnya saya yang masih kecil saat itu tidak tahu seberapa mengerikan kualitas gambar tersebut
Rasio aspek artwork 8:7 juga terlihat pada port ke platform lain dari SFC/SNES seperti ROCKMANX3 / Mega Man X3
Versi PSX/Saturn/PC mempertahankan artwork asli tanpa merenggangkannya, tetapi untuk menyesuaikan 8:7 ke 4:3, mereka menambahkan margin vertikal yang disesuaikan dengan stage. Karena terbiasa dengan versi aslinya, ini cukup mengganggu saat dimainkan, dan jika melihat screenshot versi Saturn, bisa dilihat semuanya tampak sedikit terlalu kurus: https://segaretro.org/Mega_Man_X3
Penasaran berapa lama Fabien menulis artikel seperti ini. Detailnya sangat banyak dan penyusunannya rapi
Penasaran seberapa banyak dari resolusi SNES yang tetap di hardware konsol, dan seberapa banyak yang merupakan area yang bisa digerakkan oleh cartridge
Misalnya, jika ada cartridge yang punya koprosesor sendiri sehingga tidak perlu memuat sprite, dan juga punya clock onboard, secara teori apakah ia bisa mengeluarkan lebih dari 256 piksel horizontal per baris?
Dengan koprosesor, ia bisa merender frame sendiri lalu menaruhnya di lokasi memori tempat tile baris berikutnya akan dibaca. Seingat saya SuperFX kurang lebih melakukan hal seperti itu
Namun pada akhirnya yang benar-benar menggambar piksel dan menangani jumlah warna, dll. adalah PPU, jadi hasil akhirnya tetap terikat pada batasan PPU