Super Nintendo वीडियो सिस्टम डिज़ाइन को समझना
(fabiensanglard.net)- SNES वीडियो को 1990 के शुरुआती दौर के CRT TV और NTSC सिग्नल की सीमाओं के भीतर 256x224 स्क्रीन, 60.098Hz फ़्रेमरेट और blanking interval के हिसाब से डिज़ाइन किया गया था
- CRT पिक्सेल ग्रिड पर नहीं, बल्कि electron gun, RGB सिग्नल और HSYNC/VSYNC के साथ scan line खींचकर काम करता है, और progressive व interlace का अंतर भी sync signal की स्थिति से तय होता है
- अलग video oscillator नहीं रख सकने वाले SNES ने 21.47727MHz master clock को divide करके 5.3693175MHz dot clock बनाया, और 262 lines व 341 dots के संयोजन से NTSC के मानक 59.94Hz से अलग 60.098Hz हासिल किया
- बेसिक मोड में 262 lines में से 224 lines display और 38 lines VBLANK, तथा 341 dots में 256 dots display और 85 dots HBLANK रखे गए ताकि PPU को sprite line buffer पर काम करने का समय मिल सके
- PAL SNES ने 50Hz·312.5-line वातावरण के लिए अलग oscillator और 240-line overscan mode दिया, लेकिन ज़्यादातर गेम 224-line आधार पर बने होने से काली पट्टियाँ और 17% धीमा चलना आम था
जहाँ CRT TV ने डिज़ाइन को सीमित किया
- SNES का वीडियो आउटपुट मूल रूप से मानक CRT TV के लिए था, और उस समय TV या तो antenna से NTSC analog broadcast लेते थे या AUX input से बाहरी वीडियो
- आम TV के auxiliary input में पीले रंग का composite video jack और सफेद-लाल stereo audio jack होते थे
- CRT को लगभग 15,000 lines प्रति सेकंड खींचने वाली 15kHz-क्लास line-drawing device की तरह देखा जा सकता है
CRT पिक्सेल से नहीं, scan line और signal से काम करता है
- CRT के अंदर तीन electron guns होते हैं, और electrons को vertical व horizontal magnet की मदद से ऊपर-नीचे और दाएँ-बाएँ मोड़ा जाता है
- electron का अपना कोई रंग नहीं होता; mask यह सुनिश्चित करता है कि हर electron gun के electrons सही रंग की phosphor strip पर पड़ें
- CRT में pixel नहीं होते, और slot भी pixel नहीं है
- हाई-रेज़ोल्यूशन TV में slot छोटे होते हैं, इसलिए वही color signal horizontal दिशा में अधिक fidelity के साथ दिख सकता है
- CRT पाँच signals को चार तारों से लेता है
- Red, Green, Blue signals सीधे संबंधित electron gun से जुड़े होते हैं
- अगर तीनों RGB lines पर signal न हो, तो electron fire नहीं होते और काला रंग दिखता है
- सफेद तार Composite Sync(CSYNC) है, जो HSYNC और VSYNC दोनों को साथ लेकर चलता है
- CRT खुद VSYNC नहीं बनाता; बाहरी system से आने वाले sync signal के आधार पर electron gun की स्थिति मिलाई जाती है
Progressive और interlace का अंतर
- CRT एक लाइन को बाएँ से दाएँ खींचता है, और HSYNC मिलते ही स्क्रीन के बाएँ X=0 पर लौटता है
- VSYNC मिलते ही ऊपर Y=0 पर वापस जाता है
- electron gun दाएँ बढ़ते समय नीचे की ओर झुके हुए पथ का अनुसरण करता है, इसलिए HSYNC के बाद अगली लाइन पिछली लाइन के नीचे बनती है
- अगर VSYNC आख़िरी HSYNC के ठीक उसी समय आए, तो field उसी स्थान पर बनता है और यह progressive scan होता है
- अगर VSYNC दो HSYNC के बीच आए, तो अगली field की लाइनें पिछली field की लाइनों के बीच में भरती हैं और यह interlace होता है
- interlace vertical resolution को दोगुना कर देता है, लेकिन हर लाइन का refresh rate आधा हो जाता है
- NTSC लगभग 30Hz पर दो fields भेजता है, इसलिए CRT में interlacing के लिए line spacing मौजूद थी; progressive में खींचने पर काली scanline gaps दिखाई देती हैं
NTSC स्पेसिफिकेशन और सरल डिज़ाइन की सीमा
- SNES का डिज़ाइन उन मानों के क़रीब होना था जिन्हें NTSC TV संभाल सके
- aspect ratio: 4:3
- lines per field: 262.5
- dots per line: 341.25
- field frequency: 59.94Hz
- black-and-white NTSC मूल रूप से 60Hz था, लेकिन color NTSC ने backward compatibility रखते हुए artifacts से बचने के लिए frequency को 0.1% घटा दिया
- सरल रूप से 262-line progressive, 350 dots, 59.94Hz चुनकर 5,496,498Hz dot clock की आवश्यकता मानी जा सकती थी
- लेकिन यह डिज़ाइन वास्तविक SNES के लिए उपयुक्त नहीं था
- लागत सीमाओं के कारण video system के लिए अलग oscillator नहीं रखा जा सकता था, और sub-systems को master oscillator को divide करके चलना था
- CRT में स्क्रीन लौटते समय भी electron gun fire कर सकता है, इसलिए overscan और blanking handling ज़रूरी थी
Blanking और vertical resolution का चयन
- जब electron gun की स्थिति horizontal या vertical रूप से reset हो रही हो और वह firing जारी रखे, तो visible artifacts बनते हैं
- TV अक्सर स्क्रीन से थोड़ा बड़ा चित्र दिखाने वाला overscan करते हैं, और इसकी मात्रा TV के अनुसार बदलती है
- VSYNC और HSYNC के बाद electron gun की स्थिति कुछ समय अस्थिर रहती है, इसलिए स्थिर सीधी रेखा बनने तक electron firing रोकने का समय चाहिए
- VSYNC के बाद firing-stop interval को VBLANK कहते हैं
- HSYNC के बाद firing-stop interval को HBLANK कहते हैं
- उस समय की competing systems भी blanking का उपयोग करती थीं
- Capcom CPS-1: 262 lines, VBLANK 38 lines, display 224 lines, 59.6294fps
- Sega Genesis: 262 lines, VBLANK 38 lines, display 224 lines, 59.9227fps
- Neo-Geo AES: 264 lines, VBLANK 40 lines, display 224 lines, 59.18fps
- SNES ने 262 lines को 224 display lines + 38 blank lines में बाँटा
- 224, 16 से पूरा विभाजित होता है, इसलिए 16x16 tile-आधारित graphics pipeline के लिए उपयुक्त था
Horizontal resolution और 60.098Hz
- SNES ने 21.47727MHz master clock को 4 से divide करके 5.3693175MHz dot clock इस्तेमाल किया
- frame rate, line count, dots per line और dot clock आपस में जुड़े हुए हैं
- लक्ष्य 59.94Hz frame rate और 262 lines रखने पर प्रति लाइन लगभग 342 dots आते, लेकिन composite output के carrier artifacts के कारण Nintendo engineers को 341 dots इस्तेमाल करने पड़े
- इस संयोजन में SNES का frame rate 5.3693175MHz / (341 * 262) = 60.098Hz बनता है
- 60.098Hz, NTSC के 59.94Hz से अलग है, लेकिन CRT की tolerance के भीतर काम करता है
256x224 बेसिक स्क्रीन क्यों बनी
- प्रति लाइन 341 dots पूरे के पूरे display area के रूप में इस्तेमाल नहीं किए जा सकते, क्योंकि shake, artifacts और TV overscan छिपाने के लिए HBLANK चाहिए
- 224 lines पर 4:3 के क़रीब display width 224 * 4/3 = 298 dots होती है
- tilemap pipeline 16x16 tiles का उपयोग करती है, इसलिए संभव मान 304, 288, 272, 256, 240 आदि थे
- 304 dots वह मान है जो लगभग बिना distortion के सबसे क़रीब पड़ता है
- PPU को HBLANK के दौरान sprite line buffer भरना होता था, यह भी एक बाधा थी
- अगर 304-dot display चुना जाता, तो HBLANK केवल 37 dots, यानी लगभग 7µs रह जाता
- अधिकतम 128 sprites का data लाने के लिए शायद इससे अधिक समय चाहिए था
- अंत में 256 display dots + 85 HBLANK dots चुने गए
- PPU को HBLANK के दौरान लगभग 16µs मिलते हैं
- display area का aspect ratio 4:3 नहीं बल्कि 8:7 है, इसलिए CRT पर दिखने पर हल्का distortion होता है
हाई-रेज़ोल्यूशन मोड में समझौते
- बेसिक SNES वीडियो कॉन्फ़िगरेशन overscan resolution 341x262, display resolution 256x224, और frame rate 60.098Hz है
- 99% गेम इसी कॉन्फ़िगरेशन का उपयोग करते थे, लेकिन SNES में vertical या horizontal resolution दोगुना करने वाले high-resolution modes भी थे
- 448-line vertical resolution पाने के लिए VSYNC को आख़िरी HSYNC के बाद आधी लाइन की स्थिति पर भेजकर interlace frame बनाया जा सकता था
- इस स्थिति में हर लाइन 60.098/2 = 30.049Hz पर refresh होती है
- इससे flicker आता है और देखने में अच्छा नहीं लगता, लेकिन vertical resolution बढ़ जाती है
- horizontal resolution दोगुना करना अधिक कठिन था क्योंकि आवश्यक dot clock उपलब्ध नहीं था
- SNES दूसरी field को horizontal दिशा में थोड़ा shift करता है ताकि dots पिछली field के dots के बीच आ जाएँ
- नतीजतन आधा frame rate और काफ़ी color bleeding होती है
- fullsnes.txt में कई titles के high-resolution उपयोग के उदाहरण दिए गए हैं
- Donkey Kong Country 1 का Nintendo logo: 512x224, BgMode5
- Seiken Densetsu 2 settings screen: 512x224, BgMode5
- RPM Racing: intro और in-game 512x448, BgMode5+Interlace
- Ranma 1/2 का मामला वास्तव में 256x224 है, लेकिन interlace संयोग से enable होने के कारण अनावश्यक flicker बनती है
PAL, SECAM और यूरोपीय SNES की समस्या
- यूरोपीय TV, NTSC नहीं बल्कि PAL का उपयोग करते थे, और फ़्रांस में SECAM भी चलता था
- PAL वातावरण ठीक 50Hz और प्रति field 312.5 lines की अपेक्षा करता है
- PAL SNES में NTSC के 21.4772700MHz की जगह 17.7344750MHz oscillator लगाया गया
- S-CLK chip 6/5 processing करता है, फिर /4 divide करके 5.32034250MHz dot clock बनाता है
- अगर केवल 224-line graphics का उपयोग किया जाए, तो display area के ऊपर-नीचे बड़ी काली पट्टियाँ बनती हैं
- इसे कम करने के लिए display lines को 240 तक बढ़ाने वाला overscan mode था
- अतिरिक्त 16 lines, एक tile की ऊँचाई के बराबर हैं
- व्यवहार में ज़्यादातर titles 224 lines के हिसाब से बने थे, इसलिए यह mode लगभग उपयोग नहीं हुआ
- कुल केवल 12 titles ने इसका उपयोग किया
- Super Mario World ने PAL में vertical viewing range बढ़ाकर इसका समाधान किया
- NTSC और PAL दोनों 4:3 aspect ratio का उपयोग करते हैं, इसलिए PAL image, NTSC की तुलना में vertical दिशा में थोड़ी अधिक compressed दिखती है
- कई गेम code इस बात को ध्यान में नहीं रख पाए कि VSYNC 50.00697891Hz पर हो रहा है, 60.098Hz पर नहीं, और परिणामस्वरूप गेम इच्छित गति से 17% धीमे चलते थे
Output signal और AV connector
- ऊपर बताए गए RGB और sync signals, CRT को सीधे चलाने वाले raw signals हैं, लेकिन वास्तविकता में अधिकांश TV इन signals को सीधे CRT तक नहीं पहुँचा सकते थे
- कई TV में पीछे सिर्फ पीला composite input होता था, जबकि कुछ high-end models में S-Video input भी मिलता था
- SNES ने CRT वाले signals को composite और S-Video दोनों में convert किया
- AV connector signal को हटाए बिना कई output methods उपलब्ध कराता है
- Red, Green, Blue
- C-Sync
- Luminance और Chrominance आधारित S-Video
- Composite Video
- +5V DC
- Ground
- Left Audio, Right Audio
- यूरोप के TV, ख़ासकर फ़्रांस के TV, में अक्सर SCART connector होता था, जिससे ऐसे cables बनाना संभव हुआ जो signal को CRT तक अधिक सीधे पहुँचा सकें
- नतीजतन यूरोपीय उपयोगकर्ता 17% धीमे और काली पट्टियों वाले गेम को बेहतर video fidelity के साथ खेल सकते थे
1 टिप्पणियां
Hacker News की रायें
224 शायद कोई रैंडम चुना हुआ नंबर नहीं है। यह 16 से पूरी तरह विभाजित होता है (224/16=14), इसलिए graphics rendering pipeline के tilemap के साथ अच्छी तरह फिट बैठता है
बचपन में game programming सीखने के लिए तरह-तरह की चीज़ें छेड़ते हुए मुझे यह बहुत बाद में समझ आया, और तब यह बात काफी तार्किक लगी। CGA/EGA/VGA में 320x200 mode आम था, और NES व SNES 256x224 थे, जो असल में लगभग TV constraints जैसा ही था
दूसरी ओर arcade Pac-Man 288x224 था, इसलिए PC पर बने Pac-Man clones कभी भी “ठीक” नहीं दिखते थे, और Namco द्वारा बनाया गया NES वाला Pac-Man भी फिट नहीं बैठता था। Map tiles छोटे हो जाते और characters विशाल लगते, या Game Boy/Tengen version की तरह scrolling world बन जाता, या distortion और non-original map जैसे समझौते करने पड़ते; इसलिए घर पर “arcade” game खेलने की कोशिश अजीब और खीज पैदा करने वाली लगती थी
मशीन की संरचना और sprites कैसे काम करते हैं यह सीखने के बाद, आखिरकार मैं इस नतीजे पर पहुँचा कि और कोई विकल्प था ही नहीं, और यह मेरे लिए बड़ा एहसास था। अगर इसमें यह तथ्य भी जोड़ दें कि PC की उस resolution में pixels square नहीं थे, तो मामला और जटिल हो जाता है
इसके बाद जब भी मैं Pac-Man ports या clones देखता हूँ, तो तुरंत world size, tile size और sprite size पर ध्यान देने लगता हूँ
हालांकि यह overscan हर TV में अलग था, और modern TV या emulators आम तौर पर पूरी 240 lines दिखाते हैं
SNES की vertical resolution, लेख में बताए अनुसार, 224 lines या 240 lines पर सेट की जा सकती थी। ज़्यादातर games 224 lines इस्तेमाल करते थे, क्योंकि इससे vertical blanking time लंबा हो जाता था और PPU को graphics transfer करने के लिए समय ज़्यादा मिलता था
Rodrigo Copetti का SNES architecture पर लेख भी साथ में पढ़ने लायक है: https://www.copetti.org/writings/consoles/super-nintendo/
59.94Hz का अजीब नंबर होना सही है, लेकिन जहाँ तक मुझे पता है 30Hz power grid कहीं नहीं है। जिन North America और कुछ अन्य क्षेत्रों के लिए NTSC design किया गया था, वहाँ 60Hz power grid इस्तेमाल होती है
https://en.wikipedia.org/wiki/Mains_electricity_by_country
black-and-white TV में generate होने वाली सबसे ऊँची frequency horizontal scan rate थी, जो frame rate का multiple थी। 3.579545MHz carrier wave इस्तेमाल करने वाला NTSC color signal जोड़े जाने पर TV के अंदर की highest frequency काफी बढ़ गई, और hardware को सरल रखने के लिए lower frequencies को अब भी उसी highest frequency, यानी color carrier, के divisors से match किया गया। नतीजतन frame rate प्रति सेकंड 59.94 fields हो गया
PAL क्षेत्रों में गेम्स को 50.00697891Hz VSYNC के हिसाब से संशोधित नहीं किया गया, इसलिए वे 60.098Hz मानक की तुलना में 17% धीमे चलते थे — यह बात बहुत गहराई से महसूस होती है
यह सिर्फ Super Nintendo की बात नहीं है, लेकिन मुझे वह समय याद आता है जब मैंने Mega Drive(Genesis) पर Sonic the Hedgehog पहली बार देखा या खेला था. Master System वर्ज़न की तुलना में वह सुस्त और धीमा लगा, इसलिए खास प्रभावशाली नहीं लगा; YouTube के आने के बाद ही समझ आया कि NTSC और PAL की स्पीड में अंतर कितना बड़ा था. सिर्फ गेम स्पीड नहीं, PAL में संगीत भी बेहद खराब सुनाई देता था
16-bit दौर में भी PAL और “ब्लैक बॉक्स” की ज़रूरत के बारे में पता था, लेकिन अंतर इतना बड़ा है यह नहीं जानता था. उस समय console magazines ज़्यादातर कहती थीं कि गेम्स में अंतर छोटा है; अपवाद के तौर पर SNES वर्ज़न DooM में NTSC वर्ज़न की स्क्रीन बड़ी थी
बचपन में मैं NES वर्ज़न Punch-Out में अच्छा था और Mr. Dream या Mike Tyson को पहले round में हरा सकता था, लेकिन अब सोचता हूं तो मैं PAL वर्ज़न खेल रहा था. अगर मैं किसी अमेरिकी tournament में गया होता तो पहले round में ही बुरी तरह पिट गया होता, और मुझे पूरा यकीन होता कि किसी ने मुझे फंसा दिया है
उदाहरण के लिए, कम frame rate पर Samus और projectiles एक frame में अधिक pixels चलते हैं, इसलिए objects के आर-पार जाना आसान हो जाता है; यह gate glitch सिर्फ PAL में संभव है: https://www.youtube.com/watch?v=RvyIwtO_qgM
Samus के physics constants और animation timing को नए frame rate के हिसाब से adjust किया गया था, लेकिन enemies, cutscenes और अन्य environment elements को adjust नहीं किया गया. इसलिए PAL में Samus NTSC जैसी ही speed से चलती है, लेकिन बाकी दुनिया धीमी चलती है. इसी वजह से Bombs उठाकर दरवाज़ा lock होने से ठीक पहले room से बाहर निकला जा सकता है और miniboss को skip किया जा सकता है: https://www.youtube.com/watch?v=R3t8TIIj7IM
NTSC वर्ज़न में वही skip करने के लिए जटिल तैयारी और लगातार दर्जनों frame-perfect inputs चाहिए होते हैं, और अब तक सिर्फ एक व्यक्ति ने इसे सफल किया है: https://www.youtube.com/watch?v=jcKUMk5g8Wk
NTSC(बाएं) और PAL(दाएं) के सबसे छोटे tool-assisted speedrun की comparison भी है: https://www.youtube.com/watch?v=KD_-thqcB5s दोनों runs लगभग अंत तक एक ही route इस्तेमाल करते हैं और NTSC वर्ज़न लगभग हर room में तेज़ है, लेकिन arbitrary code execution की तैयारी पूरी तरह अलग है, इसलिए PAL अंत में पहले finish करता है. NTSC run में door को activate किए बिना उसके पार जाकर bounds से बाहर निकलना और memory corruption करवाने के लिए बहुत धीमी pause/unpause sequence करनी पड़ती है. दूसरी ओर PAL वर्ज़न game animation system की race condition का उपयोग करके पूरी तरह screen के अंदर ही arbitrary code execution हासिल कर सकता है. यह spikes के knockback timer और Samus के landing animation के बीच की race है; सिर्फ Samus की timing PAL के लिए संशोधित की गई और spikes की नहीं, इसलिए PAL में इसी context में exploit की जा सकने वाली timing बनती है
Dreamcast आने पर पहली बार ऐसे games आए जिनमें TV support करे तो 50Hz और 60Hz के बीच switch किया जा सकता था. और जिन games ने इस difference को ठीक से reflect नहीं किया था, उन्हें 50Hz पर वापस करके आसान भी बनाया जा सकता था; मुझे याद है Crazy Taxi 50Hz पर कहीं ज्यादा आसान था
इतना अलग game वैसे ही बेचा गया, यह अजीब लगता है, लेकिन यह पूरी तरह समझ आता है कि ऐसा फैसला क्यों लिया गया. बचपन में मैं स्वाभाविक रूप से मानता था कि Mario हर जगह Mario है और Sonic भी हर जगह Sonic है
सोचता हूं कि क्या ऐसे differences 3D console दौर में खत्म हुए. क्योंकि तब से rendering और game logic ज़्यादातर पूरी तरह tied together नहीं रह गए थे
लगता है मूल लेख में typo है. Aspect ratio को 8:6 कहा गया है, लेकिन वह 4:3 के बराबर है, और calculation के हिसाब से 8:7 सही है
लगता है 256x224, यानी 8:7 output resolution, को लगभग 4:3 — सटीक रूप से 64:49 image — में stretch होने वाला हिस्सा छूट गया है
SNES की dot speed लगभग 5.37MHz है, जो ATSC standard द्वारा define की गई square pixel speed लगभग 6.13MHz से धीमी है. यह ठीक 8/7 गुना धीमी है, इसलिए pixels horizontally 8/7 stretch होते हैं, और 8:7 resolution (8/7)(8/7)=64/49 तक stretch होकर 64:48=4:3 के करीब हो जाता है
“4:3 के करीब aspect ratio बनने के लिए 224(4/3)=298 visible dots चाहिए” वाली calculation में, ऊपर के factor को ध्यान में रखें तो coefficient (4/3)/(8/7)=7/6 बनता है. तब 224*(7/6)=261.33... visible dots चाहिए होते हैं, जो वास्तव में चुने गए 256 के कहीं ज्यादा करीब है
मैं RF output में switch box लगाकर SNES और TV antenna को बारी-बारी से select करके इस्तेमाल करता था
बाद में video engineer बनने के बाद मैं इस पर हंस सका, लेकिन उस समय के बच्चे के रूप में मुझे यह नहीं पता था कि वह image quality कितनी भयानक थी — यह अच्छी बात थी
8:7 artwork aspect ratio ROCKMANX3 / Mega Man X3 जैसे SFC/SNES के दूसरे platform ports में भी दिखता है
PSX/Saturn/PC versions ने original art को stretch किए बिना बनाए रखा, लेकिन 8:7 को 4:3 में फिट करने के लिए stages के हिसाब से vertical margins जोड़े। Original version की आदत होने की वजह से खेलते समय यह काफ़ी खटकता है, और Saturn version के screenshots देखने पर पता चलता है कि सब कुछ थोड़ा ज़्यादा दुबला दिखता है: https://segaretro.org/Mega_Man_X3
सोचता हूँ Fabien को ऐसे लेख लिखने में कितना समय लगता होगा। Details सच में बहुत ज़्यादा हैं और organization काफ़ी साफ़-सुथरी है
SNES resolution का कितना हिस्सा console hardware में fixed है, और कितना cartridge द्वारा driven किया जा सकने वाला area है, यह जानने की उत्सुकता है
उदाहरण के लिए, अगर किसी cartridge में अपना co-processor हो, जिससे sprites load करने की ज़रूरत न पड़े, और onboard clock भी हो, तो क्या theoretically एक line में horizontal 256 pixels से ज़्यादा output किया जा सकता था?
co-processor होने पर वह खुद frame render करके उसे उस memory location में डाल सकता है जहाँ अगली line की tiles पढ़ी जाएँगी। SuperFX ने शायद लगभग यही किया था
लेकिन आखिरकार pixels draw करना और color count वगैरह handle करना PPU ही करता है, इसलिए final output PPU की constraints से बंधा रहता है