NES Elite - NES के लिए Elite का दस्तावेज़ीकृत source code

 (github.com/markmoxon)
1 पॉइंट द्वारा GN⁺ 2023-10-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Ian Bell और David Braben के NES के लिए Elite source code में हर लाइन के साथ documentation है, अधिकतर में explanations भी दिए गए हैं, और इसे original game binary की disassembly से हाथ से reconstruct किया गया है
  • आधुनिक कंप्यूटर पर source से पूरी तरह चलने वाला game build करके iNES ROM image बनाया जा सकता है, जिसे असली NES या emulator में load किया जा सकता है
  • समर्थित variants Imagineer PAL variant और Ian Bell की निजी वेबसाइट का NTSC variant हैं; default build PAL variant है
  • source explore करने के तरीके: elite.bbcelite.com पर human-readable रूप में देखना, या IDE में annotated source खोलना; वेबसाइट और source files की सामग्री समान है
  • build requirements हैं BeebAsm, Python, और Mac/Linux पर make; Python build केवल 3.x पर test किया गया है और Windows में make.exe शामिल है
    • Windows पर make.bat, Mac/Linux पर make से build होता है, और default output 5-compiled-rom-images folder में elite-pal.NES है
    • variant=ntsc से elite-ntsc.NES बनाया जा सकता है
  • build options variant selection, maximum के करीब test commander का उपयोग, original binary matching छोड़ना, crc32 verification disable करना आदि control करते हैं
    • प्रतिनिधि example है make variant=ntsc commander=max match=no verify=no
    • crc32.py generated file और original source से निकाली गई reference file के checksum और file size को साथ-साथ compare करता है
  • PAL और NTSC variants में NMI handler cycle count, Start screen का Imagineer/Nintendo heading, combat demo auto-play wait time, save slot checksum algorithm, internal version number, hidden copyright message, scroll text, y-coordinate constants आदि में फर्क है
  • NTSC variant असली NTSC hardware पर काम नहीं करता; यह कुछ emulators के NTSC mode के लिए NMI timing बदला हुआ NTSC emulation है
  • कोई license file नहीं है; default copyright law लागू होता है, जिससे केवल पढ़ना और fork करना allowed है, जबकि reproduction, distribution और derivative works बनाना allowed नहीं है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-09
Hacker News की राय

  • बहुत पहले Frontier में काम करते समय David Braben से NES Elite के बारे में एक मज़ेदार किस्सा सुना था। मुझे याद था कि शुरू में NES के हार्डवेयर timer से वास्तविक समय track किया जाता था, ताकि frame rate अलग होने पर भी physics समान रूप से चले
    Nintendo के pre-release inspection में कहा गया कि शुरुआती NES की कुछ units में वह timer ठीक से काम नहीं करता, इसलिए उसे इस्तेमाल नहीं किया जा सकता। मैंने सुना था कि इस वजह से Bell/Braben ने हर function ने उस frame में कितने clock cycles खर्च किए, इसका अपना अनुमान बनाए रखा और frame के अंत में उन्हें जोड़कर बीता हुआ समय estimate किया
    लेकिन GitHub source देखने पर लगता है कि या तो मेरी याद गलत थी या मैंने Braben की बात सही से नहीं समझी थी। elite-source-bank-7.asm में comment है: “NES द्वारा support न किए जाने वाले hardware timer के बजाय इस्तेमाल किए जा सकने वाले NMI timer को update करता है”, और ऐसा लगता है कि non-maskable interrupts गिनकर pseudo real-time clock implement की गई थी

    • शायद यादें मिल गई होंगी। रिलीज़ हुए NES के किसी भी revision में hardware timer नहीं था
      शुरुआती NES CPU die में एक buggy और disabled programmable interval timer के अवशेष थे: https://www.nesdev.org/wiki/RP2A03_Programmable_Interval_Tim...
      बाद के revisions में इसे पूरी तरह हटा दिया गया, और संभव है कि यह केवल development kit जैसी चीज़ों में enabled रहा हो। अगर consumer devices पर काम न करने वाले feature पर depend किया गया था, तो Nintendo testing में reject होना स्वाभाविक था
      मान भी लें कि released console में programmable interval timer था, तब भी वह precise raster effects जैसे sub-frame measurements के लिए ही उपयोगी होता। वास्तविक समय मापने के लिए NMI count कहीं ज़्यादा उचित है। NMI हर video frame की शुरुआत में fire होता है और 60.0988Hz पर बहुत stable रहता है; game engine धीमा होकर frame rate बदल भी दे, तो CPU-side processing video signal timing को प्रभावित नहीं कर सकती
      संदर्भ के लिए, audio hardware भी timer interrupts बना सकता है, और कई expansion chips में rendering sync के लिए scanline counters होते हैं। NES पर समय मापने के तरीकों की कमी नहीं है
    • BEAM Software(Melbourne House) के Andrew Davie से भी कुछ ऐसा ही सुना था। उन्होंने Super Glove Ball develop किया था, और उनका कहना था कि Nintendo ने meaningful documentation बहुत कम दी, इसलिए frame rate calculation जैसी चीज़ों में कई hacks लगाने पड़े
      जब वे किसी game को Nintendo से approve कराने की कोशिश कर रहे थे, तो सुना कि वह US version NES के किसी specific version पर काम नहीं करता था या system overheating कर देता था। release schedule tight था, इसलिए उन्हें समस्या solve करने Nintendo headquarters तक उड़कर जाना पड़ा, और मुझे याद है कि उस specific version की circulation 100 units से कम थी
      बाद में एक unpublished book के notes मिले, और असल में बात थोड़ी अलग थी। game testing केवल gameplay तक सीमित नहीं थी; उसे हर उस NES console variant पर test करना होता था जिस पर वह चल सकता था। Beam Software के Andrew Davie ने याद किया कि “The Three Stooges” ने Washington के Nintendo office में testing वाले NES पर problem पैदा की थी, इसलिए वे खुद वहाँ गए थे
      उन्होंने कहा कि game pass कराने के लिए अलग-अलग chip manufacturer combinations सहित “लगभग 23 तरह की machine variants” थीं, और official documentation की कमी के कारण उन्होंने sprite data को official recommendation की तरह RAM में लिखने के बजाय हर 2 सेकंड में सीधे लिखवाया, जिससे NES बहुत गर्म हो जाता था और पूरे game में sprites flicker करते थे। fix के बाद release approval मिल गया, और उन्हें बताया गया कि problematic NES combination पूरे US में करीब 5 units ही था, इसलिए उसे Nintendo testing lineup से हटा दिया गया

  • हाल ही में sequel Elite: Dangerous शुरू किया, और कुछ problems होने के बावजूद अनुभव काफ़ी शानदार है
    1984 वाले version से चले आ रहे game elements देखना अजीब तरह से भावुक कर देने वाला था। उस समय की cutting-edge 16K memory-mapped screen की vector graphics में दिखने वाले ships, और खासकर Coriolis station, जब 4K/60fps में पूरी 3D rendering में बदले दिखे, तो यह उम्मीद से ज़्यादा emotional लगा
    billboards, plants और docking equipment तक के साथ detailed Coriolis interior आखिरकार देखना सच कहूँ तो आंखें थोड़ी नम कर देने वाला था। अभी मुश्किलें हों तब भी यह game एक precious legacy है, और उम्मीद है कि किसी न किसी रूप में बना रहेगा

    • Elite Dangerous मुझे वाकई बहुत पसंद आया। console support बंद होने के बाद से नहीं खेला, लेकिन repetitive tasks और shallow content के बावजूद दोस्तों के साथ ships उड़ाने का समय याद आता है
      Blue Danube सुनते हुए spaceship को manually dock करना हमेशा सुकून देने वाला अनुभव था
      सोचता हूँ कि space simulators और space games में हमेशा इतनी समस्याएँ क्यों आ जाती हैं। Elite Dangerous कहीं आगे बढ़ता नहीं दिखता, Star Citizen हमेशा का beta लगता है, और KSP2 भी निराशाजनक था
    • open beta के समय से Elite: Dangerous लंबे समय तक खेला। यह खूबसूरत game है, और sound design कमाल का है
      9 साल पहले लिखे विचार: https://hypertexthero.com/elite-dangerous-education/
      Odyssey expansion भी मज़ेदार है, और उम्मीद है कि कभी EVA spacewalks और zero-gravity missions भी जोड़े जाएँगे

  • मूल के लगभग वफादार C संस्करण Elite - The New Kind भी मौजूद है: https://github.com/fesh0r/newkind
    इसे Christian Pinder ने बनाया था: https://www.christianpinder.com/games/
    Ian Bell का Elite homepage भी देखने लायक है, जहाँ कई मूल versions मौजूद हैं: http://www.ianbellelite.com/

    • Ian Bell और उनकी website का ज़िक्र निश्चित रूप से होना चाहिए। यही वह जगह है जहाँ BBC Micro version का original source code मिल सकता है, और वही original disks NES project सहित मेरे सभी Elite annotation work का आधार हैं
      1991 के NES version का core, यानी 128K ROM का लगभग 30%, मूलतः 1986 का BBC Master version है, जो खुद 1984 के original BBC Micro version का विकसित रूप है। Commodore 64 और Apple II versions भी इसी वंश से हैं, और development भी BBC Micro पर ही हुआ था
      banks 0, 1, 2 का ज़्यादातर code सीधे original BBC version से लिया गया था, और bank 7 में भी कुछ और हिस्सा है। ऊपर से नए graphics, sound और controller routines जोड़े गए, लेकिन धड़कता दिल अब भी Beeb version ही है

  • Elite के लेखक Ian Bell ने NES version को अपना पसंदीदा 8-bit Elite version कहा था
    कुल मिलाकर, उन्होंने कहा था कि उन्हें 32-bit Archimedes port सबसे ज़्यादा पसंद था

    • मूल quote यह है: “तकनीकी रूप से मेरी प्रकाशित सबसे बड़ी उपलब्धि BBC cassette version ‘Elite’ को screen सहित 32K RAM में फिट करना, और character mapping display तथा single NES controller का इस्तेमाल करके Nintendo Entertainment System के लिए ‘Elite’ conversion करना था। NES मेरा पसंदीदा published conversion है, और जब तक हमने इसे कर नहीं दिखाया था, इसे तकनीकी रूप से संभव नहीं माना जाता था।”
      पूरा interview http://www.elitehomepage.org/archive/b5081501.htm पर है
      मैं इसका मतलब यह समझता हूँ कि उनका पसंदीदा version BBC Micro cassette version है, और पसंदीदा conversion NES version है। हालाँकि हो सकता है कि BBC fanboy होने के नाते मैं आशावादी interpretation कर रहा हूँ
    • लेकिन उन्होंने slavery और drug trading तो हटा दी थी :)
    • Arch Elite निश्चित रूप से peak है
    • हाल की Oric Atmos fan-made version भी काफ़ी अच्छी है: https://www.youtube.com/watch?v=kC1cJGLGlxo

  • हर bank की शुरुआत में ऐसा bank-switching shim होना मुझे पसंद है
    SEI / INC $C006 / JMP BEGIN
    space बचाने के लिए ऐसा करने की वजह विस्तार से बताई गई है, लेकिन मेरी नज़र में JMP की ज़रूरत का इकलौता कारण instruction pipeline है, और लगता है कि सिर्फ़ NOP से भी flush किया जा सकता है
    इसलिए मेरा 2-byte optimization यह है: SEI / INC $FFFD ; command vector में C0 का इस्तेमाल करें / NOP

    • “JMP की ज़रूरत का इकलौता कारण instruction pipeline है” यह बात सही है, लेकिन इंसानों के लिए भी इसका मतलब बनता है। execution bank 7 में शुरू होता है, इसलिए bank 7 पर jump किया जाता है
      अलग बात के तौर पर, Game Boy में entry point fixed bank ROM0 में होता है, इसलिए कम से कम आम MBCs में शुरुआत से ही ऐसी समस्या नहीं होती

  • तुलना के लिए Objective-C में लिखा गया open-source Elite clone Oolite का source code है: https://github.com/OoliteProject/oolite
    https://oolite.space
    https://news.ycombinator.com/item?id=7894145

  • 8 साल की उम्र में मैंने इसे C64 पर खेला था। 30 साल बाद भी यह code मेरी समझ में नहीं आता

  • सिर्फ़ बैंक 0 में ही assembly की 18,305 lines हैं—समझ नहीं आता कि उन्होंने यह सब दिमाग़ में कैसे रखा होगा

    • 6502 वाले दौर में सब कुछ दिमाग़ में नहीं रखा जाता था; इसे tractor-feed dot matrix paper के ढेरों में रखा जाता था। आम तौर पर pencil से लिखे ढेर सारे notes और corrections भी होते थे
    • मैंने आधुनिक समय में 8-bit devices के लिए थोड़ा embedded development किया है, और 80s में यह काम करने वाले engineers को दिल से सलाम करता हूँ
      सबसे अच्छे tools होने पर भी code track करने के लिए ज़बरदस्त संगठन और अनुशासन चाहिए रहा होगा। मैंने 80s की शुरुआत के Hitachi 6303[0]/Motorola 6800[1] के assemblers पर research की थी, और ऐसे tool constraints के बीच लोगों ने जो किया वह हैरान करने वाला है
      उदाहरण के लिए, नीचे दिए गए दोनों assemblers में labels सिर्फ़ 6 characters तक हो सकते थे, और subroutine के अंदर इस्तेमाल होने वाले local labels भी नहीं थे। अपने काम में मैंने readability के लिए labels को 40 characters तक सीमित किया था, फिर भी ऐसा लगा
      हालांकि इन architectures की relative simplicity, modern systems embedded काम की तुलना में वाक़ई refreshing है। पूरे system state को मोटे तौर पर दिमाग़ में रख पाना निश्चित रूप से एक फायदा है
      0: http://www.bitsavers.org/components/hitachi/_dataBooks/U24_H...
      1: http://www.bitsavers.org/components/motorola/6800/exorciser/...
    • उस समय हम बेहतर versions of ourselves थे। गंभीरता से कहूँ तो, किसी भी ठीक-ठाक आकार के project में लगभग निश्चित रूप से बहुत सारा code कागज़ पर लिखना या print करना पड़ता था। सच में बहुत कागज़ चाहिए होता था
    • यह code बेहद अच्छी तरह organized है और documentation भी अच्छी है। असली code की documentation का स्तर कैसा था, पता नहीं, लेकिन लगता है printouts पर हाथ से लिखे notes बहुत रहे होंगे
      कुल मिलाकर assembly programming भी high-level languages से बहुत अलग नहीं है। आप code को functions और blocks वगैरह में organize करते हैं। jumps से उलझी हुई बेहद लंबी code wall लिखना अपने लिए गंभीर समस्याएँ खड़ी करने जैसा है
    • एक modern engineer के नज़रिये से, समझ नहीं आता कि इसे दिमाग़ में रखने की ज़रूरत क्यों होगी

  • अफ़सोस है कि यह free software नहीं है। अगर मैं Elite का creator होता, तो सभी game ports को free license के तहत release करता
    वैसे भी आजकल सस्ते netbook पर Oolite खेल सकते हैं, और addons की विशाल list की वजह से उतना ही या उससे भी ज़्यादा मज़ा मिल सकता है

    • ऐसा इसलिए था क्योंकि Braben copyright मुद्दों पर काफ़ी सख़्त थे। इसके उलट Bell अच्छे इंसान थे, और उन्होंने अपने लिखे हुए ज़्यादातर हिस्से公開 कर दिए थे
    • इस release के आसपास का इतिहास कई दशकों पीछे तक जाता है
      शायद Braben की तरफ़ से वे Elite 4/Elite: Dangerous बना रहे थे, इसलिए वे copyright को कमजोर नहीं करना चाहते थे

  • सभी source code को इसी स्तर पर documented होना चाहिए