"कलर एक्सटेंडर फॉर ज़ेडएक्स-स्पेक्ट्रम" - यह 3 अगस्त, 1997 को इको फ़िडो 7.zx.spectrum में प्रकाशित लेख का शीर्षक है । लेख में जेडएक्स-स्पेक्ट्रम प्लेटफॉर्म की मुख्य समस्याओं में से एक को हल करने के विचार का वर्णन किया गया है - विशेषता टकराव । प्रकाशन ने उस समय कुछ रुचि पैदा की, और मैं तकनीकी विवरण और मुद्दे के इतिहास के बारे में बताना चाहूंगा।

मैं तकनीकी विवरणों में गहराई से नहीं जाऊंगा और सिर्फ संरचनात्मक रूप से विचार और समाधान का वर्णन करूंगा।

मानक वीडियो मोड जेडएक्स-स्पेक्ट्रम, 192 पिक्सल द्वारा 256 प्रदर्शित करता है। मोनोक्रोम मोड में, इसके लिए केवल 6144 बाइट्स की आवश्यकता होती है, जो कि कुल मेमोरी फ़ील्ड का लगभग 10% (BK-0010 पर 50% के विरुद्ध) है। पिक्सेल डेटा के तुरंत बाद स्थित अतिरिक्त 768 बाइट्स में रंग जानकारी संग्रहीत की जाती है। पैलेट में आठ रंग और दो रंग होते हैं। प्रबुद्ध और त्याग किए गए पिक्सेल का रंग तुरंत 8 पिक्सेल ब्लॉक द्वारा 8 के लिए निर्धारित किया जाता है, और रंग तुरंत प्रकाशित और त्याग दिए गए पिक्सेल के रंग के लिए निर्धारित किया जाता है।

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

जेडएक्स-स्पेक्ट्रम 128 के लिए मंच के विकास के साथ, वीडियो मेमोरी के दो पृष्ठों के बीच हार्डवेयर स्विच करने की क्षमता जोड़ी गई थी। प्रोग्रामर ने प्रदर्शित वीडियो पेजों के त्वरित परिवर्तन और रंग विशेषताओं के गतिशील परिवर्तन का उपयोग करके जल्दी से बहु-रंग प्राप्त करने का एक तरीका ढूंढ लिया।

इसके कारण, स्क्रीन रिज़ॉल्यूशन को प्रोग्रामेटिक रूप से उठाना संभव हो गया था (जो कि पूरी तरह से दिखाया गया है, उदाहरण के लिए, "डेड मोरोज़" डेमो में, जहां एक ही समय में टेक्स्ट 256, 512 और 768 अंकों के क्षैतिज रूप से रिज़ॉल्यूशन के साथ चलता है)।

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

मेरा विचार था कि आप तीन और प्रोसेसर जोड़ सकते हैं, उनमें से प्रत्येक को उनके रंग घटक के प्रसंस्करण पर फेंक सकते हैं। प्रत्येक प्रोसेसर की अपनी वीडियो मेमोरी से प्राप्त डेटा को एकीकृत किया जाना चाहिए, जिससे प्रत्येक पिक्सेल के लिए YRGB मूल्य हो। मानक रंग विशेषताओं को अनदेखा किया जाता है। सूचना के समानांतर प्रसंस्करण को सुनिश्चित करना चाहिए कि कोई भी प्रदर्शन नहीं है।

मैं यह नहीं कह सकता कि यह विचार में मूल था, क्योंकि यह अनुवाद पुस्तक "द कंप्यूटर गेन्स माइंड" (मीर पब्लिशिंग हाउस, 1990) के पढ़ने से प्रेरित था, जिसमें लुकासफिल्म में विकसित एक निश्चित पिक्सार ग्राफिक्स प्लेटफॉर्म का वर्णन किया गया था। और TRIZ के अनुसार , यह मोनो-सिस्टम से पॉली-सिस्टम के लिए एक संक्रमण है।

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

मुझे लगता है कि यह अवधारणा किसी भी पुराने घरेलू मंच (उदाहरण के लिए, AGAT, Radio86RK, BK-0010, आदि) पर लागू होती है, जहां कोई समर्पित वीडियो त्वरक नहीं है और प्रोसेसर चित्र बनाने के लिए वीडियो मेमोरी के साथ सीधे काम करता है।

एमुलेटर के पहले संस्करण में, मैंने सिर्फ चार ZX-Spectrum 48s को सिंक्रोनाइज़ करने का काम किया है। लेकिन एमुलेटर पर अनुकरण करने में जो आसान है वह असली हार्डवेयर पर दोहराना बहुत मुश्किल है। चार कंप्यूटिंग मॉड्यूल में डेटा को लोड करना सुनिश्चित करना और एक ही पते से एक तुल्यकालिक शुरुआत करना काफी मुश्किल है। इसी तरह का एक समाधान Spec256 इस विशेष आभासी 64-बिट SIMD Z80 के लिए पेश करता है, जो प्रकृति में मौजूद नहीं है। इस समस्या के अधिक यथार्थवादी (और अधिक जटिल) समाधान के हिस्से के रूप में, जेडएक्स-पॉली प्लेटफॉर्म का गठन किया गया था।

"कलर एक्सटेंडर" से ZX-Poly तक

प्रोसेसर मॉड्यूल

ZX-Poly एक कंप्यूटिंग प्लेटफॉर्म है जो ZX-Spectrum 128 पर आधारित है जिसमें चार प्रोसेसर मॉड्यूल हैं। प्रत्येक मॉड्यूल का अपना बाहरी दृश्यमान पता योग्य सिस्टम IO पोर्ट होता है। हालांकि प्रोसेसर मॉड्यूल सिस्टम कंट्रोल सिग्नल (RESET, NMI, CLK, और INT) साझा करते हैं, वे स्वतंत्र रूप से काम करते हैं।

मॉड्यूल के सूचकांक के आधार पर एक निश्चित रैंकिंग है - छोटे सूचकांक, क्रमशः उच्च रैंक, "मॉड्यूल 0" सिस्टम में मास्टर है। मॉड्यूल के सिस्टम पोर्ट तक पहुंच को केवल उसी या उच्च रैंक वाले मॉड्यूल की अनुमति है, कोई रीडिंग प्रतिबंध नहीं है। ऐसा इसलिए किया गया क्योंकि एक विशेष ओएस विकसित करने के बारे में विचार थे।

एक बहुत ही महत्वपूर्ण विवरण यह है कि उपयोग किए जाने वाले सभी प्रोसेसर डिवाइस एक ही निर्माता के होने चाहिए (और यह एक उत्पादन श्रृंखला के लिए अच्छा होगा), क्योंकि उनके आंतरिक संगठन या अनुकूलन में मामूली अंतर सिस्टम की स्थिरता का उल्लंघन कर सकता है।

सिस्टम की शुरुआत के तुरंत बाद, केवल मास्टर मॉड्यूल (CPU0) लॉन्च किया जाता है, शेष मॉड्यूल WAIT मोड में होते हैं, इसलिए उपयोगकर्ता के लिए सब कुछ किसी का ध्यान नहीं जाता है।

IO स्पेस में, ZX-Poly लिखने और पढ़ने के लिए उपलब्ध निम्नलिखित पोर्ट जोड़ता है:

• मुख्य विन्यास बंदरगाह $ 3D00
• मॉड्यूल 0 - $ 00FF, $ 10FF, $ 20FF, $ 30FF
• मॉड्यूल 1 - $ 01FF, $ 11FF, $ 21FF, $ 31FF
• मॉड्यूल 2 - $ 02FF, $ 12FF, $ 22FF, $ 32FF
• मॉड्यूल 3 - $ 03FF, $ 13FF, $ 23FF, $ 33FF

मुख्य ZX-Poly कॉन्फ़िगरेशन पोर्ट $ 3D00 है। केवल मास्टर मॉड्यूल ही इसे लिख सकता है, लेकिन यह सभी मॉड्यूलों को पढ़ने के लिए उपलब्ध है और इसकी प्रत्येक विशेष जानकारी लौटा दी जाती है। विशेष रूप से, एक मॉड्यूल अपने सूचकांक का पता लगा सकता है, चाहे उसकी मेमोरी को मुख्य मॉड्यूल के IO पोर्ट्स पर मैप किया गया हो, ढेर में इसकी मेमोरी की ऑफसेट आदि। इसके अलावा, बेस प्लेटफॉर्म $ 7FFD के कॉन्फ़िगरेशन पोर्ट में मामूली बदलाव हुए हैं, जो मूल में अप्रयुक्त बिट्स का उपयोग करता है।

स्मृति

ZX- स्पेक्ट्रम 128 की मूल वास्तुकला में, ROM और RAM हैं। यदि संगठन और ROM के साथ काम करना व्यावहारिक रूप से नहीं बदला, तो RAM 512 KB का एक आम "ढेर" में बदल गया, जिसमें प्रत्येक प्रोसेसर एक समर्पित 128 KB विंडो के साथ काम करता है (यह ZX-स्पेक्ट्रम 128 में 16 KB का 8 पृष्ठ है)। विंडो ऑफसेट को 64 Kb के इंक्रीमेंट में बदला जा सकता है और सभी प्रोसेसर मॉड्यूल को ढेर में मेमोरी के पूर्ण या आंशिक रूप से अतिव्यापी टुकड़े के साथ काम करने का अनुमान लगाया जा सकता है। ROM को निष्क्रिय किया जा सकता है और RAM0 RAM पेज को इसके स्थान पर जोड़ा जाएगा (यह आपको आधार ओएस का "पूर्ण-रंग" संस्करण बनाने की अनुमति देता है, उदाहरण के लिए, एक बुनियादी दुभाषिया)। एक हार्डवेयर RESET के बाद, सभी मॉड्यूल हीप में मेमोरी विंडो को डिसाइड करने के लिए स्वचालित ऑफ़सेट प्राप्त करते हैं।

प्रोसेसर मॉड्यूल मास्टर (CPU0), अन्य मॉड्यूल (CPU1-3) के एड्रेस स्पेस को अपने ओओ पोर्ट के क्षेत्र में मैप करने की क्षमता रखता है। यानी वह पोर्ट को लिख सकता है, किसी दिए गए मॉड्यूल की मेमोरी सेल की स्थिति को बदल सकता है, और एक ही समय में, मैप किए गए मॉड्यूल पर एनएमआई सिग्नल उत्पन्न करना संभव है। एक मैप किए गए मॉड्यूल की मेमोरी कोशिकाओं से पढ़ते समय, INT पीढ़ी संभव है। यह मॉड्यूल 1-3 का उपयोग करके आभासी उपकरणों का अनुकरण करने के लिए किया गया था।

वीडियो नियंत्रक

मुख्य "चेरी" निश्चित रूप से एक वीडियो नियंत्रक है, इसके लिए सब कुछ शुरू किया गया था। कुल मिलाकर, मंच पांच वीडियो मोड का समर्थन करता है।

जेडएक्स-स्पेक्ट्रम 128 वीडियो मोड (मोड 0,1,2,3)

ये वीडियो मोड अचूक हैं और मानक ZX-स्पेक्ट्रम 128 वीडियो मोड से बिल्कुल अलग नहीं हैं। विशेषता रंग के साथ चयनित प्रोसेसर मॉड्यूल का वर्तमान वीडियो पृष्ठ प्रदर्शित किया गया है। सिस्टम की शुरुआत के तुरंत बाद, मोड 0 सक्रिय हो जाता है, अर्थात। मास्टर मॉड्यूल (CPU0) का वीडियो पृष्ठ प्रदर्शित होता है।

ZX-Poly 256x192 (मोड 4)

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

प्रत्येक मॉड्यूल इसके घटक के लिए जिम्मेदार है:

• मॉड्यूल 0 (मास्टर) ग्रीन (हरा) के लिए।
• लाल (लाल) के लिए मॉड्यूल 1
• ब्लू (नीला) के लिए मॉड्यूल 2
• चमक के लिए मॉड्यूल 3

यदि आप इस विधा में एक अनपेक्षित खेल शुरू करते हैं, तो यह बस काला और सफेद होगा।

INX + पेपर द्वारा मास्किंग के साथ ZX-Poly 256x192 (मोड 6)

पिछले एक की तरह, यह प्रत्येक बिंदु के लिए 16 रंग प्रदान करता है, लेकिन एक "चाल" है। कुछ ZX- स्पेक्ट्रम कार्यक्रमों में, ग्राफिक तत्वों को समान रूप से INK और PAPER मानों का उपयोग करके विशेषताओं में छिपाया जाता है, विशेष रूप से स्कोरर गेम्स में। यदि आप इस अवसर को हटाते हैं, तो चित्र को तोड़ते हुए ग्राफिक तत्व स्क्रीन पर जमा होने लगते हैं। इसलिए, INK और PAPER की स्थिति का विश्लेषण वीडियो मेमोरी (CPU0) से पढ़े गए मास्टर मॉड्यूल की विशेषता से किया जाता है और यदि वे समान हैं, तो सभी बिंदुओं को INK / PAPER (निश्चित रूप से चमक को ध्यान में रखते हुए) से लिए गए रंग के साथ हाइलाइट किया जाता है।

ZX-Poly 256x192 फ्लैश के साथ मास्किंग + INK + पेपर (मोड 7)

मोड 4 मोड और मोड 6 का संयोजन है। मास्टर मॉड्यूल (CPU0) की पठनीय विशेषताओं के लिए, FLASH बिट का विश्लेषण किया जाता है और यदि इसे सेट किया जाता है (जो कि खेल के मैदान में गतिशील खेलों में दुर्लभ है), तो 8 बाय 8 पिक्सेल ब्लॉक मोड 6 मोड में प्रदर्शित किया जाता है। समान INK और पेपर के साथ मास्किंग के साथ)। यदि FLASH रीसेट हो जाता है, तो ब्लॉक को नियमित ZX-Spectrum के रूप में प्रदर्शित किया जाता है। FLASH बिट का अपनी प्रत्यक्ष भूमिका में अभ्यास नहीं किया गया है और इसमें कोई ब्लिंकिंग नहीं होगी।
खेल सूचना पैनल और कुछ इन-गेम प्रभाव (उदाहरण के लिए, जब गेम डेवलपर्स विशेषताओं के माध्यम से खेल के मैदान पर फ्लैश करते हैं) से बचने के लिए यह मोड बहुत सुविधाजनक है।

ZX-Poly 512x384 विशेषताओं के साथ (मोड 5)

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

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

इस वीडियो मोड में बहुत बेहतर प्रभाव पाठ अनुप्रयोगों पर प्राप्त किया गया था, उदाहरण के लिए, जेडएक्स-वर्ड टेक्स्ट एडिटर पर, जहां फॉन्ट को निष्पादन योग्य कोड में बदलाव के बिना संसाधित किया गया था।

मल्टीटास्किंग

इस तथ्य के बावजूद कि सिस्टम में प्रोसेसर नियंत्रण संकेतों के समान स्रोत का उपयोग करते हैं, वे स्वतंत्र रूप से काम करते हैं। सिस्टम को पूर्ण-विकसित SIMD नहीं कहा जा सकता है , क्योंकि प्रत्येक प्रोसेसर अपने स्वयं के मेमोरी ब्लॉक से निर्देशों को संसाधित करता है, समान निर्देशों को "पाम ऑफ" करने की क्षमता बस उपयोग की जाती है। , " " — .

, , "". , .

RESET

RESET , . JP ADDR .

-

master- (CPU0). , ( M1), WAIT, RESET. , , 16 .

2007 JavaSE . Z80 ( -) FDD 181893. JDK 1.8+ .

ZX-Spectrum , 80% , . ZX-Spectrum 128, Options->ZX 128 Mode , ZX-Poly .

-, ZX-Spectrum — . , File->Options

- , . , .

, . TAP TR-DOS .

( Java) .

GitHub GNU GPLv3 .