इंटेल हेक्स

From Vigyanwiki
Not to be confused with इंटेल हेक्साडेसिमल नोटेशन.
इंटेल हेक्स
Filename extension
.hex,[1] .h86,[2][3] .hxl,[4] .hxh,[4] .obl,[4] .obh,[4] .mcs,[5] .ihex, .ihe, .ihx, .a43, .a90, .p00[6] to .pff[6]

इंटेल हेक्साडेसिमल ऑब्जेक्ट फ़ाइल फॉर्मेट, इंटेल हेक्स फॉर्मेट या इंटेलेक हेक्स एक फ़ाइल फॉर्मेट है जो ASCII टेक्स्ट रूप में बाइनरी जानकारी देता है।[7] इसका उपयोग सामान्यतः प्रोग्रामिंग माइक्रोकंट्रोलर, EPROMs और अन्य टाइप के प्रोग्रामेबल लॉजिक डिवाइस और हार्डवेयर एमुलेटर के लिए किया जाता है। एक विशिष्ट एप्लिकेशन में, एक कंपाइलर या असेंबलर एक प्रोग्राम के सोर्स कोड (जैसे सी या असेंबली लैंग्वेज में) को मशीन कोड में परिवर्तित करता है और इसे हेक्स फ़ाइल में आउटपुट करता है। कुछ लोग इसका उपयोग स्ट्रीम डेटा के पैकेट रखने वाले कंटेनर फॉर्मेट के रूप में भी करते हैं।[8][1] परिणामी फ़ाइलों के लिए उपयोग किए जाने वाले सामान्य फ़ाइल एक्सटेंशन .हेक्स[1] या H86 हैं।[2][3] हेक्स फ़ाइल को प्रोग्रामर द्वारा PROM में मशीन कोड लिखने के लिए पढ़ा जाता है या लोडिंग और निष्पादन के लिए लक्ष्य सिस्टम में स्थानांतरित किया जाता है।[9][10]

इतिहास

इंटेल हेक्स फॉर्मेट मूल रूप से 1973 में इंटेल के इंटेलेक माइक्रो कंप्यूटर डेवलपमेंट सिस्टम (एमडीएस) के लिए डिज़ाइन किया गया था ताकि पेपर टेप से प्रोग्राम लोड और निष्पादित किया जा सके। इसका उपयोग ROM उत्पादन के लिए Intel को मेमोरी सामग्री निर्दिष्ट करने के लिए भी किया जाता था।[11] 1973 में, इंटेल के "सॉफ़्टवेयर समूह" में केवल बिल बायर्ली और केन बर्गेट और बाहरी सलाहकार के रूप में गैरी किल्डॉल सम्मिलित थे।[12][13][6] 1975 की आरंभ में, फ़ाइल एक्सटेंशन हेक्स का उपयोग करते हुए, इस फॉर्मेट का उपयोग MCS सीरीज II ISIS-II सिस्टम द्वारा किया गया था।[14] कई PROM और EPROM प्रोग्रामिंग उपकरणों ने इस फॉर्मेट को स्वीकार किया।

फॉर्मेट

Intel हेक्स में ASCII टेक्स्ट की पंक्तियाँ होती हैं जो लाइन फ़ीड या कैरिएज रिटर्न कैरेक्टर या दोनों द्वारा अलग की जाती हैं। प्रत्येक टेक्स्ट लाइन में हेक्साडेसिमल वर्ण होते हैं जो एकाधिक बाइनरी संख्याओं को एन्कोड करते हैं। बाइनरी संख्याएँ डेटा, मेमोरी एड्रेस या अन्य मानों का प्रतिनिधित्व कर सकती हैं, जो लाइन में उनकी स्थिति और लाइन के टाइप और लंबाई पर निर्भर करता है। प्रत्येक टेक्स्ट लाइन को रिकॉर्ड कहा जाता है।

रिकॉर्ड संरचना

एक रिकॉर्ड (टेक्स्ट की लाइन) में छह फ़ील्ड (भाग) होते हैं जो बाएं से दाएं क्रम में दिखाई देते हैं:[9]

  1. स्टार्ट कोड, एक वर्ण, एक ASCII कोलन ':'। किसी रिकॉर्ड में इस प्रतीक से पहले आने वाले सभी वर्णों को अनदेखा किया जाना चाहिए।[11][2][15][16][17][18] वास्तव में, विनिर्देश के बहुत प्रारंभिक संस्करणों में पहले रिकॉर्ड से पहले और अंतिम रिकॉर्ड के बाद कम से कम 25 एनयूएल वर्णों की मांग की गई थी।[11][19][16][17] हालाँकि, चूंकि यह विनिर्देशन का एक अल्पज्ञात हिस्सा था, इसलिए लिखे गए सभी सॉफ़्टवेयर इसका सही ढंग से सामना नहीं कर पाते। यह अन्य संबंधित जानकारी को एक ही फ़ाइल (और यहां तक ​​कि एक ही लाइन) में संग्रहीत करने की अनुमति देता है,[11][18] प्रतीक तालिकाओं या अतिरिक्त टिप्पणियों को संग्रहीत करने के लिए विभिन्न सॉफ़्टवेयर विकास उपयोगिताओं द्वारा उपयोग की जाने वाली सुविधा,[20][11][16][21][6] और थर्ड पार्टी एक्सटेंशन अन्य वर्णों को स्टार्ट कोड के रूप में उपयोग करते हैं जैसे केइल द्वारा अंक '0', [21] मोस्टेक द्वारा '$', [22][23] या '!', '@', '#', '\', '&' और ';' टीडीएल द्वारा.[23][24] अनुक्रम के अनुसार, '//' का प्रयोग प्रायः टिप्पणियों के लिए किया जाता है। इनमें से किसी भी एक्सटेंशन में पेलोड के हिस्से के रूप में कोई ':' अक्षर सम्मिलित नहीं हो सकता है।
  2. बाइट काउंट, दो हेक्स अंक (एक हेक्स अंक जोड़ी), डेटा फ़ील्ड में बाइट्स (हेक्स अंक जोड़े) की संख्या दर्शाती है। अधिकतम बाइट काउंट 255 (0xFF) है। 8 (0x08),[6]16 (0x10)[6]और 32 (0x20) सामान्यतः उपयोग की जाने वाली बाइट काउंट हैं। सभी सॉफ़्टवेयर 16 से बड़ी काउंट का सामना नहीं कर पाते।[5]
  3. एड्रेस, चार हेक्स अंक, डेटा के 16-बिट आरंभिक मेमोरी एड्रेस ऑफसेट का प्रतिनिधित्व करते हैं। डेटा के भौतिक एड्रेस की काउंट इस ऑफसेट को पहले से स्थापित आधार एड्रेस में जोड़कर की जाती है, इस टाइप 16-बिट एड्रेस की 64 किलोबाइट सीमा से परे मेमोरी एड्रेसिंग की अनुमति मिलती है। आधार एड्रेस, जो डिफ़ॉल्ट रूप से शून्य होता है, विभिन्न टाइप के रिकॉर्ड द्वारा बदला जा सकता है। आधार एड्रेस और एड्रेस ऑफसेट को निरंतर बड़े एंडियन मान के रूप में व्यक्त किया जाता है।
  4. रिकॉर्ड टाइप (नीचे रिकॉर्ड टाइप देखें), दो हेक्स अंक, 00 को 05, डेटा फ़ील्ड का अर्थ परिभाषित करना।
  5. डेटा, डेटा के n बाइट्स का एक क्रम, जिसे 2n हेक्स अंकों द्वारा दर्शाया जाता है। कुछ रिकॉर्ड इस फ़ील्ड को छोड़ देते हैं (n शून्य के बराबर है)। डेटा बाइट्स का अर्थ और व्याख्या एप्लिकेशन पर निर्भर करती है। (4-बिट डेटा को या तो बाइट्स के निचले या ऊपरी आधे हिस्से में संग्रहीत करना होगा, यानी, एक बाइट में केवल एक एड्रेस योग्य डेटा आइटम होता है।[11]
  6. अंततः, , दो हेक्स अंक, एक परिकलित मान जिसका उपयोग यह सत्यापित करने के लिए किया जा सकता है कि रिकॉर्ड में कोई त्रुटि नहीं है।

कलर लीजेंड

एक दृश्य सहायता के रूप में, इंटेल हेक्स रिकॉर्ड के क्षेत्र इस पूरे आलेख में निम्नानुसार रंगीन हैं:

  Start code   Byte count   Address   Record type   Data   Checksum

चेकसम काउंट

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

उदाहरण के लिए, रिकॉर्ड के स्थिति में :0300300002337A1E, डिकोड किए गए बाइट मानों का योग है 03 + 00 + 30 + 00 + 02 + 33 + 7A = E2, जिसका LSB मूल्य है E2. दोनों का पूरक E2 है 1E, जो रिकॉर्ड के अंत में प्रदर्शित होने वाला चेकसम बाइट है।

किसी रिकॉर्ड की वैधता को उसके चेकसम की काउंट करके और यह सत्यापित करके जांचा जा सकता है कि काउंट किया गया चेकसम रिकॉर्ड में दिखाई देने वाले चेकसम के बराबर है; यदि चेकसम भिन्न हैं तो एक त्रुटि का संकेत दिया जाता है। चूँकि रिकॉर्ड का चेकसम बाइट दोनों का पूरक है - और इसलिए डेटा चेकसम का योगात्मक व्युत्क्रम -, इस प्रक्रिया को रिकॉर्ड के चेकसम सहित सभी डिकोड किए गए बाइट मानों के योग तक कम किया जा सकता है, और यह सत्यापित किया जा सकता है कि योग का LSB शून्य है। जब पिछले उदाहरण पर लागू किया जाता है, तो यह विधि निम्नलिखित परिणाम उत्पन्न करती है: 03 + 00 + 30 + 00 + 02 + 33 + 7A + 1E = 100, जिसका LSB मूल्य 00है।

टेक्स्ट लाइन टर्मिनेटर

इंटेल हेक्स रिकॉर्ड सामान्यतः एक या अधिक ASCII लाइन समाप्ति वर्णों द्वारा अलग किए जाते हैं ताकि प्रत्येक रिकॉर्ड एक टेक्स्ट लाइन पर अकेला दिखाई दे। यह रिकॉर्ड्स को दृश्य रूप से सीमित करके पठनीयता को बढ़ाता है और यह रिकॉर्ड्स के बीच पैडिंग भी प्रदान करता है जिसका उपयोग मशीन पार्सिंग दक्षता में सुधार के लिए किया जा सकता है। हालाँकि, पंक्ति समाप्ति वर्ण वैकल्पिक हैं, क्योंकि ':' का उपयोग रिकॉर्ड की आरंभ का पता लगाने के लिए किया जाता है।[11][2][19][15][16][17][18]

हेक्स रिकॉर्ड बनाने वाले प्रोग्राम सामान्यतः लाइन टर्मिनेशन वर्णों का उपयोग करते हैं जो उनके ऑपरेटिंग सिस्टम की परंपराओं के अनुरूप होते हैं। उदाहरण के लिए, लिनक्स प्रोग्राम लाइनों को समाप्त करने के लिए एकल LF (लाइन फ़ीड, हेक्स वैल्यू 0A) वर्ण का उपयोग करते हैं, जबकि विंडोज प्रोग्राम LF के बाद सीआर (कैरिज रिटर्न, हेक्स वैल्यू 0D) का उपयोग करते हैं।

रिकॉर्ड टाइप

इंटेल हेक्स के छह मानक रिकॉर्ड प्रकार हैं:[9]

हेक्स कोड रिकार्ड टाइप विवरण उदाहरण
00 सांख्यिकी बाइट काउंट रिकॉर्ड में डेटा बाइट्स की संख्या निर्दिष्ट करती है। उदाहरण है 0B (ग्यारह) डेटा बाइट्स। डेटा के लिए 16-बिट प्रारंभिक एड्रेस (उदाहरण में प्रारंभ होने वाले एड्रेस पर 0010) और डेटा (61, 64, 64, 72, 65, 73, 73, 20, 67, 61, 70). :0B0010006164647265737320676170A7
01 फाइल समाप्त फ़ाइल के अंतिम रिकॉर्ड में प्रति फ़ाइल ठीक एक बार आना चाहिए। बाइट काउंट है 00, एड्रेस फ़ील्ड सामान्यतः है 0000 और डेटा फ़ील्ड छोड़ दिया गया है। :00000001FF
02 विस्तारित खंड एड्रेस बाइट काउंट निरंतर होती है 02, एड्रेस फ़ील्ड (सामान्यतः 0000) को नजरअंदाज कर दिया जाता है और डेटा फ़ील्ड में 16-बिट खंड आधार एड्रेस होता है। इसे 16 से गुणा किया जाता है और डेटा के लिए प्रारंभिक एड्रेस बनाने के लिए प्रत्येक बाद के डेटा रिकॉर्ड एड्रेस में जोड़ा जाता है। यह एड्रेस स्थान के एक mebibyte (1048576 बाइट्स) तक संबोधित करने की अनुमति देता है। :020000021200EA
03 प्रारंभ खंड एड्रेस 80x86 प्रोसेसर के लिए, प्रारंभिक निष्पादन एड्रेस निर्दिष्ट करता है। बाइट काउंट निरंतर होती है 04, एड्रेस फ़ील्ड है 0000 और पहले दो डेटा बाइट्स कोड ब्लॉक मान हैं, बाद वाले दो निर्देश सूचक मान हैं। निष्पादन इस एड्रेस पर प्रारम्भ होना चाहिए. :0400000300003800C1
04 विस्तारित रैखिक एड्रेस 32 बिट एड्रेसिंग (4 GiB तक) की अनुमति देता है। बाइट काउंट निरंतर होती है 02 और एड्रेस फ़ील्ड को अनदेखा कर दिया जाता है (सामान्यतः)। 0000). दो डेटा बाइट्स (बड़े एंडियन) बाद के सभी टाइप के लिए 32 बिट निरपेक्ष एड्रेस के ऊपरी 16 बिट्स निर्दिष्ट करते हैं 00 अभिलेख; ये ऊपरी एड्रेस बिट्स अगले तक लागू होते हैं 04 अभिलेख। किसी टाइप के लिए पूर्ण एड्रेस 00 रिकॉर्ड नवीनतम के ऊपरी 16 एड्रेस बिट्स को मिलाकर बनाया गया है 04 निम्न 16 एड्रेस बिट्स के साथ रिकॉर्ड करें 00 अभिलेख। यदि एक टाइप 00रिकॉर्ड के पहले कोई टाइप नहीं है 04 रिकॉर्ड करता है तो इसके ऊपरी 16 एड्रेस बिट्स डिफ़ॉल्ट रूप से 0000 होते हैं। :020000040800F2
05 रेखीय एड्रेस प्रारंभ करें बाइट काउंट निरंतर होती है 04, एड्रेस फ़ील्ड है 0000. चार डेटा बाइट्स 32-बिट एड्रेस वैल्यू (बिग-एंडियन) का प्रतिनिधित्व करते हैं। इसका समर्थन करने वाले सीपीयू के स्थिति में, यह 32-बिट एड्रेस वह एड्रेस है जिस पर निष्पादन प्रारम्भ होना चाहिए। :04000005000000CD2A

अन्य रिकॉर्ड टाइप का उपयोग वेरिएंट के लिए किया गया है, जिनमें 06 वेन और लेने द्वारा,[25] 0A, 0B, 0C, 0D और 0E बीबीसी/माइक्रो:बिट एजुकेशनल फाउंडेशन द्वारा,[26] और 81, 82, 83, 84, 85, 86, 87 और 88डिजिटल अनुसंधान द्वारा सम्मिलित हैं।[3][15]

नामांकित फॉर्मेट

1973/1974 में मूल 4-बिट/8-बिट इंटेलेक हेक्स पेपर टेप फॉर्मेट और इंटेलेक हेक्स कंप्यूटर पंच्ड कार्ड फॉर्मेट केवल एक रिकॉर्ड प्रकार 00 का समर्थन करता था।[27][28][20] रिकॉर्ड प्रकार 01.[11] का भी समर्थन करने के लिए 1975 के आसपास इसका विस्तार किया गया था इसमें प्रतीकात्मक डिबगिंग के लिए एक प्रतीक तालिका वाला एक वैकल्पिक हेडर सम्मिलित हो सकता है,[20][21][6] कोलन से पहले के रिकॉर्ड में सभी वर्णों को अनदेखा कर दिया जाता है।[11][2]

1978 के आसपास, इंटेल ने अपने विस्तारित इंटेललेक हेक्स फॉर्मेट में नए रिकॉर्ड प्रकार 02 और 03 (तत्कालीन नए 8086/8088 प्रोसेसर के खंडित पता स्थान के लिए समर्थन जोड़ने के लिए) प्रस्तुत किया था।

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

  • I8HEX फ़ाइलें केवल रिकॉर्ड टाइप 00 और 01 का उपयोग करती हैं।
  • I16HEX फ़ाइलें केवल रिकॉर्ड टाइप 00 द्वारा 03 का उपयोग करती हैं।[7]
  • I32HEX फ़ाइलें केवल रिकॉर्ड टाइप 00, 01, 04, और 05 का उपयोग करती हैं।

फ़ाइल उदाहरण

यह उदाहरण एक फ़ाइल दिखाता है जिसमें चार डेटा रिकॉर्ड हैं और उसके बाद फ़ाइल का अंत रिकॉर्ड है: :10010000214601360121470136007EFE09D2190140 :100110002146017E17C20001FF5F16002148011928 :10012000194E79234623965778239EDA3F01B2CAA7 :100130003F0156702B5E712B722B732146013421C7 :00000001FF

  Start code   Byte count   Address   Record type   Data   Checksum

वेरिएंट

इंटेल के स्वयं के विस्तार के अलावा, कई थर्ड पार्टी ने भी इंटेल हेक्स फॉर्मेट के वेरिएंट और एक्सटेंशन को परिभाषित किया है, जिसमें डिजिटल रिसर्च (तथाकथित "डिजिटल रिसर्च हेक्स फॉर्मेट" [15][3], ज़िलॉग, मोस्टेक, [ सम्मिलित हैं।[22][23] टीडीएल,[23][24] टेक्सास इंस्ट्रूमेंट्स, माइक्रोचिप,[29] सी'टी, वेन और लेने,[25] और बीबीसी/माइक्रो:बिट एजुकेशनल फाउंडेशन (अपने "यूनिवर्सल हेक्स फॉर्मेट" के साथ)[26] इनमें प्रोग्राम प्रवेश बिंदुओं और रजिस्टर सामग्री, डेटा फ़ील्ड में एक स्वैप किए गए बाइट ऑर्डर, अप्रयुक्त क्षेत्रों के लिए मान भरने, फ़्यूज़ बिट्स और अन्य अंतरों के बारे में जानकारी हो सकती है।

8086 प्रोसेसर के लिए डिजिटल रिसर्च हेक्स फॉर्मेट कोड, डेटा, स्टैक और अतिरिक्त सेगमेंट के बीच अंतर करने के लिए रिकॉर्ड टाइप जोड़कर सेगमेंट जानकारी का समर्थन करता है।[2][3][15]

CP/M-80 (और मोटोरोला 6809 के लिए XASM09) के लिए अधिकांश असेंबलर फ़ाइल के अंत को इंगित करने के लिए रिकॉर्ड टाइप 01h का उपयोग नहीं करते हैं, बल्कि इसके बजाय शून्य-लंबाई डेटा टाइप 00h प्रविष्टि का उपयोग करते हैं।[30] यह एकाधिक हेक्स फ़ाइलों के संयोजन को आसान बनाता है।[31][32][1]

टेक्सास इंस्ट्रूमेंट्स एक वेरिएंट को परिभाषित करता है जहां एड्रेस प्रोसेसर के रजिस्टरों की बिट-विड्थ पर आधारित होते हैं, बाइट्स पर नहीं।

माइक्रोचिप वेरिएंट INTHX8S[33] (INHX8L,[1] INHX8H[1]), INHX8M,[33][1][34] INHX16[33] (INHX16M[1] और INHX32[35] उनके पीआईसी माइक्रोकंट्रोलर को परिभाषित करता है।

अल्फ्रेड अर्नोल्ड के क्रॉस-मैक्रो-असेम्बलर AS,[1] वर्नर हेनिग-रोलेफ़ के 8051-एमुलेटर SIM51,[21] और मैथियास आर. पॉल के क्रॉस-कन्वर्टर BINTEL को इंटेल हेक्स फॉर्मेट में एक्सटेंशन को परिभाषित करने के लिए भी जाना जाता है।

यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Arnold, Alfred (2020) [1996, 1989]. "6.3. P2HEX". Macro Assembler AS - User's Manual. V1.42. Translated by Arnold, Alfred; Hilse, Stefan; Kanthak, Stephan; Sellke, Oliver; De Tomasi, Vittorio. Archived from the original on 2020-02-28. Retrieved 2020-02-28. […] For the PIC microcontrollers, the switch -m <0..3> allows to generate the three different variants of the Intel Hex format. Format 0 is INHX8M which contains all bytes in a Lo-Hi-Order. Addresses become double as large because the PICs have a word-oriented address space that increments addresses only by one per word. […] With Format 1 (INHX16M), bytes are stored in their natural order. This is the format Microchip uses for its own programming devices. Format 2 (INHX8L) resp. 3 (INHX8H) split words into their lower resp. upper bytes. […] Unfortunately, one finds different statements about the last line of an Intel-Hex file in literature. Therefore, P2HEX knows three different variants that may be selected […] :00000001FF […] :00000001 […] :0000000000 […] By default, variant 0 is used which seems to be the most common one. […] If the target file name does not have an extension, an extension of HEX is supposed. […]
  2. ↑ 2.0 2.1 2.2 2.3 2.4 2.5 "3.1. Intel 8086 Hex File Format". CP/M-86 Operating System - System Guide (PDF) (2nd printing, 1st ed.). Pacific Grove, California, USA: Digital Research. June 1981. pp. 15–16. Archived (PDF) from the original on 2020-02-28. Retrieved 2020-02-28. p. 16: […] The following are output from ASM-86 only: 81 same as 00, data belongs to code segment […] 82 same as 00, data belongs to data segment […] 83 same as 00, data belongs to stack segment […] 84 same as 00, data belongs to extra segment […] 85 paragraph address for absolute code segment […] 86 paragraph address for absolute data segment […] 87 paragraph address for absolute stack segment […] 88 paragraph address for absolute extra segment […] All characters preceding the colon for each record are ignored. […] (17 pages)
  3. ↑ 3.0 3.1 3.2 3.3 3.4 "Appendix C. ASM-86 Hexadecimal Output Format". CP/M-86 - Operating System - Programmer's Guide (PDF) (3 ed.). Pacific Grove, California, USA: Digital Research. January 1983 [1981]. pp. 97–100. Archived (PDF) from the original on 2020-02-27. Retrieved 2020-02-27. pp. 97–99: […] The Intel format is identical to the format defined by Intel for the 8086. The Digital Research format is nearly identical to the Intel format, but adds segment information to hexadecimal records. Output of either format can be input to GENCMD, but the Digital Research format automatically provides segment identification. A segment is the smallest unit of a program that can be relocated. […] It is in the definition of record types 00 and 02 that Digital Research's hexadecimal format differs from Intel's. Intel defines one value each for the data record type and the segment address type. Digital Research identifies each record with the segment that contains it. […] 00H for data belonging to all 8086 segments […] 81H for data belonging to the CODE segment […] 82H for data belonging to the DATA segment […] 83H for data belonging to the STACK segment […] 84H for data belonging to the EXTRA segment […] 02H for all segment address records […] 85H for a CODE absolute segment address […] 86H for a DATA segment address […] 87H for a STACK segment address […] 88H for an EXTRA segment address […] [1] (1+viii+122+2 pages)
  4. ↑ 4.0 4.1 4.2 4.3 "The Interactive Disassembler - Hexadecimal fileformats". Hex-Rays. 2006. Archived from the original on 2020-03-01. Retrieved 2020-03-01. [2]
  5. ↑ 5.0 5.1 "AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and others". Xilinx. 2010-03-08. Intel MCS-86 Hexadecimal Object - File Format Code 88. Archived from the original on 2020-03-03. Retrieved 2020-03-03.
  6. ↑ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 Roche, Emmanuel (2000-04-01). "The Intel HEX File Format". France: Newsgroup: comp.os.cpm. INTELHEX.WS4. Archived from the original on 2021-12-08. Retrieved 2021-12-08. […] the Intel HEX file format can contain much more than the "data bytes". As long as the lines do not start with a colon (":"), they can contain anything that you want. […] I once saw a big HEX file […] It contained, at the beginning, the source code of a PL/M program, followed, at the end, by the resulting HEX file produced by the PL/M compiler. […] I found another HEX file containing several lines of comments, not at the beginning or at the end, but separating several lines of "absolute records". […] it was from an "(Intel) 8008 Simulator". So, at the beginning of its use, it was well known that HEX files could contain explanations. […]
  7. ↑ 7.0 7.1 "Appendix D. MCS-86 Absolute Object File Formats: Hexadecimal Object File Format". 8086 Family Utilities - User's Guide for 8080/8085-Based Development Systems (PDF). Revision E (A620/5821 6K DD ed.). Santa Clara, California, USA: Intel Corporation. May 1982 [1980, 1978]. pp. D-8–D-13. Order Number: 9800639-04. Archived (PDF) from the original on 2020-02-29. Retrieved 2020-02-29.
  8. ↑ "LT Programming Hex File Format Documentation -- In Circuit Programming". Analog Devices, Inc. / Linear Technology. 2021. Archived from the original on 2021-03-07. Retrieved 2021-12-11.
  9. ↑ 9.0 9.1 9.2 Hexadecimal Object File Format Specification. Revision A. Intel. 1998 [1988-01-06]. Retrieved 2019-07-23. [3][4][5][6] (11 pages)
  10. ↑ "General: Intel Hex File Format". ARM Germany GmbH. Archived from the original on 2020-02-27. Retrieved 2017-09-06.
  11. ↑ 11.0 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 "Chapter 6. Microcomputer System Component Data Sheet - EPROMs and ROM: I. PROM and ROM Programming Instructions - B1. Intellec Hex Paper Tape Format / C1. Intellec Hex Computer Punched Card Format". MCS-80 User's Manual (With Introduction to MCS-85). Intel Corporation. October 1977 [1975]. pp. 6-75–6-78. 98-153D. Retrieved 2020-02-27. p. 6-76: […] In the Intel Intellec Hex Format, a data field can contain either 8 or 4-bit data. Two ASCII hexadecimal characters must be used to represent both 8 and 4-bit data. In the case of 4-bit data, only one of the characters is meaningful and must be specified on the Intel PROM/ROM Order Form. […] Preceding the first data field and following the last data field there must be a leader/trailer length of at least 25 null characters. Comments (except for a colon) may be placed on the tape leader. […] If the data is 4·bit, then either the high or low-order digit represents the data and the other digit of the pair may be any ASCII hexadecimal digit. […] [7][8] (NB. This manual also describes a "BPNF Paper Tape Format", a "Non-Intellec Hex Paper Tape Format" and a "PN Computer Punched Card Format".)
  12. ↑ Kildall, Gary Arlen (January 1980). "The History of CP/M, The Evolution of an Industry: One Person's Viewpoint". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. 5 (1): 6–7. #41. Archived from the original on 2016-11-24. Retrieved 2013-06-03. […] Programs had been written and tested by Intel's software group, consisting of myself and two other people, and we were ready for the real machine. […]
  13. ↑ Kildall, Gary Arlen (2016-08-02) [1993]. Kildall, Scott; Kildall, Kristin (eds.). Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry (Manuscript, part 1). Kildall Family. Archived (PDF) from the original on 2016-11-17. Retrieved 2016-11-17. (NB. Part 2 not released due to family privacy reasons.)
  14. ↑ Feichtinger, Herwig (1987). "1.8.5. Lochstreifen-Datenformate: Das Intel-Hex-Format" [1.8.5. Paper tape data formats]. Arbeitsbuch Mikrocomputer [Microcomputer work book] (in Deutsch) (2 ed.). Munich, Germany: Franzis-Verlag GmbH. pp. 240–243 [243]. ISBN 3-7723-8022-0. (NB. The book also describes a BNPF, a Motorola S and a MOS 6502 hex format.)
  15. ↑ 15.0 15.1 15.2 15.3 15.4 "4.3 Intel Hexadecimal File Format". Concurrent CP/M Operating System - Programmer's Reference Guide (PDF) (1 ed.). Pacific Grove, California, USA: Digital Research Inc. January 1984. pp. 4-9–4-12. Archived (PDF) from the original on 2021-12-11. Retrieved 2021-12-11. pp. 4-11–4-12: […] The following are output from ASM-86 only: 81 same as 00, data belongs to Code Segment […] 82 same as 00, data belongs to Data Segment […] 83 same as 00, data belongs to Stack Segment […] 84 same as 00, data belongs to Extra Segment […] *85 paragraph address for absolute Code Segment […] *86 paragraph address for absolute Data Segment […] *87 paragraph address for absolute Stack Segment […] *88 paragraph address for absolute Extra Segment […] * 85, 86, 87, and 88 are Digital Research Extensions. […] All characters preceding the colon for each record are ignored. […] (346 pages) (NB. This manual marks only types 85, 86, 87 and 88 as Digital Research extensions, as if types 81, 82, 83, 84 were not.)
  16. ↑ 16.0 16.1 16.2 16.3 "2.8. Microprocessor Formats, 2.8.1. Input Requirements: Intel Intellec 8/MDS Format. Select Code 83". Operator Guide To Serial I/O Capabilities of Data I/O Programmers - Translation-Format Package (PDF). Revision C. Data I/O Corporation. October 1980. pp. 2–10. 055-1901. Archived (PDF) from the original on 2020-03-01. Retrieved 2020-03-01. p. 2-10: […] Input […] This space can be used for line feed, carriage return or comments. […] Output […] 2) Each line ends with nonprinting line feed, carriage returns and nulls. […] (1+ii+19 pages)
  17. ↑ 17.0 17.1 17.2 "Intel Intellec 8/MDS Format, Code 83". Translation File Formats (PDF). Data I/O Corporation. 1987-09-03. pp. 22, 26–27, 52–53, 54. Archived (PDF) from the original on 2021-07-28. Retrieved 2020-03-01. pp. 22, 26, 52: […] Nonprinting Carriage Return, line feed, and nulls determined by null count […] (56 pages)
  18. ↑ 18.0 18.1 18.2 "Appendix B: Intel Hex and Intel Extended Hex Format - B.1 Common Format". Fujitsu Semiconductor Controller Manual: FR/F2MC Family Softune Linkage Kit Manual for V3 (PDF). Fujitsu Limited. 2001. pp. 319–525 [320–321]. Archived (PDF) from the original on 2021-12-12. Retrieved 2021-12-12. p. 321: […] (g) Generally, a control code (such as CR and LF) is added. Data in this field is skipped until the start character ":" of (a) appears. Since the (a), (b), (c), (d), and (f) fields always exist, the minimum length of a record is 11 bytes long and the maximum length is 521 bytes long. […] (4+x+350 pages)
  19. ↑ 19.0 19.1 "1.6.4 PIP". CP/M Operating System Manual (First printing ed.). Pacific Grove, California, USA: Digital Research. July 1982 [1976]. pp. 17–23. Retrieved 2021-12-12. pp. 19–21: […] PIP performs a special function if the destination is a disk file with type "HEX" (an Intel hex-formatted machine code file), and the source is an external peripheral device, such as a paper tape reader. In this case, the PIP program checks to ensure that the source file contains a properly formed hex file, with legal hexadecimal values and checksum records. When an invalid input record is found, PIP reports an error message at the console and waits for corrective action. It is usually sufficient to open the reader and rerun a section of the tape (pull the tape back about 20 inches). When the tape is ready for the reread, a single carriage return is typed at the console, and PIP will attempt another read. If the tape position cannot be properly read, the user continues the read (by typing a return following the error message), and enters the record manually with the ED program after the disk file is constructed. For convenience, PIP allows the end-of-file to be entered from the console if the source file is an RDR: device. In this case, the PIP program reads the device and monitors the keyboard. If ctl-Z is typed at the keyboard the read operation is terminated normally. […] PIP PUN:=NUL:,X.ASM,EOF:,NUL: […] Send 40 nulls to the punch device; copy the X.ASM file to the punch, followed by an end-of-file (ctl-Z) and 40 more null characters. […] H […] HEX data transfer: all data are checked for proper Intel hex file format. Nonessential characters between hex records are removed during the copy operation. The console will be prompted for corrective action in case errors occur. […] I […] Ignore ":00" records in the transfer of Intel hex format file (the I parameter automatically sets the H parameter). […] PIP PUN:=X.HEX[i],Y.ZOT[h] […] First copy X.HEX to the PUN: device and ignore the trailing ":00" record in X.HEX; continue the transfer of data by reading Y.ZOT, which contains HEX records, including any ":00" records it contains. […] [9] (6+250 pages)
  20. ↑ 20.0 20.1 20.2 "Appendix A: A Sample Program in PL/M: Hexidecimal Object Tape". MCS-8 A Guide to PL/M programming (PDF). Rev 1 (printed September 1974 ed.). 1974-03-15 [September 1973]. p. 102. MCS180-0774-1K, MCS280-0974-1K. Archived (PDF) from the original on 2022-01-29. Retrieved 2022-05-18. p. 102:
        1 CARRY 05714
        2 ZERO 05715
        3 SIGN 05716
        4 PARITY 05717
        5 MEMORY 06000
       23 SQUAREROOT 04003
    […]
       83 MONITORUSES 05766
     $
    ****************************************
    :1008000044520A2E0B36D0F930FA31CF30D730F9B6
    […]
    :100AF0000936F4C730D70401C8C20C0031F930F808
    :040B0000445E0AFF46
    ****************************************
    :0000000000
     $     (1+i+100+1+11+1 pages) (NB. Shows an example containing asterisk-based separators and a space-indented header with symbol names to be processed by Intel ISIS's HEXOBJ command as well as by INTERP/8 or INTERP/80 for symbolic debugging. This optional header is not documented as part of Intel hex or BNPF formats but in Intel's PL/M and assembler programming manuals producing such symbol tables.)
  21. ↑ 21.0 21.1 21.2 21.3 Hennig-Roleff, Werner (1993-02-01) [1988]. "HEX.DOC: Intel-HEX-Format". SIM51. 1.04 (in Deutsch). Archived from the original on 2017-08-11. Retrieved 2021-12-08. […] Beim Absolut-Hex Konvertierprogramm von Keil können optional […] Symbol-Informationen in den Hex-File aufgenommen werden. Die Symbol-Informationen stehen dabei am Anfang des Files, vor dem ersten ':'. Die Symbol-Informationen sind allerdings nicht sehr aussagekräftig, da nicht unterschieden wird zwischen Modul-Name, CODE, XDATA, DATA, IDATA, BIT, NUMBER. Für jeden Symboleintrag werden nur ASCII-Zeichen verwendet. Pro Zeile ist 1 Symbol angeschrieben und zwar in der Form: "0 SymbolName Wert" […] [10][11] (NB. This is an older version of SIM51, the software and documentation was maintained up to 1996. The HEX.DOC file also describes the EASM51 hex format used by the elektor assembler.)
  22. ↑ 22.0 22.1 Formaniak, Peter G.; Leitch, David (July 1977). "A Proposed Microprocessor Software Standard". BYTE - the small systems journal. Technical Forum. Vol. 2, no. 7. Peterborough, New Hampshire, USA: Byte Publications, Inc. pp. 34, 62–63. ark:/13960/t32245485. Retrieved 2021-12-06. (3 pages) (NB. Describes an extension of the Intel hex format by Mostek.)
  23. ↑ 23.0 23.1 23.2 23.3 Ogdin, Carol Anne; Colvin, Neil; Pittman, Tom; Tubb, Philip (November 1977). "Relocatable Object Code Formats". BYTE - the Small Systems Journal. Technical Forum. Peterborough, New Hampshire, USA: Byte Publications, Inc. 2 (11): 198–205. ark:/13960/t59c88b4h, ark:/13960/t3kw76j24. Retrieved 2021-12-06. (8 pages) (NB. Besides others describes an incompatible extension of the Intel hex format used by Technical Design Labs (TDL).)
  24. ↑ 24.0 24.1 Kreidl, Günter (June 1981). "Relocator: Das TDL-Format". Hardware. Nascom journal - Zeitschrift für Anwender des NASCOM 1 oder NASCOM 2 (in Deutsch). Germersheim, Germany: Verlag NASCOM Journal, MK-Systemtechnik. 2 (6): 12–14 [12]. Archived from the original on 2021-12-01. Retrieved 2021-12-11. (20 pages) (NB. Shows a variant of the TDL format, which itself is a variant of the Intel hex format.)
  25. ↑ 25.0 25.1 Beckler, Matthew L. (2016-07-25) [2016-07-19]. "Blinky Grid - serial optical bit stream". Discourse. Minneapolis, Minnesota, USA: Wayne and Layne, LLC. Archived from the original on 2021-12-11. Retrieved 2021-12-11.
  26. ↑ 26.0 26.1 "micro:bit Universal Hex Format Specification - Specification for the micro:bit Universal Hex Format". micro:bit. 0.4.0. Micro:bit Educational Foundation. 2021-01-26 [2020]. Archived from the original on 2021-08-14. Retrieved 2021-12-08. [12][13] (NB. This represents kind of a fat hex file format.)
  27. ↑ Intellec 8 Microcomputer System Operator's Manual. Intel Corporation. November 1973.
  28. ↑ "Appendix D. Hexadecimal Program Tape Format". Intellec 8/MOD 80 Operators Manual. Intel. June 1974. 98-003A. […] Frames 7,8: Record Type […] Two ASCII characters. Currently (1974), all records are type 0. This field is reserved for future expansion […] [14]
  29. ↑ "PIC Microcontrollers: PIC Hex File Format". Kanda Electronics Blog. Canolafan, Llanafan, Aberystwyth, Wales, UK: Embedded Results Ltd. 2012-04-26. Archived from the original on 2021-08-16. Retrieved 2021-12-11.
  30. ↑ Kildall, Gary Arlen (February 1978) [1976]. "A simple technique for static relocation of absolute machine code". Dr. Dobb's Journal of Computer Calisthenics & Orthodontia. People's Computer Company. 3 (2): 10–13 (66–69). ISBN 0-8104-5490-4. #22 ark:/13960/t8hf1g21p. Retrieved 2017-08-19. [15][16][17]. Originally presented at: Kildall, Gary Arlen (1977) [22–24 November 1976]. "A Simple Technique for Static Relocation of Absolute Machine Code". Written at Naval Postgraduate School, Monterey, California, USA. In Titus, Harold A. (ed.). Conference Record: Tenth Annual Asilomar Conference on Circuits, Systems and Computers: Papers Presented November 22–24, 1976. Asilomar Conference on Signals, Systems & Computers. Asilomar Hotel and Conference Grounds, Pacific Grove, California, USA: Western Periodicals Company. pp. 420–424. ISSN 1058-6393. Retrieved 2021-12-06. (609 pages)
  31. ↑ Zschocke, Jörg (November 1987). "Nicht nur Entwicklungshilfe - Down-Loading für Einplatinencomputer am Beispiel des EPAC-09: Intel-Hex-Format". c't - magazin für computertechnik (in Deutsch). Vol. 1987, no. 11. Verlag Heinz Heise GmbH & Co. KG. pp. 198, 200, 202–203, [200]. ISSN 0724-8679. […] Den Vorspann beschließt ein Byte, dessen Wert den Typ des Blockes angibt: 0 = Datenblock, 1 = Endblock. Auf diese Unterscheidung kann jedoch verzichtet werden, wenn sich ein Endblock auch durch eine Blocklänge gleich Null eindeutig kennzeichnen läßt. (So verfahren die meisten Assembler unter CP/M, auch der XASM09; das Typbyte ist dann immer Null). […] [18] (NB. XASM09 is a Motorola 6809 assembler.)
  32. ↑ Prior, James E. (1989-02-24). "Re: Intel hex (*.HEX) format questions". Newsgroup: comp.os.cpm. Retrieved 2020-02-27.
  33. ↑ 33.0 33.1 33.2 "PIC16C5X Programming Specification 5.0 - PIC16C5X Hex Data Formats: 5.1. 8-Bit Split Intellec Hex Format (INHX8S) / 5.2. 8-Bit Merged Intellec Hex Format (INHX8M) / 5.3. 16-Bit Hex Format / 5.4. 8-Bit Word Format / 5.5. 16-Bit Word Format". Microchip Databook (1994 ed.). Microchip Technology Inc. April 1994. pp. 3-10–3-11, 9-10, 9-15, 9-17, 9-21, 9-23, 9-27. DS00018G. Retrieved 2020-02-28. […] Assemblers for the PIC16C5X can produce PIC16C5X object files in various formats. A PIC16C5X programmer must be able to accept and send data in at least one of following formats. The 8-bit merged (INHX8M) format is preferred. […] format […] INHX8S […] produces two 8-bit Hex files. One file will contain the address / data pairs for the high order 8-bits and the other file will contain the low order 8-bits. File extensions for the object code will be '.obl' and '.obh' for low and high order files […] format […] INHX8M […] produces one 8-bit Hex file with a low byte / high byte combination. Since each address can only contain 8 bits in this format, all addresses will be doubled. File extensions for the object code will be '.obj' […] format […] INHX16 […] produces one 16-bit Hex file. File extension for the object code will be '.obj'. […] [19][20]
  34. ↑ Beard, Brian (2016) [2010]. "Microchip INHX8M HEX-record Format". Lucid Technologies. Archived from the original on 2020-02-28. Retrieved 2020-02-28.
  35. ↑ Beard, Brian (2016) [2013]. "Microchip INHX32 HEX-record Format". Lucid Technologies. Archived from the original on 2020-02-28. Retrieved 2020-02-28.


अग्रिम पठन

  • "How Do I Interpret Motorola S & Intel HEX Formatted Data? Intel Hex-32, Code 99". Home > Hardware > … > In-circuit Test Systems > Automated Test Equipment [Discontinued] > Details. Keysight Technologies. Archived from the original on 2020-03-01. Retrieved 2020-03-01.
  • Bergmans, San (2019-06-02) [2001]. "Intel HEX Format". SB-Projects. Archived from the original on 2020-03-01. Retrieved 2020-03-01.
  • Beard, Brian (2016) [2007]. "Intel HEX-record Format". Lucid Technologies. Archived from the original on 2020-02-28. Retrieved 2020-02-28.
  • Anderson, Thomas N. (February 1998). "Intel Hex Word Address Object Format". The Telemark Assembler (TASM) User's Manual (PDF). 3.1. Issaquah, Washington, USA: Squak Valley Software. pp. 25–26. Archived (PDF) from the original on 2021-12-11. Retrieved 2021-12-11. Intel Hex Word Address Object Format […] This format is identical to the Intel Hex Object Format except that the address for each line of object code is divided by two thus converting it to a word address (16 bit word). All other fields are identical. Here is an example: […] :180800000102030405060708090A0B0C0D0E0F101112131415161718AC […] :02080C00191AA3 […] :00000001FF […] (32 pages)


बाहरी संबंध

  • binex - a converter between Intel हेक्स and binary for Windows.
  • SRecord, a converter between Intel हेक्स and binary for Linux (usage), C++ source code.
  • kk_ihex, open source C library for reading and writing Intel हेक्स
  • libgis, open source C library that converts Intel हेक्स, Motorola S-Record, Atmel Generic files.
  • bincopy is a Python package for manipulating Intel हेक्स files.
  • SwiftIntelHex - a Swift package to parse Intel हेक्स files for iOS and macOS.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=इंटेल_हेक्स&oldid=251258’