MS-DOS और अन्य टेक्स्ट मोड प्रोग्राम डबल-चौड़ाई CJK वर्ण कैसे प्रदर्शित कर सकते हैं?

Question

मैंने जापानी और चीनी में कई टेक्स्ट मोड BIOS सेटअप स्क्रीन देखे हैं। हाल ही में मैंने जापानी में Windows XP सेटअप भी देखा है। MS-DOS के जापानी संस्करण भी थे। रियल डॉस मोड , विंडोज कमांड प्रॉम्प्ट नहीं!

एक विशिष्ट टेक्स्ट मोड स्क्रीन का आकार 80x25 है । जापानी चरित्र के साथ डबल सामान्य लैटिन चरित्र चौड़ाई जितनी बड़ी थी, स्क्रीन पर एक ही समय में प्रदर्शित किए जा सकने वाले जापानी वर्णों की अधिकतम संख्या लगभग 1000 है। इसलिए हमें वर्णों के बाएँ और दाएँ भाग को प्रदर्शित करने के लिए 2000 कोड बिंदुओं की आवश्यकता है ।

जैसे कि डिफ़ॉल्ट पाठ मोड केवल 256 वर्ण प्रदर्शित कर सकता है, लेकिन पहले 128 का उपयोग ASCII के लिए किया जाता है, इसलिए प्रयोग करने योग्य उच्च 128 अंक तक सीमित होते हैं। यदि आवश्यक हो तो हम इसे 512 तक विस्तारित कर सकते हैं लेकिन यह अभी भी प्रदर्शन के लिए पर्याप्त कोड बिंदुओं का समर्थन नहीं कर सकता है। मुझे हमेशा आश्चर्य होता है कि वे इतने सीमित पात्रों के साथ सेट किए गए बड़े चरित्र को कैसे प्रदर्शित करने में कामयाब रहे।

[ ]]]

लिनक्स में टेक्स्ट मोड ग्राफिक्स मोड ड्राइवर का उपयोग करता है क्योंकि यह यूनिकोड प्रदर्शित कर सकता है और इसमें बहुत अधिक रंग हैं। लेकिन मैं यह नहीं समझा सकता कि वे इसे MS-DOS और BIOS सेटअप स्क्रीन में कैसे करते हैं।

---

संपादित करें: मैंने डॉस के लिए एक जापानी पाठ इनपुट भी पाया है

पाठ मोड में भी कोरियाई हैं!

Comments

आप शायद जापानी "वर्णों" यानी कांजी को नहीं देख रहे हैं , बल्कि हिरागाना या कटकाना , जिसमें यूनिकोड मैपिंग है।

— चूरा

@sawdust: ऊपर दी गई तस्वीर को देखें और आप देखेंगे कि यह न केवल सभी काना बल्कि कांजी

— phuclv

ध्यान दें कि आपके द्वारा संभावित रूप से OS / 2 इंस्टॉलर स्क्रीनशॉट से लिया गया पेज स्क्रीनशॉट के ठीक बगल में कहता है कि "OS / 2 को बूट करते समय ग्राफिकल टेक्स्ट मोड सपोर्ट को लगभग तुरंत शुरू किया गया था"। कुंजी शब्द चित्रमय ।

— बजे एक CVn

@ माइकलकॉर्जिंग यह न केवल ओएस / 2 है, बल्कि एमएस-डॉस और BIOS सेटअप प्रोग्राम्स में पाठ मोड में भी यह क्षमता है

— phuclv

Answer 1

सामान्य "80x25 वर्ण" मोड वास्तव में 720x350 पिक्सेल है (जिसका अर्थ है कि प्रत्येक वर्ण सेल 14 पिक्सेल उच्च द्वारा 9 पिक्सेल चौड़ा है)। डबल-चौड़ाई वाले वर्ण मोड ("40x25") या तो केवल वीडियो सामग्री मेमोरी पर सहेजने के लिए प्रत्येक कॉलम को दोगुना करके बड़ी चौड़ाई में इसे प्रक्षेपित कर सकते हैं (आधे हिस्से में वीडियो सामग्री मेमोरी की आवश्यक मात्रा में कटौती), या अतिरिक्त ग्लिफ़ मेमोरी और एक समान का उपयोग करें चरित्र कोशिकाओं को 18 * 14 पिक्सेल तक बढ़ाने के लिए वीडियो सामग्री मेमोरी की मात्रा।

बहुत जल्दी (मुझे लगता है कि यह तब किया गया था जब ईजीए पेश किया गया था), आईबीएम पीसी के पाठ प्रदर्शन मोड में उपयोगकर्ता-परिभाषित चरित्र ग्लिफ़ के लिए समर्थन जोड़ा गया था।

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

इसका मतलब है कि जब तक आप किसी एक समय में स्क्रीन पर 256 अलग-अलग ग्लिफ़ के साथ कर सकते हैं, और प्रत्येक ग्लिफ़ को 9x14 एक-बिट बिटमैप के रूप में दर्शाया जा सकता है, तो आप पात्रों को अलग तरह से बनाने के लिए बस ग्लिफ़ को मेमोरी में बदल सकते हैं । भाग में, यह mode con codepage selectडॉस पर किया गया एक हिस्सा था। यह अपेक्षाकृत तुच्छ है।

यदि आपको 256 से अधिक अलग-अलग ग्लिफ़ की आवश्यकता है, लेकिन स्क्रीन पर ग्लिफ़ की कम संख्या के साथ रह सकते हैं, तो आप 40x25 स्कीम के साथ डबल-चौड़ाई (18 पिक्सेल चौड़ा) ग्लिफ़ के साथ जा सकते हैं। यह मानते हुए कि वीडियो सामग्री RAM की कुल मात्रा निर्धारित है और यह मानते हुए कि आप ग्लिफ़ बिटमैप मेमोरी बढ़ा सकते हैं, आप प्रत्येक चार बाइट्स में से दो बाइट्स का उपयोग करके एक-स्क्रीन ग्लिफ़ का प्रतिनिधित्व कर सकते हैं, जिससे आपको 2 = 16 तक पहुँच प्राप्त होगी। 65,536 विभिन्न ग्लिफ़ (खाली ग्लिफ़ सहित)। यदि आप साहसी महसूस करते हैं, तो आप दूसरी विशेषता बाइट को भी छोड़ सकते हैं जो आपको 2 ^ 24 ~ 16.7M विभिन्न ग्लिफ़ तक पहुंच प्रदान करता है। ये दोनों दृष्टिकोण विशेष सॉफ़्टवेयर समर्थन पर निर्भर करते हैं, लेकिन हार्डवेयर और फ़र्मवेयर भाग को करना बहुत आसान होना चाहिए। 18x14 एक-बिट पिक्सल में 65,536 ग्लिफ़, लगभग 2 MiB के लिए काम करते हैं, जो उस समय एक बड़ी स्मृति योग्य नहीं, बल्कि दुर्गम मात्रा है।

मूल अमेरिकी अंग्रेजी में कम से कम 62 समर्पित ग्लिफ़ (संख्या 0-9, अक्षर AZ ऊपरी और निचले मामले में) की आवश्यकता होती है, इसलिए आपके पास खेलने के लिए 180-190 ग्लिफ़ जैसा कुछ है यदि आप भी उसी पर यूएस अंग्रेज़ी पाठ प्रदर्शित करने में सक्षम होना चाहते हैं समय और प्रति ग्लिफ़ 8 बिट्स के साथ जाना। यदि आप एक साथ अमेरिका के अंग्रेजी समर्थन के बिना रह सकते हैं, जिसे आप संसाधन-विवश वातावरण में चुन सकते हैं, जैसे कि आईबीएम पीसी आर्किटेक्चर, आपके पास ग्लिफ़ की पूरी संख्या तक पहुंच है।

कुछ प्रवंचनाओं के साथ आप शायद दो योजनाओं को भी मिला सकते हैं और मेल कर सकते हैं।

मुझे नहीं पता कि यह वास्तव में कैसे किया गया था, लेकिन इन दोनों के लिए व्यवहार्य योजनाएं हैं कि विशेष रूप से सीमित-चरित्र-गिनती "फैंसी" वर्णमाला को टेक्स्ट मोड में एक सादे आईबीएम पीसी स्क्रीन पर कैसे प्राप्त किया जाए कि मैं सिर्फ सामने बैठकर आ सकता हूं एक पल के लिए स्टैक एक्सचेंज। यह पूरी तरह से संभव है कि अतिरिक्त ग्राफिक्स मोड हैं जो अभ्यास में इसे आसान बनाते हैं।

इसके अलावा, टेक्स्ट प्रदर्शित करने वाले टेक्स्ट मोड और ग्राफ़िकल मोड के बीच अंतर को ध्यान में रखें । यदि आप चित्रमय विधा में हैं, तो शायद VESA के माध्यम से, जो बहुत सार्वभौमिक रूप से समर्थित है, आप अपने दम पर हैं जहाँ तक ड्रॉइंग कैरेक्टर ग्लिफ़ जाते हैं, लेकिन आपको उन्हें खींचने में बहुत अधिक स्वतंत्रता है। उदाहरण के लिए, मुझे पूरा यकीन है कि Windows NT (जो कि उत्पाद परिवार Windows XP है) का पाठ-आधारित भाग, पाठ को प्रदर्शित करने के लिए एक चित्रमय विधा का उपयोग करता है, जिसमें Windows NT 4.0 बूट स्क्रीन और बीएसओडी शामिल हैं।

Comments

आप देख सकते हैं कि जापानी / कोरियाई लोगों की डबल चौड़ाई के साथ सामान्य चौड़ाई के लैटिन वर्ण हैं, इसलिए यह 40x25 डबल चौड़ाई मोड नहीं हो सकता है। इसलिए आप ग्लिफ़ का प्रतिनिधित्व करने के लिए हर 4 बाइट्स के 2 बाइट्स को जोड़ नहीं सकते हैं। अग्रभूमि रंग के बिट 3 का उपयोग करके आप एक ही समय में 512 ग्लिफ़ का प्रतिनिधित्व कर सकते, लेकिन अभी भी नहीं पर्याप्त है, तो वर्ण स्क्रीन का ज़्यादातर हिस्सा en.wikipedia.org/wiki/VGA-compatible_text_mode#Fonts

— phuclv

@ LưuV LnhPhúc आप उच्च बिट repossess कर सकते हैं, या सिंगलबी के साथ मल्टीबाइट-आवश्यक पात्रों को मिलाने के लिए किसी भी अन्य संभव चाल की किसी भी संख्या का उपयोग कर सकते हैं। मुझे अभी भी लगता है कि इसका उत्तर ओपनिंग पैराग्राफ में दिए गए स्टेटमेंट को पहचानना है: वर्णों को दिखाते समय, कुछ स्तर पर आप अभी भी पिक्सल्स के साथ काम कर रहे हैं, और उन पिक्सल्स के साथ काम किया जा सकता है, हालांकि सीधे सीधे नहीं।

— एक CVn

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

— phuclv

Answer 2

यह सरल कर रहा है @Michael Kjörling क्या कह रहा है।

पाठ मोड में, आपके पास "स्क्रीन मेमोरी" होती है जिसमें 1 बाइट प्रति ऑनस्क्रीन चरित्र होता है जो एडेप्टर को बताता है कि प्रत्येक स्क्रीन पोजीशन में कौन सा वर्ण दिखाई देता है। ("विशेषता" बाइट्स भी हैं जो एडेप्टर को बताते हैं कि रंग और चीजें जैसे कि अंडरलाइन, ब्लिंक, आदि)।

एडेप्टर इस बाइट को दूसरे "वर्ण तालिका" में अनुक्रमित करने के लिए उपयोग करता है जिसमें छोटे 8x12 या वर्ण का जो भी बिटमैप है। डॉस इस कैरेक्टर टेबल को एक कोड पेज कहता है।

सीजीए के साथ शुरू, आप एडॉप्टर की रैम में एक विशिष्ट स्थान पर वर्ण तालिका प्राप्त करने के लिए एडेप्टर को बता सकते हैं। प्रत्येक एडेप्टर में एक चरित्र ROM होता है जिसमें उस कार्ड के लिए डिफ़ॉल्ट "फ़ॉन्ट" होता है (जो कि मानक आईबीएम फ़ॉन्ट है), लेकिन आप एडॉप्टर को रैम में किसी स्थान पर स्विच करने और वहां अपनी खुद की छवियां डालने के लिए कह सकते हैं।

जब तक सॉफ़्टवेयर जानता है कि क्या हो रहा है, स्क्रीन मेमोरी में कोड जो वर्ण तालिका में छवियों को इंगित करते हैं, उनके पास किसी भी ASCII कोड के साथ लाइन अप नहीं है, हालांकि यह आसान है अगर वे करते हैं। आप देखेंगे कि 1-31 के लिए स्क्रीन मेमोरी कोड (और कैरेक्टर टेबल शेप) हैं जो कि अप्रमाणित ASCII वर्ण हैं - लेकिन स्क्रीन मेमोरी को सीधे लिखकर ( DEFSEG = &HB800 : POKE 0,1GW-BASIC में याद रखने वाली यादों को ऊपरी चरित्र को स्माइली में बदलने के लिए) मन) आप अभी भी उन्हें प्रदर्शित कर सकते हैं।

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

Comments

क्या यह सीजीए के रूप में जल्दी था? मुझे बूढ़ा होना ही है। (मेरे बचाव के लिए, मैंने उस उत्तर को स्मृति से बड़े पैमाने पर लिखा था, और वास्तव में उन तकनीकों का इस्तेमाल हमेशा के लिए मज़े के लिए भी नहीं किया है।)

— एक CVn

मुझे लगता है कि आप इसे देखने के बाद सही हैं, यह ईजीए था।

— लॉरेंस सी

मुझे पता है कि हम सूचक को बदलकर पाठ फ़ॉन्ट बदल सकते हैं, मैंने सीखा है कि यह कैसे करना है साल पहले, बस पता नहीं कैसे वे डबल बाइट चरित्र सेट का प्रतिनिधित्व कर सकते हैं, क्योंकि 256 या 512 कोड अंक भी पकड़ नहीं सकते हैं स्क्रीन पर अलग-अलग वर्णों की अधिकतम संख्या, पूरे जटिल

— वर्णक्रम

Answer 3

मुझे विकिपीडिया में "वीजीए-संगत पाठ मोड" पृष्ठ में और कुछ वीजीए प्रोग्रामिंग पुस्तकों में भी कुछ मिला:

ईजीए और वीजीए दोनों पाठ मोड स्क्रीन पर एक साथ 512 ग्लिफ़ की अनुमति देते हैं, या 2 बैंक 256 ग्लिफ़ प्रत्येक के साथ। एट्रीब्यूट बिट 3 (फोरग्राउंड कलर इंटेंसिटी) भी बैंक ए या बी के बीच चयन कर सकता है। सामान्य रूप से ऐसा होता है कि डिफ़ॉल्ट रूप से ए और बी दोनों फ़ॉन्ट रजिस्टर एक ही पते पर इंगित करते हैं, जिससे आपको केवल 256 ग्लिफ़ मिलते हैं। तो, यह काम करने के लिए, आपको सही आदतों के लिए फ़ॉन्ट रजिस्टर सेट करना होगा।

प्रत्येक बैंक में 8192 बाइट्स हैं, और बैंक के 256 ग्लिफ़ों में से प्रत्येक में 32 बाइट्स (8 पिक्सेल चौड़ा और 32 पिक्सेल लंबा) है। आप अपने पात्रों की सही ऊंचाई बताने के लिए स्कैनलाइन काउंट रजिस्टर सेट कर सकते हैं। वीजीए कार्ड 400 स्कैनलाइन ऑनस्क्रीन प्रिंट करते हैं जबकि ईजीए 350 स्कैनलाइन ऑनस्क्रीन प्रिंट करते हैं, इसलिए, आपको 25 वर्ण पंक्तियों को देने के लिए, वे क्रमशः अपने चरित्र की ऊंचाई 16 और 14 स्कैनलाइन पर सेट करते हैं। इसके अलावा, वीजीए में प्रत्येक ग्लिफ़ में 8 या 9 डॉट्स चौड़े हो सकते हैं, लेकिन 9 वां कॉलम या तो खाली होता है या सिर्फ 8 वां कॉलम रिपीट होता है। दोनों बैंकों में ये सभी ग्लिफ़ उपयोगकर्ता-परिभाषित हो सकते हैं।

आप कुछ भाषाओं में ऑनस्क्रीन 256 से अधिक विभिन्न पात्रों को कैसे प्राप्त कर सकते हैं? ऊपर दिए गए उदाहरणों में, प्रत्येक विशेष विदेशी चरित्र दो ग्लिफ़ (बाएं और दाएं), या अधिक से बना है। आप ASCII पाठ के लिए बैंक ए के अलावा, पहले से कहे गए १२ for ग्लिफ़ को पहले सेट कर सकते हैं, और आपके पास कस्टमाइज़ करने के लिए बैंक B + ३ gly४ ग्लिफ़ से बैंक A + २५० ग्लिफ़ से १२ from ग्लिफ़ होंगे।

इसके अलावा, आप एक विशाल चरित्र सेट बनाने के लिए अलग-अलग बाएं और दाएं किनारों को जोड़ सकते हैं! उदाहरण के लिए, मान लें कि 384 उपयोगकर्ता-परिभाषित ग्लिफ़ से, आप 184 को बाईं ओर के लिए और 200 को दाएँ-बाएँ के लिए आरक्षित करना चाहते हैं: आपके पास 184 * 200 = 36800 विभिन्न वर्ण हो सकते हैं! (निश्चित रूप से, उनमें से अधिकांश शायद उस भाषा के लिए अमान्य वर्ण होंगे, लेकिन फिर भी आपको अच्छी संख्या में मान्य संयोजन मिल सकते हैं)।

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

अंत में, शुरुआती पीसी युग में BIOS स्ट्रिंग फ़ंक्शन यूनिकोड-जागरूक नहीं थे, लेकिन यह होना जरूरी नहीं है। आपको बस अपने 512 ग्लिफ़ को अनुकूलित करना था और सही EGA या VGA रजिस्टर सेट करना था। उदाहरण के लिए, आप "!" "" # $ ""% ^ "" और * "çé" "ñs" ग्लिफ को अपने विदेशी पात्रों (बैंक ए या बी में) को अनुकूलित कर सकते हैं, और फिर BIOS प्रिंट कर सकते हैं "! @ # S% ^ & * çéñ S "एक ही बार में स्ट्रिंग। BIOS ग्लिफ़ की जांच नहीं करेगा। आप BIOS फ़ंक्शन का उपयोग बिल्कुल भी नहीं कर सकते, क्योंकि आप सीधे वीडियो मेमोरी में लिख सकते हैं। बैंक बी से एक ग्लिफ़ का उपयोग करने के लिए, बस 8 और 15 (चमकीले रंग) के बीच के मूल्य के लिए फोरग्राउंड कलर विशेषता सेट करें।

(मेरी बुरी अंग्रेजी के लिए खेद है)

Comments

मुझे पता है कि हमारे पास 512 वर्ण हो सकते हैं जैसा कि प्रश्न में उल्लेख किया गया है। हालाँकि बात यह है कि ऊपर दिए गए कार्यक्रम वास्तविक कांजी पात्रों को प्रदर्शित कर रहे हैं , काना को नहीं, जो एक ही समय में प्रदर्शित होने वाली चीजों की संख्या में काफी वृद्धि करता है। सीमित एन्कोडिंग वाली प्रणालियों में अर्ध-चौड़ाई वाले कटकाना का उपयोग किया जाएगा, जिसमें अलग-अलग मारू और टेनन हैं, इसलिए समान कोड बिंदु का उपयोग し और half, या は और can दोनों के लिए किया जा सकता है, बाएं और दाएं हिस्से को साझा करने की कोई आवश्यकता नहीं है:

— फ़ुक्लेव

Answer 4

मैंने कुछ शोध किया और जैसा कि मैंने अनुमान लगाया था, आपको ग्राफिक्स मोड का उपयोग करना होगा या विशेष हार्डवेयर समर्थन की आवश्यकता होगी क्योंकि वीजीए पाठ मोड में 512 से अधिक वर्णों का उपयोग करने का कोई तरीका नहीं है

ठीक है, डॉस स्वयं 1-बाइट-प्रति-चार से आगे के वर्णमाला में प्रिंट नहीं कर सकता है, क्योंकि यह BIOS फ़ंक्शन का उपयोग करता है जो बदले में वीजीए हार्डवेयर का उपयोग करते हैं जिसमें 2 x 256 चार्ट आकार से अधिक फोंट नहीं हो सकते हैं। तो यह फिर से एक ड्रिवर के लिए एक नौकरी की तरह लगता है, जो व्यापक फोंट को प्रस्तुत करने के लिए ग्राफिक्स मोड का उपयोग करता है। हमारे पास पहले से ही कुछ ग्राफ़िकल डॉस पाठ संपादकों और समान (धन्यवाद :-)) में यूनिकोड फोंट के लिए समर्थन है और क्या DBCS या UTF-8 का उपयोग किया जाता है, दोनों "चरित्र का आकार एक या एक से अधिक बाइट्स" संभाल कर सकते हैं "विसंगति" ।

क्या फ्रीडोस में जापानी भाषा के लिए कभी कोई आधिकारिक समर्थन होगा?

डॉस (DOS / वी) के जापानी संस्करण पहले दृष्टिकोण का उपयोग करता है और पाठ मोड simulates द्वारा ग्राफ़िक्स मोड में पात्रों प्रतिपादन एक विशेष ड्राइवर के प्रयोग से। ड्राइवर IBM V-Text मानक का अनुसरण करता है जो DOS की पाठ प्रदर्शन क्षमताओं को बढ़ाने के लिए एक तंत्र है। आप इस तरह के विभिन्न 16/24/32/48-डॉट फोंट के बीच चयन कर सकते हैं

कुछ अन्य टेक्स्ट मोड सिस्टम भी उसी तकनीक का उपयोग करते हैं। FreeDOS में आप जापानी समर्थन के लिए कुछ विशेष ड्राइवर लोड कर सकते हैं

रेंडरर इंट 10h और int 21h कॉल को इंटरसेप्ट करेगा और टेक्स्ट को मैन्युअल रूप से ड्रा करेगा, इसलिए यह सामान्य अंग्रेजी कार्यक्रमों के लिए भी काम करेगा। लेकिन यह उन कार्यक्रमों के लिए काम नहीं करेगा जो सीधे वीजीए मेमोरी में लिखते हैं। जापानी वर्णों की छपाई के लिए int 5h और int 17h भी आदी हैं।

डॉस / वी मैनुअल के अनुसार बाद में आईबीएम BIOS ने नीचे के 4 नए कार्यों के साथ int 15h के माध्यम से V-पाठ के लिए समर्थन भी जोड़ा

5010H Video extension information acquisition
5011H Video extension function registration
5012H Video extension driver release
5013H Video extension driver lock setting

मुझे लगता है कि यही कारण है कि मैंने अपने पुराने पीसी के BIOS में जापानी समर्थन देखा

फिर भी ग्राफिक्स मोड की सुस्ती स्क्रॉल करते समय ग्लिच का परिचय दे सकती है जिसे विशेष हैंडलिंग की आवश्यकता होती है

डॉस / वी वास्तव में जापानी टेक्स्ट मोड के लिए पहला सॉफ्टवेयर समाधान है

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

डॉस / वी: हार्ड (वेयर) समस्याओं के लिए सॉफ्ट (वेयर) समाधान

उसी लेख के अनुसार, डॉस / वी अन्य प्रणालियों के आविष्कार से पहले सभी को हार्डवेयर में कांजी रोम की आवश्यकता होती है

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

उदाहरण के लिए आईबीएम पर्सनल सिस्टम / 55 जो जापानी फ़ॉन्ट के साथ एक विशेष ग्राफिक्स एडेप्टर का उपयोग करता है, इसलिए उन्हें वास्तविक टेक्स्ट मोड मिलता है

1980 के दशक की शुरुआत में, IBM जापान ने एशियाई-प्रशांत क्षेत्र, IBM 5550 और IBM JX के लिए दो x86- आधारित व्यक्तिगत कंप्यूटर लाइनें जारी कीं। 5550 ने डिस्क से कांजी फोंट पढ़ा, और 1024 x 768 उच्च रिज़ॉल्यूशन मॉनिटर पर ग्राफिक पात्रों के रूप में पाठ आकर्षित किया।

https://en.wikipedia.org/wiki/DOS/V#History

IBM 5550 के समान, टेक्स्ट मोड 1040x725 पिक्सेल (12x24 और 24x24 पिक्सेल फ़ॉन्ट, 80x25 वर्ण) 8 रंगों में था, फ़ॉन्ट ROM से पढ़े गए जापानी वर्ण प्रदर्शित कर सकते हैं

कुल्हाड़ी वास्तुकला मानक ईजीए के बजाय एक विशेष जेगा अनुकूलक का उपयोग करता है

AX (आर्किटेक्चर eXtended) एक जापानी कंप्यूटिंग पहल थी जो 1986 के आसपास शुरू हुई थी, जिसमें PC को डबल-बाइट (DBCS) जापानी टेक्स्ट को विशेष हार्डवेयर चिप्स के माध्यम से संभालने की अनुमति दी गई थी, जबकि विदेशी IBM PC के लिए लिखे गए सॉफ़्टवेयर के साथ संगतता की अनुमति थी।

...

पर्याप्त स्पष्टता के साथ कांजी पात्रों को प्रदर्शित करने के लिए, एक्सएक्स मशीनों में उस समय कहीं और 640x350 मानक ईजीए संकल्प के बजाय 640x480 के संकल्प के साथ जेईजीए (जेए) स्क्रीन थे। उपयोगकर्ता आमतौर पर 'JP' और 'US' लिखकर जापानी और अंग्रेजी मोड के बीच स्विच कर सकते हैं, जो AX-BIOS और IME को जापानी वर्णों के इनपुट को सक्षम करने का भी आह्वान करेगा।

बाद के संस्करण भी VGA पर सॉफ्टवेयर इम्यूलेशन के लिए एक विशेष AX-VGA / H हार्डवेयर और AX-VGA / S जोड़ते हैं

हालाँकि, AX की रिलीज़ के तुरंत बाद, IBM ने VGA मानक जारी किया जिसके साथ AX स्पष्ट रूप से संगत नहीं था (वे गैर-मानक "सुपर EGA" एक्सटेंशन को बढ़ावा देने वाले एकमात्र नहीं थे)। नतीजतन, AX कंसोर्टियम को संगत AX-VGA (ja) डिजाइन करना पड़ा। AX-VGA / H, AX-BIOS के साथ एक हार्डवेयर कार्यान्वयन था, जबकि AX-VGA / S एक सॉफ्टवेयर एमुलेशन था।

कम उपलब्ध सॉफ़्टवेयर और अन्य समस्याओं के कारण, AX विफल रहा और जापान में PC-9801 के प्रभुत्व को तोड़ने में सक्षम नहीं था। 1990 में, IBM जापान ने DOS / V का अनावरण किया, जिसने IBM PC / AT और इसके क्लोन को एक मानक VGA कार्ड का उपयोग करके बिना किसी अतिरिक्त हार्डवेयर के जापानी पाठ प्रदर्शित करने में सक्षम बनाया। इसके तुरंत बाद, AX गायब हो गया और NEC PC-9801 की गिरावट शुरू हुई।

परिषद पीसी-98 श्रृंखला भी प्रदर्शन नियंत्रक में एक चरित्र ROM है

एक मानक पीसी -98 में दो µPD7220 डिस्प्ले कंट्रोलर (एक मास्टर और एक दास) क्रमशः 12 केबी मुख्य मेमोरी और 256 केबी वीडियो रैम है। मास्टर डिस्प्ले कंट्रोलर फ़ॉन्ट ROM को हैंडल करता है, JIS X 0201 (7x13 पिक्सल) और JIS X 0208 (15x16 पिक्सल) वर्णों को प्रदर्शित करता है

मैं चीनी और कोरियाई के लिए स्थिति नहीं जानता, लेकिन मुझे लगता है कि समान तकनीकों का उपयोग किया जाता है। मुझे यकीन नहीं है कि कोई अन्य तरीके हैं जो हासिल करने के लिए हैं या नहीं

Answer 5

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

http://www.mobilefish.com/tutorials/windows/windows_quickguide_dos_unicode.html

Comments

नहीं, मेरे द्वारा पोस्ट की गई छवियों को देखें, यह वास्तविक डॉस मोड है, विंडोज़ में कमांड

— प्रोम

लेख में शीर्षक पूरी तरह से गलत और भ्रामक है। cmd.exe DOS जैसा नहीं है और टर्मिनल इंटरफ़ेस DOS और कुछ इसी तरह के कमांड के समान है। क्या कमांड प्रॉम्प्ट और एमएस-डॉस एक ही चीज हैं?

— फुल्विक