पायथन का उपयोग करके सुपर मारियो ब्रोस से स्तरों को पुनः प्राप्त करना

परिचय

एक नए प्रोजेक्ट के लिए, मुझे 1985 के क्लासिक वीडियो गेम सुपर मारियो ब्रोस (एसएमबी) से स्तरीय डेटा निकालने की आवश्यकता थी। अधिक विशेष रूप से, मैं एक इंटरफ़ेस, चलती स्प्राइट्स आदि के बिना खेल के प्रत्येक स्तर के पृष्ठभूमि ग्राफिक्स को निकालना चाहता था।

बेशक, मैं बस खेल से छवियों को गोंद कर सकता हूं और संभवतः, मशीन विजन तकनीकों का उपयोग करके प्रक्रिया को स्वचालित कर सकता हूं। लेकिन यह मुझे नीचे वर्णित विधि से अधिक दिलचस्प लग रहा था, जो आपको उन स्तर तत्वों का पता लगाने की अनुमति देता है जो स्क्रीनशॉट का उपयोग करके प्राप्त नहीं किया जा सकता है।

परियोजना के पहले चरण में, हम 6502 कोडांतरक भाषा और पायथन में लिखित एक एमुलेटर सीखेंगे। पूर्ण स्रोत कोड यहां उपलब्ध है ।

स्रोत कोड विश्लेषण

किसी भी कार्यक्रम का रिवर्स इंजीनियरिंग बहुत सरल है यदि आपके पास इसका स्रोत कोड है, और हमारे पास डॉपेलगैंगर द्वारा प्रकाशित कोडांतरक कोड 6502 (एनईएस प्रोसेसर) की 17 हजार लाइनों के रूप में एसएमबी स्रोत हैं। चूंकि निंटेंडो ने कभी आधिकारिक स्रोत जारी नहीं किया, इसलिए एसएमबी मशीन कोड को अलग करके, प्रत्येक भाग के अर्थ को स्पष्ट रूप से परिभाषित करते हुए, टिप्पणियों और सार्थक प्रतीकात्मक नामों को जोड़कर कोड बनाया गया था।

फ़ाइल पर त्वरित खोज करने के बाद, मुझे उस स्तर के डेटा के समान कुछ मिला जिसकी हमें आवश्यकता थी:

;level 1-1
L_GroundArea6:
.db $50, $21
.db $07, $81, $47, $24, $57, $00, $63, $01, $77, $01
.db $c9, $71, $68, $f2, $e7, $73, $97, $fb, $06, $83
.db $5c, $01, $d7, $22, $e7, $00, $03, $a7, $6c, $02
.db $b3, $22, $e3, $01, $e7, $07, $47, $a0, $57, $06
.db $a7, $01, $d3, $00, $d7, $01, $07, $81, $67, $20
.db $93, $22, $03, $a3, $1c, $61, $17, $21, $6f, $33
.db $c7, $63, $d8, $62, $e9, $61, $fa, $60, $4f, $b3
.db $87, $63, $9c, $01, $b7, $63, $c8, $62, $d9, $61
.db $ea, $60, $39, $f1, $87, $21, $a7, $01, $b7, $20
.db $39, $f1, $5f, $38, $6d, $c1, $af, $26
.db $fd

यदि आप असेंबलर से अपरिचित हैं, तो मैं समझाता हूँ: यह सब बस इसका अर्थ है "संकलित प्रोग्राम में इस तरह के बाइट्स को सम्मिलित करें, और फिर प्रोग्राम के अन्य भागों को L_GroundArea6 प्रतीक का उपयोग करके इसे संदर्भित करने की अनुमति दें"। आप इस टुकड़े को एक सरणी के रूप में ले सकते हैं जिसमें प्रत्येक तत्व एक बाइट है।

पहली चीज़ जो आप देख सकते हैं कि डेटा की मात्रा बहुत कम (लगभग 100 बाइट्स) है। इसलिए, हम सभी प्रकार के कोडिंग को बाहर करते हैं, जिससे आप मनमाने ढंग से ब्लॉक स्तर पर रख सकते हैं। थोड़ा खोज करने के बाद, मैंने पाया कि यह डेटा एरियापार्सरकोर में पढ़ा (कई अप्रत्यक्ष रूप से संबोधित करने के बाद) है। यह उपप्रक्रिया, बदले में, कई अन्य उपप्रक्रियाओं को कॉल करती है, अंततः प्रत्येक प्रकार की वस्तु के लिए विशिष्ट उपप्रक्रमों को बुलाती है जो दृश्य में मान्य होती हैं (उदाहरण के लिए, StaircaseObject , VerticalPipe , RowOfBricks ):


AreaParserCore लिए AreaParserCore कॉल ग्राफ़

यह प्रक्रिया MetatileBuffer को MetatileBuffer : एक 13-बाइट मेमोरी अनुभाग, जो एक स्तर में ब्लॉक का एक कॉलम है, जिसमें से प्रत्येक बाइट एक अलग ब्लॉक का प्रतिनिधित्व करता है। एक मेटास्टाइल एक 16x16 ब्लॉक है जिसमें से SMB गेम की पृष्ठभूमि बनाई जाती है:


आयतों के साथ स्तर मेटाटाइल्स के चारों ओर घूमता है

उन्हें मेटा-फाइलें कहा जाता है, क्योंकि प्रत्येक में चार 8x8-पिक्सेल टाइलें होती हैं, लेकिन इसके नीचे और भी बहुत कुछ।

यह तथ्य कि डिकोडर पूर्वनिर्धारित वस्तुओं के साथ काम करता है, स्तर के छोटे आकार की व्याख्या करता है: स्तर डेटा को केवल वस्तुओं के प्रकार और उनके स्थान का उल्लेख करना चाहिए, उदाहरण के लिए, "बिंदु पर पाइप (20, 16), बिंदु पर ब्लॉक की संख्या (10, 5), ... "। हालांकि, इसका मतलब है कि कच्चे स्तर के डेटा को मेटा फ़ाइलों में बदलने के लिए बहुत सारे कोड लगते हैं।

अपने स्तर के अनपैकर को बनाने के लिए कोड की इस राशि को पोर्ट करने में बहुत अधिक समय लगेगा, इसलिए आइए एक अलग दृष्टिकोण का प्रयास करें।

py65emu

यदि हमारे पास पायथन और 6502 असेंबलर भाषा के बीच एक इंटरफ़ेस था, तो हम प्रत्येक स्तर के कॉलम के लिए AreaParserCore को कॉल कर सकते हैं, और फिर ब्लॉक की जानकारी को वांछित छवि में बदलने के लिए अधिक समझने योग्य पायथन का उपयोग कर सकते हैं।

तब py65emu दृश्य पर दिखाई देता है - पायथन इंटरफ़ेस के साथ एक संक्षिप्त 6502 एमुलेटर। यहाँ बताया गया है कि NES के अनुसार py65emu में समान मेमोरी कॉन्फ़िगरेशन कैसे कॉन्फ़िगर किया गया है:

  from py65emu.cpu import CPU from py65emu.mmu import MMU #  ROM  (..  ) with open("program.bin", "rb") as f: prg_rom = f.read() #   . mmu = MMU([ #  2K ,    0x0. (0x0, 2048, False, []), #  ROM   0x8000. (0x8000, len(prg_rom), True, list(prg_rom)) ]) #     ,       0x8000 cpu = CPU(mmu, 0x8000) 

उसके बाद, हम cpu.step() विधि का उपयोग करके व्यक्तिगत निर्देशों को निष्पादित कर सकते हैं, cpu.step() का उपयोग करके मेमोरी की जांच कर cpu.ra , cpu.r.pc , cpu.r.pc , आदि का उपयोग करके मशीन रजिस्टरों का अध्ययन कर cpu.ra । इसके अलावा, हम mmu.write() का उपयोग करके मेमोरी में लिख सकते हैं।

यह ध्यान देने योग्य है कि यह सिर्फ एक एनईएस प्रोसेसर एमुलेटर है: यह अन्य हार्डवेयर, जैसे कि पीपीयू (पिक्चर प्रोसेसिंग यूनिट) का अनुकरण नहीं करता है, इसलिए इसका उपयोग पूरे गेम का अनुकरण करने के लिए नहीं किया जा सकता है। हालांकि, पार्सिंग सबप्रोसेसर को कॉल करने के लिए पर्याप्त होना चाहिए, क्योंकि यह सीपीयू और मेमोरी के अलावा किसी अन्य हार्डवेयर डिवाइस का उपयोग नहीं करता है।

सीपीयू को ऊपर दिखाए अनुसार कॉन्फ़िगर करने की योजना है, और फिर प्रत्येक स्तर के कॉलम के लिए, मेमोरी पार्टिशन को AreaParserCore लिए आवश्यक इनपुट वैल्यू के साथ आरंभीकृत करें, AreaParserCore को कॉल करें, और फिर कॉलम डेटा को वापस पढ़ें। इन ऑपरेशनों को पूरा करने के बाद, हम परिणाम को तैयार छवि में इकट्ठा करने के लिए पायथन का उपयोग करते हैं।

लेकिन इससे पहले, हमें विधानसभा भाषा में मशीन कोड में लिस्टिंग को संकलित करने की आवश्यकता है।

x816

जैसा कि स्रोत कोड में संकेत दिया गया है, कोडांतरक x816 का उपयोग करके संकलित किया गया है। x816 एक MS-DOS असेंबलर 6502 है जो NES और ROM हैकर्स के लिए homebrew समुदाय द्वारा उपयोग किया जाता है। यह डॉसबॉक्स पर बहुत अच्छा काम करता है।

प्रोग्राम के रोम के साथ, जो py65emu के लिए आवश्यक है, x816 कोडांतरक एक चरित्र फ़ाइल बनाता है जो सीपीयू के एड्रेस स्पेस में स्मृति में उनके स्थान के लिए पात्रों को मैप करता है। यहाँ फ़ाइल का एक टुकड़ा है:

AREAPARSERCORE = $0093FC ; <> 37884, statement #3154
AREAPARSERTASKCONTROL = $0086E6 ; <> 34534, statement #1570
AREAPARSERTASKHANDLER = $0092B0 ; <> 37552, statement #3035
AREAPARSERTASKNUM = $00071F ; <> 1823, statement #141
AREAPARSERTASKS = $0092C8 ; <> 37576, statement #3048

यहाँ हम देखते हैं कि सोर्स कोड में AreaParserCore फ़ंक्शन को 0x93fc पर एक्सेस किया जा सकता है।

सुविधा के लिए, मैंने एक प्रतीक फ़ाइल पार्सर लिखा जो प्रतीक नामों और पते से मेल खाता है:

 sym_file = SymbolFile('SMBDIS.SYM') print("0x{:x}".format(sym_file['AREAPARSERCORE'])) #  0x93fc print(sym_file.lookup_address(0x93fc)) #  "AREAPARSERCORE" 

सबरूटीन

जैसा कि ऊपर की योजना में कहा गया है, हम सीखना चाहते हैं कि पायथन से AreaParserCore को कैसे कॉल किया AreaParserCore ।

एक उप-प्रक्रिया के यांत्रिकी को समझने के लिए, आइए एक छोटी उप-प्रक्रिया और उसकी संबंधित चुनौती की जाँच करें:

 WritePPUReg1: sta PPU_CTRL_REG1 ;  A   1 PPU sta Mirror_PPU_CTRL_REG1 ;    rts ... jsr WritePPUReg1 

jsr (सबरूटीन पर जाएं, "सबरूटीन पर जाएं") निर्देश पीसी रजिस्टर को स्टैक पर jsr और इसे पता मान WritePPUReg1 जिसे WritePPUReg1 संदर्भित करता WritePPUReg1 । पीसी रजिस्टर प्रोसेसर को लोड करने के लिए अगले निर्देश का पता बताता है, ताकि jsr निर्देश के बाद निष्पादित अगला निर्देश jsr की पहली पंक्ति हो।

सबरूटीन के अंत में, rts स्टेटमेंट निष्पादित किया जाता है (सबरूटीन से वापसी, "सबरूटीन से वापसी")। यह कमांड स्टैक से संग्रहीत मूल्य को निकालता है और इसे पीसी रजिस्टर में संग्रहीत करता है, जो सीपीयू को jsr कॉल के बाद निर्देश को निष्पादित करने के लिए मजबूर करता है।

उपप्रक्रियाओं की एक बड़ी विशेषता यह है कि आप इनलाइन कॉल कर सकते हैं, यानी उपप्रोसेस के भीतर उपप्रकारक कॉल कर सकते हैं। रिटर्न पते को स्टैक पर धकेल दिया जाएगा और सही क्रम में पॉपअप किया जाएगा, उसी तरह जैसे उच्च-स्तरीय भाषाओं में फ़ंक्शन कॉल के साथ।

यहाँ पायथन से सबरूटिन को निष्पादित करने का कोड है:

 def execute_subroutine(cpu, addr): s_before = cpu.rs cpu.JSR(addr) while cpu.rs != s_before: cpu.step() execute_subroutine(cpu, sym_file['AREAPARSERCORE']) 

कोड स्टैक पॉइंटर रजिस्टर ( s ) के वर्तमान मूल्य को बचाता है, एक jsr कॉल का अनुकरण करता है, और तब निर्देश निष्पादित करता है जब तक कि स्टैक अपनी मूल ऊंचाई पर वापस नहीं आता है, जो पहले उपप्रकार की वापसी के बाद ही होता है। यह उपयोगी होगा, क्योंकि अब हमारे पास पायथन से 6502 सबरूटीन्स को सीधे कॉल करने का एक तरीका है।

हालांकि, हम कुछ भूल गए: इस उपप्रकार के लिए इनपुट मान कैसे पारित करें? हमें उस प्रक्रिया को बताना होगा जिस स्तर पर हम रेंडर करना चाहते हैं और हमें किस कॉलम को पार्स करना है।

उच्च-स्तरीय भाषाओं में कार्यों के विपरीत, विधानसभा भाषा 6502 के उप-संस्करण स्पष्ट रूप से निर्दिष्ट इनपुट डेटा प्राप्त नहीं कर सकते हैं। इसके बजाय, इनपुट को कॉल से पहले मेमोरी स्थानों को निर्दिष्ट करके प्रेषित किया जाता है, जो तब उपप्रोसेसर कॉल के अंदर पढ़े जाते हैं। AreaParserCore के आकार को देखते हुए, रिवर्स इंजीनियरिंग को स्रोत कोड को देखते हुए आवश्यक इनपुट करना बहुत जटिल और त्रुटि प्रवण होगा।

एनईएस के लिए मान्य?

AreaParserCore के इनपुट मूल्यों को निर्धारित करने का एक तरीका खोजने के लिए, मैंने एक उदाहरण के रूप में Valgrind के लिए मेमचेक टूल का उपयोग किया। मेमचेक वास्तविक आवंटित स्मृति के प्रत्येक टुकड़े के साथ समानांतर में छाया स्मृति को संग्रहीत करके एकतरफा स्मृति तक पहुंच संचालन को पहचानता है। छाया स्मृति रिकॉर्ड करती है कि रिकॉर्डिंग को वास्तविक मेमोरी में बनाया गया था या नहीं। यदि प्रोग्राम उस पते पर पढ़ता है, जिस पर उसने कभी नहीं लिखा है, तो एक असंक्रमित मेमोरी त्रुटि आउटपुट है। हम एक उपकरण के साथ AreaParserCore चला सकते हैं जो हमें बताता है कि उपप्रक्रिया को लागू करने से पहले क्या इनपुट सेट करने की आवश्यकता है।

वास्तव में, py65emu के लिए एक सरल मेमचेक संस्करण लिखना बहुत आसान है:

 def format_addr(addr): try: symbol_name = sym_file.lookup_address(addr) s = "0x{:04x} ({}):".format(addr, symbol_name) except KeyError: s = "0x{:04x}:".format(addr) return s class MemCheckMMU(MMU): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self._uninitialized = array.array('B', [1] * 2048) def read(self, addr): val = super().read(addr) if addr < 2048: if self._uninitialized[addr]: print("Uninitialized read! {}".format(format_addr(addr))) return val def write(self, addr, val): super().write(addr, val) if addr < 2048: self._uninitialized[addr] = 0 

यहां हमने py65emu की मेमोरी मैनेजमेंट यूनिट (MMU) को लपेटा। इस वर्ग में _uninitialized सरणी होती है, जिनमें से तत्व हमें बताते हैं कि क्या यह कभी भी संबंधित RAM के संबंधित बाइट को लिखा गया है। एक गैर-पढ़े जाने की स्थिति में, अमान्य रीड ऑपरेशन का पता और संबंधित वर्ण का नाम प्रदर्शित होता है।

execute_subroutine(sym_file['AREAPARSERCORE']) :

Uninitialized read! 0x0728 (BACKLOADINGFLAG):
Uninitialized read! 0x0742 (BACKGROUNDSCENERY):
Uninitialized read! 0x0741 (FOREGROUNDSCENERY):
Uninitialized read! 0x074e (AREATYPE):
Uninitialized read! 0x075f (WORLDNUMBER):
Uninitialized read! 0x0743 (CLOUDTYPEOVERRIDE):
Uninitialized read! 0x0727 (TERRAINCONTROL):
Uninitialized read! 0x0743 (CLOUDTYPEOVERRIDE):
Uninitialized read! 0x074e (AREATYPE):
...

कोड को देखकर, आप देख सकते हैं कि इनमें से कई मान InitializeArea सबप्रोडेक्ट द्वारा सेट किए गए हैं, इसलिए पहले इस फ़ंक्शन को कॉल करते हुए स्क्रिप्ट को फिर से चलाएं। इस प्रक्रिया को दोहराते हुए, हम कॉल के निम्नलिखित क्रम में आते हैं, जिसमें केवल विश्व संख्या और क्षेत्र संख्या की आवश्यकता होती है:

 mmu.write(sym_file['WORLDNUMBER'], 0) #    1 mmu.write(sym_file['AREANUMBER'], 0) #    1 execute_subroutine(sym_file['LOADAREAPOINTER']) execute_subroutine(sym_file['INITIALIZEAREA']) metatile_data = [] for column_pos in range(48): execute_subroutine(sym_file['AREAPARSERCORE']) metatile_data.append([mmu.read_no_debug(sym_file['METATILEBUFFER'] + i) for i in range(13)]) execute_subroutine(sym_file['INCREMENTCOLUMNPOS']) 

कोड दुनिया का पहला 48 कॉलम 1-1 स्तर को metatile_data को metatile_data , वर्तमान कॉलम को ट्रैक करने के लिए आवश्यक आंतरिक चर को बढ़ाने के लिए IncrementColumnPos metatile_data का उपयोग करता है।

और यहां खेल से स्क्रीनशॉट पर metatile_data की सामग्री है (0 के मान के साथ बाइट्स दिखाए गए हैं):


जाहिर है, metatile_data स्पष्ट रूप से पृष्ठभूमि जानकारी से मेल खाती है।

मेटा ग्राफिक्स

(अंतिम परिणाम देखने के लिए, आप तुरंत "सब कुछ एक साथ जोड़ने" अनुभाग पर आगे बढ़ सकते हैं।)

अब आइए जानें कि प्राप्त फाइलों को मेटा फाइलों को वास्तविक चित्रों में कैसे बदलना है। नीचे वर्णित चरणों का आविष्कार स्रोतों का विश्लेषण करके और अद्भुत नेसदेव विकी के साथ प्रलेखन पढ़ने के द्वारा किया गया था।

यह समझने के लिए कि प्रत्येक मेटैलिक को कैसे रेंडर किया जाए, हमें सबसे पहले NES कलर पैलेट के बारे में बात करनी होगी। NES कंसोल PPU आम तौर पर 64 अलग-अलग रंगों को प्रस्तुत कर सकता है, लेकिन काले को कई बार दोहराया जाता है ( विवरण के लिए Nesdev देखें ):


प्रत्येक मारियो स्तर पृष्ठभूमि के लिए इन 64 रंगों में से केवल 10 का उपयोग कर सकता है, 4 चार-रंग पट्टियों में विभाजित; पहला रंग हमेशा समान होता है। यहाँ 1-1 विश्व के लिए चार पैलेट हैं:


आइए अब मेटा फाइल नंबर के एक द्विआधारी उदाहरण को देखें। यहाँ खुरदार पत्थर की टाइल मेटैलिक संख्या है, जो कि विश्व 1-1 स्तर की भूमि है:


पैलेट इंडेक्स हमें बताता है कि मेटैलिक (हमारे मामले में, पैलेट 1) का प्रतिपादन करते समय किस पैलेट का उपयोग करना है। पैलेट इंडेक्स निम्नलिखित दो सरणियों का सूचकांक भी है:

MetatileGraphics_Low:
.db <Palette0_MTiles, <Palette1_MTiles, <Palette2_MTiles, <Palette3_MTiles

MetatileGraphics_High:
.db >Palette0_MTiles, >Palette1_MTiles, >Palette2_MTiles, >Palette3_MTiles

इन दो सरणियों के संयोजन से हमें 16-बिट पता मिलता है, जो हमारे उदाहरण में Palette1_Mtiles ओर Palette1_Mtiles :

Palette1_MTiles:
.db $a2, $a2, $a3, $a3 ;vertical rope
.db $99, $24, $99, $24 ;horizontal rope
.db $24, $a2, $3e, $3f ;left pulley
.db $5b, $5c, $24, $a3 ;right pulley
.db $24, $24, $24, $24 ;blank used for balance rope
.db $9d, $47, $9e, $47 ;castle top
.db $47, $47, $27, $27 ;castle window left
.db $47, $47, $47, $47 ;castle brick wall
.db $27, $27, $47, $47 ;castle window right
.db $a9, $47, $aa, $47 ;castle top w/ brick
.db $9b, $27, $9c, $27 ;entrance top
.db $27, $27, $27, $27 ;entrance bottom
.db $52, $52, $52, $52 ;green ledge stump
.db $80, $a0, $81, $a1 ;fence
.db $be, $be, $bf, $bf ;tree trunk
.db $75, $ba, $76, $bb ;mushroom stump top
.db $ba, $ba, $bb, $bb ;mushroom stump bottom
.db $45, $47, $45, $47 ;breakable brick w/ line
.db $47, $47, $47, $47 ;breakable brick
.db $45, $47, $45, $47 ;breakable brick (not used)
.db $b4, $b6, $b5, $b7 ;cracked rock terrain <--- This is the 20th line
.db $45, $47, $45, $47 ;brick with line (power-up)
.db $45, $47, $45, $47 ;brick with line (vine)
.db $45, $47, $45, $47 ;brick with line (star)
.db $45, $47, $45, $47 ;brick with line (coins)
...

जब आप मेटास्टाइल इंडेक्स को 4 से गुणा करते हैं, तो यह इस ऐरे का इंडेक्स बन जाता है। डेटा को 4 रिकॉर्ड प्रति पंक्ति में स्वरूपित किया जाता है, इसलिए हमारा उदाहरण मेटिअनेट बीसवीं पंक्ति को संदर्भित करता है, जो एक cracked rock terrain टिप्पणी के साथ चिह्नित है।

इस पंक्ति की चार प्रविष्टियाँ वास्तव में टाइल आइडेंटिफ़ायर हैं: प्रत्येक मेटास्टाइल में चार 8x8-पिक्सेल टाइलें होती हैं जो निम्न क्रम में व्यवस्थित होती हैं - ऊपरी बाएँ, निचले बाएँ, ऊपरी दाएँ और निचले दाएँ। ये पहचानकर्ता सीधे एनईएस पीपीयू कंसोल को पास किए जाते हैं। पहचानकर्ता CHR-ROM कंसोल में डेटा के 16 बाइट्स को संदर्भित करता है, और प्रत्येक रिकॉर्ड 0x1000 + 16 * < > पते से शुरू होता है:

0x1000 + 16 * 0xb4: 0b01111111 0x1000 + 16 * 0xb5: 0b11011110
0x1001 + 16 * 0xb4: 0b10000000 0x1001 + 16 * 0xb5: 0b01100001
0x1002 + 16 * 0xb4: 0b10000000 0x1002 + 16 * 0xb5: 0b01100001
0x1003 + 16 * 0xb4: 0b10000000 0x1003 + 16 * 0xb5: 0b01100001
0x1004 + 16 * 0xb4: 0b10000000 0x1004 + 16 * 0xb5: 0b01110001
0x1005 + 16 * 0xb4: 0b10000000 0x1005 + 16 * 0xb5: 0b01011110
0x1006 + 16 * 0xb4: 0b10000000 0x1006 + 16 * 0xb5: 0b01111111
0x1007 + 16 * 0xb4: 0b10000000 0x1007 + 16 * 0xb5: 0b01100001
0x1008 + 16 * 0xb4: 0b10000000 0x1008 + 16 * 0xb5: 0b01100001
0x1009 + 16 * 0xb4: 0b01111111 0x1009 + 16 * 0xb5: 0b11011111
0x100a + 16 * 0xb4: 0b01111111 0x100a + 16 * 0xb5: 0b11011111
0x100b + 16 * 0xb4: 0b01111111 0x100b + 16 * 0xb5: 0b11011111
0x100c + 16 * 0xb4: 0b01111111 0x100c + 16 * 0xb5: 0b11011111
0x100d + 16 * 0xb4: 0b01111111 0x100d + 16 * 0xb5: 0b11111111
0x100e + 16 * 0xb4: 0b01111111 0x100e + 16 * 0xb5: 0b11000001
0x100f + 16 * 0xb4: 0b01111111 0x100f + 16 * 0xb5: 0b11011111

0x1000 + 16 * 0xb6: 0b10000000 0x1000 + 16 * 0xb7: 0b01100001
0x1001 + 16 * 0xb6: 0b10000000 0x1001 + 16 * 0xb7: 0b01100001
0x1002 + 16 * 0xb6: 0b11000000 0x1002 + 16 * 0xb7: 0b11000001
0x1003 + 16 * 0xb6: 0b11110000 0x1003 + 16 * 0xb7: 0b11000001
0x1004 + 16 * 0xb6: 0b10111111 0x1004 + 16 * 0xb7: 0b10000001
0x1005 + 16 * 0xb6: 0b10001111 0x1005 + 16 * 0xb7: 0b10000001
0x1006 + 16 * 0xb6: 0b10000001 0x1006 + 16 * 0xb7: 0b10000011
0x1007 + 16 * 0xb6: 0b01111110 0x1007 + 16 * 0xb7: 0b11111110
0x1008 + 16 * 0xb6: 0b01111111 0x1008 + 16 * 0xb7: 0b11011111
0x1009 + 16 * 0xb6: 0b01111111 0x1009 + 16 * 0xb7: 0b11011111
0x100a + 16 * 0xb6: 0b11111111 0x100a + 16 * 0xb7: 0b10111111
0x100b + 16 * 0xb6: 0b00111111 0x100b + 16 * 0xb7: 0b10111111
0x100c + 16 * 0xb6: 0b01001111 0x100c + 16 * 0xb7: 0b01111111
0x100d + 16 * 0xb6: 0b01110001 0x100d + 16 * 0xb7: 0b01111111
0x100e + 16 * 0xb6: 0b01111111 0x100e + 16 * 0xb7: 0b01111111
0x100f + 16 * 0xb6: 0b11111111 0x100f + 16 * 0xb7: 0b01111111

CHR-ROM मेमोरी का केवल पढ़ने वाला टुकड़ा है जिसे केवल PPU ही एक्सेस कर सकता है। इसे PRG-ROM से अलग किया जाता है, जो प्रोग्राम कोड को स्टोर करता है। इसलिए, उपरोक्त डेटा स्रोत कोड में उपलब्ध नहीं हैं और इसे गेम के रोम के डंप से प्राप्त किया जाना चाहिए।

प्रत्येक टाइल के लिए 16 बाइट्स 2-बिट 8x8 टाइल बनाते हैं: पहला बिट पहले 8 बाइट्स है, और दूसरा दूसरा 8 बाइट्स है:

21111111 13211112
12222222 23122223
12222222 23122223
12222222 23122223
12222222 23132223
12222222 23233332
12222222 23111113
12222222 23122223

12222222 23122223
12222222 23122223
33222222 31222223
11332222 31222223
12113333 12222223
12221113 12222223
12222223 12222233
23333332 13333332

इस डेटा को पैलेट 1 में बाँधें:


... और टुकड़ों को मिलाएं:


अंत में हमें एक प्रदान की गई टाइल मिली।

यह सब एक साथ रखना

प्रत्येक मेटा फ़ाइल के लिए इस प्रक्रिया को दोहराते हुए, हमें पूरी तरह से प्रदान किया गया स्तर मिलता है।


और इसके लिए धन्यवाद, हम पायथन का उपयोग करके एसएमबी स्तर के ग्राफिक्स निकालने में सक्षम थे!