जब जीसीसी में 16-बिट पते होते हैं, और अचानक मेमोरी 256k होती है

... या कैसे खुद को एक Arduino पर पैर में गोली मारना है

ग्रीष्मकालीन कंप्यूटर स्कूल में, हम खेल के विकास के शिक्षण के लिए खुद के बनाए पुराने कंप्यूटर का उपयोग करते हैं।

अब इसमें एक Armeino Mega बोर्ड है जिसमें ATmega2560 प्रोसेसर है, जिसमें 256 किलोबाइट फ्लैश मेमोरी है। यह माना जाता था कि यह बहुत लंबे समय तक चलेगा, क्योंकि खेल सरल हैं (स्क्रीन केवल 64x64 पिक्सल है)। वास्तविकता में, हम कुछ समस्याओं का सामना कर रहे थे जब फर्मवेयर लगभग 128 किलोबाइट तक पहुंच गया था।

प्रोग्राम मेमोरी में, इसके नाम के बावजूद, गेम के निष्पादन योग्य कोड के अलावा, सभी प्रकार के अपरिवर्तित डेटा जैसे स्प्राइट और स्तर तालिकाओं को संग्रहीत किया जाता है। यह डेटा इतना नहीं है।

लेकिन जब हमने YM2149F साउंड चिप को अपने कंप्यूटर से कनेक्ट किया , और एक ही प्रोग्राम मेमोरी में कुछ दर्जन धुनों को डाउनलोड किया, तो समस्याएं शुरू हो गईं।


जब कोई राग बजाने की कोशिश कर रहा हो तो उपसर्ग दुर्घटनाग्रस्त हो गया, या खेल मेनू में कुछ कचरा फेंक दिया। यह स्पष्ट नहीं था कि इसे कैसे डिबग किया जाए, क्योंकि प्रोसेसर न केवल गेम के तर्क से संबंधित है, बल्कि छवि और ध्वनि भी प्रदर्शित करता है। नतीजतन, यह पता चला कि जीसीसी-एवीआर संकलक दो बाइट्स के चर का उपयोग करता है जो पॉइंटर्स को स्टोर करने के लिए है। लेकिन सिर्फ दो बाइट के साथ 256 किलोबाइट को संबोधित करना असंभव है! वह कैसे बाहर निकलता है?

कोड पॉइंटर्स

सबसे पहले, फ़ंक्शन कॉल निर्देश और जंप तीन-बाइट पते का उपयोग कर सकते हैं। इसलिए, यह इस तरह के निर्देश में पूर्ण पता स्थानापन्न करने के लिए लिंकर के लिए पर्याप्त है और यह काम करेगा। यदि फ़ंक्शन का पता एक पॉइंटर से गुजरता है, तो ऐसी संख्या पास नहीं होगी - क्योंकि हमारे पास एक डबल-बाइट पॉइंटर है।

इस स्थिति में, जीसीपी 64kb - निचले निर्देश में एक "स्प्रिंगबोर्ड" सम्मिलित करता है, जो वांछित फ़ंक्शन पर स्विच करता है। फिर इस स्प्रिंगबोर्ड का पता उस फ़ंक्शन के पते के रूप में कार्य करेगा जिसे चर में संग्रहीत करने की आवश्यकता है - आखिरकार, इसे दो बाइट्स में रखा गया है। और जब बुलाया जाता है, तो आवश्यक होने पर एक संक्रमण होगा।

डेटा पॉइंटर्स

लेकिन हम प्रोग्राम मेमोरी में स्टोर करते हैं न केवल निष्पादन योग्य कोड। तो यहां कूदने से कोई फायदा नहीं होगा - हम डेरेफेरिंग पॉइंटर्स हैं, लेकिन उनके पास नहीं जा रहे हैं।

AVR लाइब्रेरी में पूर्ण सूचक को निष्क्रिय करने के लिए pgm_read_byte_far (addr) जैसे फ़ंक्शंस / मैक्रोज़ भी हैं (वे चार-बाइट मान पास किए गए हैं)। लेकिन जीसीसी को नहीं पता कि सी भाषा का उपयोग करके इन बिंदुओं को कैसे प्राप्त किया जाए।

सौभाग्य से, एक चर का पूरा पता प्राप्त करने के लिए मैक्रो pgm_get_far_address (var) है। यह बिल्ट-इन असेम्बलर का उपयोग करके किया जाता है (ऐसा मामला जब असेम्बलर कंपाइलर से अधिक स्मार्ट हो)।

यह ROM में डेटा का उपयोग करने वाले सभी कोड को फिर से लिखना है। यह है, एक संगीत खिलाड़ी, स्प्राइट प्रदान करता है, पाठ आउटपुट, ... बहुत सुखद अनुभव नहीं है। हां, और कोड अधिक निरोधात्मक हो जाएगा, और ग्राफिक्स के लिए यह बहुत महत्वपूर्ण है। इसलिए,

हम ROM पर डेटा वितरित करते हैं

लिंकर 64k में प्रोग्राम मेमोरी के लिए डेटा डालने की बहुत कोशिश कर रहा है। बहुत अधिक डेटा होने पर यह काम नहीं करता है। लेकिन हमारे पास सबसे बड़ा डेटा म्यूज़िक फाइल्स हैं। इसलिए यदि आप केवल उन्हें हटाते हैं, तो बाकी सब कुछ कम मेमोरी में फिट होगा और आपको कोड के मुख्य भाग को फिर से नहीं करना होगा।

ऐसा करने के लिए, हम लिंकर स्क्रिप्ट की विशेषताओं का फायदा उठाएंगे। रोम में लिंकर स्थानों को अंतिम खंडों में से एक .fini7 कहा जाता है। इस अनुभाग में सभी संगीत सरणियों को सहेजें:

#define MUSICMEM __attribute__((section(".fini7"))) const uint8_t tetris2[] MUSICMEM = { ... }; 

अब avr-nm हमें बताता है कि सब कुछ क्रम में है - स्प्राइट और स्तरों वाले डेटा रोम के निचले भाग में और शीर्ष पर संगीत है।

 00002f9c t _ZL10level_menu 00002e0f t _ZL10rope_lines 000006de t _ZL10ShipSprite 00023a09 t tetris2 00024714 T the_last_v8 

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

 00006992 <_Z12tetris2_addrv>: 6992: 61 ef ldi r22, 0xF1 ; 241 6994: 7a e3 ldi r23, 0x3A ; 58 6996: 82 e0 ldi r24, 0x02 ; 2 6998: 99 27 eor r25, r25 699a: 08 95 ret 

दुनिया के अंत में देरी हो रही है जब तक कि स्प्राइट्स 64k के नीचे न आ जाए। यह संभावना नहीं है, क्योंकि स्प्राइट्स की तुलना में अभी भी अधिक कोड है, जिसका अर्थ है कि मेमोरी संभवतः सामान्य रूप से समाप्त हो जाएगी।

बोनस

इस गर्मी में हमने सोकोबन की शैली में एक खेल लिखा था। कुछ स्तर काफी कठिन थे। उदाहरण के लिए, इसे पास करने का प्रयास करें:

संदर्भ

1. गिथब प्रोजेक्ट पेज
2. Arduino और LED डिस्प्ले
3. Arduino और द फिलॉसफ़र का म्यूज़िकल स्टोन
4. पिछले साल के कुछ खेल