जैसा कि हमने पिछले भाग में पाया, गेम के मशीन कोड्स को डिस्केट से सीधे गंतव्य पते पर डाउनलोड नहीं किया जा सकता है। हम उन्हें किसी अन्य स्थान पर अपलोड करेंगे, और डाउनलोड करने के बाद हम उन्हें आवश्यक स्थान पर ले जाएंगे। इसके अलावा, हम बूट-लोडर और लोड किए गए डेटा दोनों एक ही मूल फ़ाइल में होने पर एक-ब्लॉक बूटलोडर बनाना चाहते हैं। ऐसा लोडर केवल मशीन कोड में लिखा जा सकता है। उसी समय, चूंकि हमारे पास एक मोनोब्लॉक फ़ाइल है, इसलिए मशीन कोड में लोडर को बेसिक में लोडर को टिप्पणियों में रखना होगा।
कुल, यह निम्नलिखित मन्नोगोडोवका निकला:
- BASIC से हम मशीन कोड में प्रोग्राम को कंट्रोल ट्रांसफर करते हैं।
- मशीन कोड में प्रोग्राम, बूटलोडर को BASIC क्षेत्र से दूसरे क्षेत्र में स्थानांतरित करता है जो खेल के मशीन कोड से प्रभावित नहीं होगा, और इसे नियंत्रण स्थानांतरित करता है।
- बूट छवि को डाउनलोड और अनपैक करें।
- हम गेम मशीन कोड को एक ऐसे क्षेत्र में लोड करते हैं जो सिस्टम चर के क्षेत्र को ओवरलैप नहीं करता है।
- हम मशीन कोड को गंतव्य पते पर स्थानांतरित करते हैं।
- हम नियंत्रण को कार्यक्रम में स्थानांतरित करते हैं।
विकास को बीच में शुरू करना होगा (पैराग्राफ 3)। तथ्य यह है कि एक आंदोलन कार्यक्रम लिखने के लिए, आपको उस कार्यक्रम के आकार को जानना होगा जो आप आगे बढ़ रहे हैं, और एक मूल में मशीन कोड एम्बेड करने के लिए, आपको आंदोलन कार्यक्रम के आकार को जानने की आवश्यकता है।
मोनोब्लॉक बूटलोडर (मशीन कोड में हिस्सा)
टीआर-डॉस में, एक मोनोब्लॉक फ़ाइल से डेटा लोड करना एक टेप से हेडरलेस फ़ाइल लोड करने की तरह है, जब एक पूर्व निर्धारित आकार का डेटा बस वर्तमान स्थिति से पढ़ा जाता है और मेमोरी के एक विशिष्ट क्षेत्र में लोड होता है। इसके लिए, TR-DOS में, #3D13 पर दिनचर्या #3D13 । सबसे पहले, डाउनलोड करें और चित्र को अनज़िप करें:
LD DE, ($5CF4) ; LD BC, $0805 ; B - (9)*, ; — #05 ( ) LD HL, $8000 ; 32768** CALL $3D13 ; TR-DOS CALL $8000 ;
& ast; - पिछले भाग में बूट छवि का संपीड़न देखें;
& ast; & ast; - अनपैकर रिलेक्वेबल है, जिससे आप कहीं भी डाउनलोड कर सकते हैं।
इसी तरह, गेम मशीन कोड डाउनलोड करें:
LD DE, ($5CF4) ; LD BC, $2505 ; B - , ; — #05 ( ) LD HL, $6000 ; 24576 CALL $3D13 ; TR-DOS
इस स्तर पर, हमें अब TR-DOS की आवश्यकता नहीं है; हम LDIR प्रोसेसर LDIR का उपयोग करके मशीन कोड को गंतव्य पते पर स्थानांतरित कर सकते हैं:
LD HL, $6000 ; (, ) LD DE, $5B00 ; LD BC, $2500 ; ( data.bin) LDIR
ठीक है, अंत में, हम प्रोग्राम को मूल बूटलोडर की तरह नियंत्रण स्थानांतरित करते हैं - स्टैक पॉइंटर को स्थानांतरित करके:
LD SP, $5D7C RET
अब जब लोडर कोड तैयार हो गया है, तो आपको इसका आकार जानने के लिए इसे संकलित करने की आवश्यकता है, जिसकी हमें आगे आवश्यकता होगी।
$ pasmo tmp.asm tmp.bin $ wc -c tmp.bin 44 tmp.bin
बूटलोडर ट्रांसफर प्रक्रिया
बूटलोडर में 44 बाइट्स होते हैं। अब आपको BASIC में टिप्पणियों से बूट लोडर को स्थानांतरित करने की प्रक्रिया लिखने की आवश्यकता है (लेख की शुरुआत में सूची के बिंदु 2)। अड़चन यह है कि पता जहां बेसिक क्षेत्र स्थित है, कंप्यूटर से जुड़ी बाह्य उपकरणों के आधार पर भिन्न हो सकता है, इसलिए, यह निर्धारित करने के लिए कि आप डेटा कहाँ स्थानांतरित करना चाहते हैं, आपको PROG सिस्टम चर (मूल बूटलोडर में) पर ध्यान केंद्रित करने की आवश्यकता है या सॉफ्टवेयर काउंटर ( PC प्रोसेसर रजिस्टर)।
सॉफ्टवेयर काउंटर तक पहुंचना इतना आसान नहीं है - LD HL, PC जैसे कोई प्रोसेसर निर्देश मौजूद नहीं हैं। मैंने लेज़र कम्प्रेशन में समाधान की जासूसी की और यह इस तरह दिखता है ( UNSTACK_Z प्रक्रिया का वास्तव में लक्षित उपयोग नहीं):
LD DE, $00 ; , , ; . ; 1 INC E ; 1 E, , ; . 1 CALL $1FC6 ; ( , LD HL, PC) ADD HL, DE ; LD DE, $F800 ; LD BC, $002C ; , (44 ) LDIR JP $F800 ; ; ;
ROM प्रक्रिया #1FC6 पर कॉल करने के समय, अगले निर्देश ( ADD HL, DE ) का पता स्टैक पर होगा। यह वह है जिसे HL में प्रक्रिया को कॉल करने के परिणामस्वरूप दर्ज किया जाएगा। तदनुसार, उस संख्या को निर्धारित करने के लिए जिसे बहुत पहली पंक्ति में लिखा जाना चाहिए, आपको ADD HL, DE से अंत तक फिर से एक टुकड़ा संकलित करने की आवश्यकता है और देखें कि इसमें कितना समय लगेगा:
$ pasmo tmp.asm tmp.bin $ wc -c tmp.bin 12 tmp.bin
यह 12 बाइट्स निकला। तदनुसार, पहली पंक्ति में हम 11 ( #0B ) लिखते हैं।
अगला, हम लोडर के साथ चाल प्रक्रिया की रचना करते हैं ( समाप्त फ़ाइल देखें), जिसे वह फिर से स्थानांतरित करेगा और संकलित करेगा। इसे 56 बाइट्स करना चाहिए।
यहां यह ध्यान दिया जाना चाहिए कि इस टुकड़े को लिखने के बाद, मुझे लगा कि कार्यक्रम को स्थानांतरित करने की लंबाई की गणना करने के बजाय, आप लेबल का उपयोग कर सकते हैं और कोडांतरक को बता सकते हैं। लेकिन ऐतिहासिक न्याय के लिए, इसे वैसे ही रहने दें।
मोनोब्लॉक बूटलोडर (आधार भाग)
अब जब हम मशीन कोड में बूटलोडर के आकार को जानते हैं, तो हम बूटलोडर को BASIC में लिख सकते हैं और एक मोनोब्लॉक फ़ाइल में सब कुछ एकत्र कर सकते हैं।
मशीन कोड एक बुनियादी फ़ाइल में या तो एक टिप्पणी में या एक फ़ाइल के अंत में एम्बेडेड होते हैं। दूसरा आमतौर पर फ़ाइल के अध्ययन को जटिल बनाता है और सुरक्षा के लिए अधिक उपयुक्त है, इसलिए हम पहले विकल्प का उपयोग करेंगे। टिप्पणी विकल्प इस प्रकार है:
1 REM @#$%... 10 RANDOMIZE USR (PEEK 23635+256*PEEK 23636+5)
23635 ( #5C53 ) PROG सिस्टम वैरिएबल का पता है जिसका हमने पहले उल्लेख किया था। 5 PROG सापेक्ष टिप्पणी के पहले वर्ण की भरपाई है (2 बाइट्स पंक्ति संख्या हैं, 2 बाइट्स पंक्ति की लंबाई हैं और 1 बाइट REM ऑपरेटर है)। यदि आप मशीन कोड से पहले कोई अन्य टिप्पणी जोड़ना चाहते हैं, उदाहरण के लिए आपका नाम, फोन नंबर या मेलिंग पता, तो मान 5 को समायोजित करने की आवश्यकता होगी।
अगर हमने बूटलोडर बनाने के लिए किसी भी अतिरिक्त उपयोगिताओं का उपयोग नहीं किया है, तो हमें मशीन कोड में प्रोग्राम की लंबाई से कम राशि में REM बाद मनमाने अक्षर दर्ज करने की आवश्यकता होगी जिसे हम टिप्पणी के स्थान पर रखना चाहते हैं (हमारे मामले में 56 बाइट्स)। उसके बाद, कोई LOAD "" CODE PEEK 23635+256*PEEK 23636+5 माध्यम से प्रोग्राम को LOAD "" CODE PEEK 23635+256*PEEK 23636+5 कर सकता है और फाइल को सेव कर सकता है।
हालाँकि, bas2tap प्रक्रिया को बहुत आसान बना सकता है। यह एक मूल फ़ाइल संकलित कर सकता है और इसमें बाइनरी डेटा एम्बेड कर सकता है यदि प्रत्येक बाइट को घुंघराले कोष्ठक में एक हेक्साडेसिमल संख्या के रूप में दर्शाया जाता है। ऐसा करने के लिए, संकलित बूटलोडर को hexdump माध्यम से hexdump :
$ hexdump -ve '1/1 "{%02x}"' loader.bin {11}{0b}{00}{1c}{cd}{c6}{1f}{19}{11}...
hexdump REM बाद पहली पंक्ति में टिप्पणी के स्थान पर hexdump आउटपुट hexdump और -sboot पर बूटलोडर संकलित करते हैं -sboot टेप पर फ़ाइल का नाम है, -a10 की लाइन संख्या है:
$ bas2tap -sboot -a10 boot.bas boot.tap
मध्यवर्ती प्रारूप 0 माध्यम से बूटलोडर को tap फॉर्मेट से hobeta :
$ tapto0 -f boot.tap $ 0tohob boot.000
एक एक टुकड़ा फ़ाइल बनाना
इस बिंदु पर, हमारे पास पहले से ही एक फ्लॉपी डिस्क छवि बनाने के लिए सभी आवश्यक फाइलें हैं। आप एक चित्र बना सकते हैं और उसमें सभी आवश्यक फाइलों को कॉपी कर सकते हैं:
createtrd Pac-Man.trd hobeta2trd boot.\$$B Pac-Man.trd hobeta2trd screen.\$$C Pac-Man.trd hobeta2trd data.\$$C Pac-Man.trd
परिणामस्वरूप फ्लॉपी डिस्क छवि को पहले से ही काम करना चाहिए। आप इसे एमुलेटर में चला सकते हैं और जांच सकते हैं, लेकिन यह सब नहीं है। चूंकि हम बूटलोडर बाद की फाइलों को नाम से नहीं डाउनलोड करते हैं, लेकिन ड्राइव के सिर की स्थिति के आधार पर, लोडिंग केवल तभी काम करेगी जब फाइलें डिस्क पर एक के बाद एक स्थित हों। इसे ठीक करने की जरूरत है।
सिद्धांत इस प्रकार है: TR-DOS अनावश्यक फ़ाइल आकार जानकारी संग्रहीत करता है:
- सेक्टरों में आकार - फ़्लॉपी डिस्क और कॉपी पर फ़ाइलों को रखने के लिए उपयोग किया जाता है।
- बाइट्स में आकार - सामग्री लोड करने के लिए उपयोग किया जाता है।
आमतौर पर ये आकार एक-दूसरे (256 बाइट्स प्रति सेक्टर) के अनुरूप होते हैं, लेकिन यह आवश्यक नहीं है। हम इसका फायदा उठाएंगे। यदि आप बूट फ़ाइल का आकार सेक्टर में उन सभी फ़ाइलों के कुल आकार के बराबर मान में बदलना चाहते हैं, जिन्हें हम डाउनलोड करना चाहते हैं, लेकिन बाइट्स में आकार नहीं बदलते हैं, तो TR-DOS सभी डेटा को एक बड़ी फ़ाइल के रूप में कॉपी कर देगा, लेकिन केवल मूल बूट में लोड किया जाएगा भाग।
एक असली स्पेक्ट्रम या एक एमुलेटर में, शून्य ट्रैक को डिस्क डॉक्टर जैसे कार्यक्रमों के साथ संपादित किया जा सकता है, उदाहरण के लिए, हेक्स डिस्क संपादक :
लेकिन इसे सरल बनाया जा सकता है: डिस्केट पर सभी डेटा की बाइट कॉपी से अधिक एक ट्रड-इमेज कुछ भी नहीं है, इसलिए इसे किसी भी हेक्स संपादक में संपादित किया जा सकता है:
$ hexdump -C Pac-Man.trd | head -4 00000000 62 6f 6f 74 20 20 20 20 42 d0 00 d0 00 01 00 01 |boot B.......| 00000010 73 63 72 65 65 6e 20 20 43 40 9c 14 07 08 01 01 |screen C@......| 00000020 64 61 74 61 20 20 20 20 43 00 5b 00 25 25 09 01 |data C.[.%%..| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
जैसा कि आप देख सकते हैं, डिस्केट की सबसे शुरुआत में (ट्रैक शून्य पर) एक फ़ाइल आवंटन तालिका है जिसमें प्रत्येक फ़ाइल के बारे में जानकारी 16 बाइट्स लेती है। सेक्टरों में आकार बाइट #0D (दाईं ओर तीसरा स्तंभ) के साथ बाइट में संग्रहीत किया जाता है। हमारी फ़ाइलों का आकार #01 , #08 और #25 सेक्टर है, जो कुल मिलाकर #2E । हम इस मूल्य को संबंधित बाइट में लिखते हैं, और शेष हेडर को हटा देते हैं, क्योंकि उन्हें अब जरूरत नहीं है:
$ hexdump -C Pac-Man.trd | head -4 00000000 62 6f 6f 74 20 20 20 20 42 d0 00 d0 00 2E 00 01 |boot B.......| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
अब हमारे पास एक पूर्ण विकसित फ्लॉपी डिस्क छवि है। इसे सही ढंग से लोड करना होगा और डिस्क से डिस्क में पूरी तरह से कॉपी होना चाहिए। यह केवल छवि के आकार को कम करने के लिए बनी हुई है। चूंकि ट्राड इमेज एक बाइट कॉपी है, इसलिए यह हमेशा 640KB लेता है। व्यवहार में, ज्यादातर मामलों में, यह scl प्रारूप का उपयोग करने के लिए अधिक सुविधाजनक है, जो कि hobeta स्टोर की तरह अधिक है जो सीधे डेटा फ़ाइल करता है:
$ trd2scl Pac-Man.trd Pac-Man.scl
अब यकीन के लिए। शुरू से अंत तक अनुकूलन प्रक्रिया गिटहब पर परियोजना भंडार में पाई जा सकती है।
उपकरण:
- पासमो Z80 के लिए एक क्रॉस-असेंबलर है।
bas2tap स्पेक्ट्रम BASIC बोली का एक क्रॉस-कंपाइलर है।trd2scl - trd-image trd2scl को scl।
संबंधित लिंक:
- निकोलाई रोडियोनोव द्वारा "टीआर-डॉस सिस्टम में कार्यक्रमों का अनुकूलन" ।
- "टीआर-डॉस फ़ंक्शंस" जानकारी गाइड पत्रिका नंबर 1 से।
- "टीआर-डॉस डिस्केट की संरचना" पुस्तक से "पेशेवरों और एमेच्योर के लिए टीआर-डॉस । "
- सिस्टम चर और स्पेक्ट्रम रॉम प्रक्रियाओं का संदर्भ ।