NES Elite - ซอร์สโค้ดของ Elite สำหรับ NES ที่มีเอกสารประกอบ

 (github.com/markmoxon)
1 คะแนน โดย GN⁺ 2023-10-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ซอร์สโค้ดของ Elite สำหรับ NES โดย Ian Bell และ David Braben ซึ่งมีเอกสารประกอบทุกบรรทัดและส่วนใหญ่มีคำอธิบาย โดยสร้างขึ้นใหม่ด้วยมือจาก disassembly ของไบนารีเกมต้นฉบับ
  • สามารถสร้างเกมที่ทำงานได้สมบูรณ์จากซอร์สบนคอมพิวเตอร์สมัยใหม่ และสร้าง iNES ROM image ที่โหลดบน NES จริงหรือ emulator ได้
  • รูปแบบที่รองรับคือ Imagineer PAL variant และ NTSC variant จากเว็บไซต์ส่วนตัวของ Ian Bell โดยค่าเริ่มต้นของการ build คือ PAL variant
  • วิธีสำรวจซอร์สคือดูในรูปแบบที่อ่านง่ายสำหรับมนุษย์ได้ที่ elite.bbcelite.com หรือเปิดซอร์สที่มีคอมเมนต์ใน IDE โดยเนื้อหาในเว็บไซต์และไฟล์ซอร์สเหมือนกัน
  • ข้อกำหนดในการ build คือ BeebAsm, Python และ make บน Mac/Linux โดยการ build ด้วย Python ทดสอบเฉพาะบน 3.x และบน Windows มี make.exe รวมอยู่ด้วย
    • บน Windows ใช้ make.bat ส่วน Mac/Linux ใช้ make โดยผลลัพธ์เริ่มต้นคือ elite-pal.NES ในโฟลเดอร์ 5-compiled-rom-images
    • สามารถสร้าง elite-ntsc.NES ได้ด้วย variant=ntsc
  • ตัวเลือกการ build ใช้ควบคุมการเลือก variant, การใช้ commander ทดสอบที่ใกล้ค่าสูงสุด, การข้ามการจับคู่กับไบนารีต้นฉบับ, การปิดใช้งานการตรวจสอบ crc32 เป็นต้น
    • ตัวอย่างหลักคือ make variant=ntsc commander=max match=no verify=no
    • crc32.py จะเปรียบเทียบ checksum และขนาดไฟล์ของไฟล์ที่สร้างขึ้นกับไฟล์อ้างอิงที่ดึงจากซอร์สต้นฉบับแบบเคียงข้างกัน
  • PAL และ NTSC variant แตกต่างกันในเรื่องจำนวน cycle ของ NMI handler, heading ของ Imagineer/Nintendo บน Start screen, เวลารอ auto-play ของ combat demo, อัลกอริทึม checksum ของ save slot, หมายเลขเวอร์ชันภายใน, copyright message ที่ซ่อนอยู่, scroll text, ค่าคงที่ y-coordinate เป็นต้น
  • NTSC variant ไม่ทำงานบนอุปกรณ์ NTSC จริง แต่เป็น NTSC emulation ที่ปรับ NMI timing ให้เหมาะกับ NTSC mode ของ emulator บางตัว
  • ไม่มีไฟล์ไลเซนส์ จึงใช้กฎหมายลิขสิทธิ์พื้นฐาน โดยอนุญาตให้อ่านและ fork เท่านั้น และไม่อนุญาตให้ทำซ้ำ แจกจ่าย หรือสร้างงานดัดแปลง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-09
ความคิดเห็นบน Hacker News

  • เมื่อนานมาแล้วตอนทำงานที่ Frontier ผมเคยได้ฟังเกร็ดสนุก ๆ เกี่ยวกับ NES Elite จาก David Braben ซึ่งเท่าที่จำได้ ตอนแรกพวกเขาใช้ฮาร์ดแวร์ไทเมอร์ของ NES เพื่อติดตามเวลาจริง ทำให้ฟิสิกส์เดินไปอย่างสม่ำเสมอแม้อัตราเฟรมจะต่างกัน
    ผมได้ยินมาว่าในการตรวจสอบก่อนวางจำหน่ายของ Nintendo เขาตัดสินว่าใช้ไม่ได้ เพราะ NES รุ่นแรกบางเครื่องมีไทเมอร์นั้นที่ทำงานไม่ถูกต้อง ดังนั้น Bell/Braben จึงทำให้แต่ละฟังก์ชันคงค่าประมาณของตัวเองว่าใช้คล็อกไซเคิลไปกี่รอบในเฟรมนั้น แล้วรวมกันตอนจบเฟรมเพื่อประมาณเวลาที่ผ่านไป
    แต่พอดูซอร์สบน GitHub แล้ว ดูเหมือนว่าผมจะจำผิดหรือไม่ก็เข้าใจคำพูดของ Braben ไม่ถูก ใน elite-source-bank-7.asm มีคอมเมนต์ว่า “อัปเดต NMI timer ที่ใช้แทนฮาร์ดแวร์ไทเมอร์ที่ NES ไม่รองรับ” และดูเหมือนว่ามันนับ non-maskable interrupt เพื่อทำเป็นนาฬิกาใกล้เคียงเวลาจริง

    • น่าจะเป็นความทรงจำที่ปนกันไปครับ NES รุ่นที่วางจำหน่ายจริงไม่ว่าริวิชันไหนก็ไม่มี ฮาร์ดแวร์ไทเมอร์
      ในได CPU ของ NES รุ่นแรกมีบั๊กและมีเศษซากของ programmable interval timer ที่ถูกปิดใช้งานอยู่: https://www.nesdev.org/wiki/RP2A03_Programmable_Interval_Tim...
      ในริวิชันถัด ๆ มามันถูกเอาออกไปหมด และก็เป็นไปได้ว่าอาจเปิดใช้ได้เฉพาะในพวกชุดพัฒนา ถ้าไปพึ่งพาฟีเจอร์ที่ไม่ทำงานบนเครื่องผู้บริโภค ก็ย่อมถูกการทดสอบของ Nintendo ปฏิเสธอยู่แล้ว
      ต่อให้คอนโซลที่วางจำหน่ายมี programmable interval timer จริง มันก็คงมีประโยชน์แค่กับการวัดระดับย่อยกว่าเฟรม เช่นเอฟเฟกต์ raster ที่ต้องการความแม่นยำสูงเท่านั้น สำหรับการวัดเวลาจริง การนับ NMI สมเหตุสมผลกว่ามาก NMI เกิดขึ้นตอนเริ่มทุกวิดีโอเฟรม และสม่ำเสมอมากที่ 60.0988Hz แม้เอนจินเกมจะช้าลงจนทำให้อัตราเฟรมเปลี่ยนไป การประมวลผลฝั่ง CPU ก็ไม่สามารถส่งผลต่อไทมิงของสัญญาณวิดีโอได้
      อนึ่ง ฮาร์ดแวร์เสียงก็สร้าง timer interrupt ได้เช่นกัน และชิปเสริมจำนวนมากก็มี scanline counter สำหรับซิงก์การเรนเดอร์ วิธีจับเวลาบน NES ไม่ได้ขาดแคลนเลย
    • ผมเคยได้ยินเรื่องคล้าย ๆ กันจาก Andrew Davie แห่ง BEAM Software (Melbourne House) ด้วย เขาพัฒนา Super Glove Ball และเล่าว่า Nintendo แทบไม่ได้ให้เอกสารที่มีสาระอะไรเลย จึงต้องใช้แฮ็กหลายอย่างกับส่วนต่าง ๆ เช่นการคำนวณอัตราเฟรม
      ตอนพยายามขออนุมัติเกมหนึ่งจาก Nintendo ได้ยินมาว่ามันไม่ทำงานบน NES เวอร์ชันหนึ่งของสหรัฐฯ หรือทำให้ระบบร้อนเกินไป กำหนดวางจำหน่ายกระชั้นมากจนต้องบินไปสำนักงานใหญ่ Nintendo เพื่อแก้ปัญหา และเท่าที่จำได้ เวอร์ชันเฉพาะนั้นมีการกระจายไม่ถึง 100 เครื่อง
      ภายหลังผมเจอโน้ตของหนังสือที่ยังไม่เคยตีพิมพ์ ซึ่งความจริงต่างออกไปเล็กน้อย การทดสอบเกมไม่ได้จำกัดแค่เกมเพลย์ แต่ต้องทดสอบบนคอนโซล NES ทุกรูปแบบที่อาจรันได้ Andrew Davie จาก Beam Software เล่าว่า “The Three Stooges” ทำให้เกิดปัญหาบน NES สำหรับทดสอบที่สำนักงาน Nintendo ใน Washington เขาจึงต้องไปด้วยตัวเอง
      เขาบอกว่ากว่าจะผ่าน เกมต้องรับมือกับ “ความแปรผันของเครื่องราว 23 แบบ” เช่นชุดผู้ผลิตชิปที่ต่างกัน และเพราะขาดเอกสารทางการ เขาจึงทำให้ข้อมูลสไปรต์ไม่ได้ถูกเขียนลง RAM ตามคำแนะนำทางการ แต่เขียนโดยตรงทุก 2 วินาที ส่งผลให้ NES ร้อนเกินไปและเกิดอาการสไปรต์กะพริบทั้งเกม หลังแก้ไขแล้วจึงได้รับอนุมัติให้วางจำหน่าย และได้ยินมาว่าชุดผสม NES ที่มีปัญหานั้นมีอยู่ทั้งสหรัฐฯ แค่ประมาณ 5 เครื่อง จึงถูกถอดออกจากไลน์อัปทดสอบของ Nintendo

  • ช่วงหลังผมเริ่มเล่นภาคต่อ Elite: Dangerous แม้จะไม่ไร้ปัญหา แต่ก็เป็นประสบการณ์ที่น่าทึ่งทีเดียว
    การได้เห็นองค์ประกอบเกมที่ต่อเนื่องมาจากเวอร์ชันปี 1984 ให้ความรู้สึกซาบซึ้งอย่างประหลาด พอได้เห็นยาน และโดยเฉพาะสถานี Coriolis ที่เคยเห็นเป็นกราฟิกเวกเตอร์บนหน้าจอ memory mapping 16K อันทันสมัยในยุคนั้น กลายมาเป็นการเรนเดอร์ 3D เต็มรูปแบบระดับ 4K/60fps มันกระทบอารมณ์มากกว่าที่คาด
    การได้เห็นภายในของ Coriolis อย่างละเอียดพร้อมป้ายโฆษณา ต้นไม้ และอุปกรณ์เทียบท่าในที่สุด พูดตามตรงก็ทำให้ตาชื้นนิด ๆ ต่อให้ตอนนี้เกมจะมีความยากลำบากอยู่บ้าง แต่นี่คือมรดกที่มีคุณค่า และหวังว่าจะคงอยู่ต่อไปในรูปแบบใดรูปแบบหนึ่ง

    • ผมสนุกกับ Elite Dangerous มากจริง ๆ หลังจากหยุดซัพพอร์ตคอนโซลแล้วก็ไม่ได้เล่นอีก แต่ทั้งที่มีงานซ้ำ ๆ และคอนเทนต์ตื้น ๆ ผมก็ยังคิดถึงช่วงเวลาที่ได้บังคับยานกับเพื่อน ๆ
      การเทียบท่ายานอวกาศแบบแมนนวลขณะฟัง Blue Danube เป็นประสบการณ์ที่ผ่อนคลายเสมอ
      สงสัยเหมือนกันว่าทำไมซิมูเลเตอร์อวกาศกับเกมอวกาศถึงมักมีปัญหาเยอะขนาดนี้ Elite Dangerous ดูเหมือนไปไหนต่อไม่ได้, Star Citizen ก็เหมือนเบต้าตลอดกาล และ KSP2 ก็น่าผิดหวัง
    • ผมเล่น Elite: Dangerous มานานตั้งแต่ช่วงโอเพนเบต้า เป็นเกมที่งดงาม และงานออกแบบเสียงก็ยอดเยี่ยมมาก
      ความคิดที่เขียนไว้เมื่อ 9 ปีก่อน: https://hypertexthero.com/elite-dangerous-education/
      ส่วนเสริม Odyssey ก็สนุก และหวังว่าสักวันหนึ่งจะเพิ่มการออกไปทำกิจกรรมนอกยานแบบ spacewalk กับภารกิจในสภาวะไร้น้ำหนัก

  • ยังมี Elite - The New Kind เวอร์ชัน C ที่แทบจะซื่อสัตย์ต่อต้นฉบับด้วย: https://github.com/fesh0r/newkind
    สร้างโดย Christian Pinder: https://www.christianpinder.com/games/
    โฮมเพจ Elite ของ Ian Bell ก็น่าดูเช่นกัน มีเวอร์ชันต้นฉบับอยู่หลายตัว: http://www.ianbellelite.com/

    • Ian Bell และเว็บไซต์ของเขาควรถูกกล่าวถึงอย่างแน่นอน เพราะเป็นที่ที่หา ซอร์สโค้ดต้นฉบับของเวอร์ชัน BBC Micro ได้ และดิสก์ต้นฉบับเหล่านั้นก็เป็นพื้นฐานของงานใส่คำอธิบายประกอบ Elite ทั้งหมดของผม รวมถึงโปรเจกต์ NES ด้วย
      แกนหลักของเวอร์ชัน NES ปี 1991 หรือราว 30% ของ ROM ขนาด 128K นั้นโดยเนื้อแท้คือเวอร์ชัน BBC Master ปี 1986 ซึ่งตัวมันเองก็เป็นพัฒนาการต่อจากเวอร์ชัน BBC Micro ดั้งเดิมปี 1984 เวอร์ชัน Commodore 64 และ Apple II ก็อยู่ในสายวิวัฒนาการเดียวกัน และการพัฒนาก็ทำบน BBC Micro
      โค้ดส่วนใหญ่ในแบงก์ 0, 1, 2 ถูกนำมาจากเวอร์ชัน BBC โดยตรง และยังมีบางส่วนในแบงก์ 7 ด้วย มีการใส่รูทีนกราฟิก เสียง และคอนโทรลเลอร์ใหม่ไว้ด้านหน้า แต่หัวใจที่เต้นอยู่ก็ยังเป็น เวอร์ชัน Beeb

  • Ian Bell ผู้เขียน Elite เคยบอกว่าเวอร์ชัน NES เป็น Elite เวอร์ชัน 8 บิต ที่เขาชอบที่สุด
    โดยรวมแล้วเขาบอกว่าชอบพอร์ตไปยัง Archimedes แบบ 32 บิตมากที่สุด

    • ข้อความอ้างอิงต้นฉบับเป็นดังนี้: “ความสำเร็จครั้งใหญ่ที่สุดในเชิงเทคนิคที่ผมเคยเผยแพร่ คือการยัด ‘Elite’ เวอร์ชันเทปคาสเซ็ตของ BBC รวมถึงหน้าจอ เข้าไปใน RAM 32K และการแปลง ‘Elite’ สำหรับ Nintendo Entertainment System โดยใช้จอแสดงผลแบบ character mapping กับคอนโทรลเลอร์ NES เพียงตัวเดียว NES เป็นงานแปลงที่ผมชอบที่สุดในบรรดาที่เผยแพร่แล้ว และก่อนที่เราจะทำสำเร็จ มันไม่เคยถูกมองว่าเป็นไปได้ในทางเทคนิค”
      บทสัมภาษณ์เต็มอยู่ที่ http://www.elitehomepage.org/archive/b5081501.htm
      ผมตีความคำพูดนี้ว่าเวอร์ชันที่เขาชอบที่สุดคือ เวอร์ชันเทปคาสเซ็ตของ BBC Micro และงานแปลงที่ชอบที่สุดคือเวอร์ชัน NES แต่อาจเป็นเพราะผมเป็นแฟนบอย BBC เลยตีความเข้าข้างตัวเองก็ได้
    • แต่ก็ตัดการค้าทาสกับการค้ายาเสพติดออกไปนี่นา :)
    • Arch Elite คือจุดสูงสุดอย่างชัดเจน
    • เวอร์ชันแฟนเมดสำหรับ Oric Atmos เมื่อไม่นานมานี้ก็ค่อนข้างดี: https://www.youtube.com/watch?v=kC1cJGLGlxo

  • ชอบที่มี bank switching shim แบบนี้อยู่ตอนเริ่มของแต่ละแบงก์
    SEI / INC $C006 / JMP BEGIN
    มีคำอธิบายละเอียดว่าทำแบบนี้เพื่อประหยัดพื้นที่ แต่ในสายตาผม เหตุผลเดียวที่ต้องใช้ JMP คือเพราะ instruction pipeline และน่าจะ flush ได้ด้วยแค่ NOP
    ดังนั้นการปรับให้เหมาะสมแบบ 2 ไบต์ของผมคือ: SEI / INC $FFFD ; ใช้ C0 ในเวกเตอร์คำสั่งแทน / NOP

    • คำว่า “เหตุผลเดียวที่ต้องใช้ JMP คือเพราะ instruction pipeline” ก็ถูก แต่ก็สื่อความหมายกับคนอ่านด้วย การรันเริ่มจาก แบงก์ 7 ดังนั้นจึงเป็นการกระโดดไปยังแบงก์ 7
      นอกเรื่องนิดหนึ่ง บน Game Boy จุดเข้าโปรแกรมอยู่ใน ROM0 ซึ่งเป็นแบงก์คงที่ ดังนั้นอย่างน้อยกับ MBC ที่พบได้ทั่วไป ก็ไม่มีปัญหาแบบนี้ตั้งแต่แรก

  • มีซอร์สโค้ดของ Oolite โคลน Elite แบบโอเพนซอร์สที่เขียนด้วย Objective-C ไว้เป็นตัวเปรียบเทียบ: https://github.com/OoliteProject/oolite
    https://oolite.space
    https://news.ycombinator.com/item?id=7894145

  • ผมเล่นเกมนี้บน C64 ตอนอายุ 8 ขวบ ผ่านมา 30 ปีแล้ว ตอนนี้ก็ยังไม่เข้าใจโค้ดนี้อยู่ดี

  • แค่แบงก์ 0 ก็มี แอสเซมบลี 18,305 บรรทัด แล้ว นึกไม่ออกเลยว่าพวกเขาเก็บมันไว้ในหัวได้ยังไง

    • ในยุคที่ใช้ 6502 กัน เขาไม่ได้ใส่ทุกอย่างไว้ในหัวหรอก แต่เก็บไว้เป็นปึกกระดาษดอตเมทริกซ์แบบ tractor feed มักจะมีบันทึกและการแก้ไขที่เขียนด้วยดินสอเต็มไปหมดด้วย
    • ผมเคยทำงานพัฒนา embedded สำหรับเครื่อง 8 บิตในยุคปัจจุบันมาบ้าง และขอคารวะวิศวกรที่ทำสิ่งนี้ในยุค 80 อย่างจริงใจ
      ต่อให้มีเครื่องมือระดับดีที่สุด การติดตามโค้ดก็น่าจะต้องใช้การจัดระเบียบและวินัยมหาศาล ผมเคยสำรวจ assembler สำหรับ Hitachi 6303[0]/Motorola 6800[1] ช่วงต้นยุค 80 และสิ่งที่ผู้คนทำได้ภายใต้ข้อจำกัดของเครื่องมือแบบนี้ก็น่าทึ่งมาก
      ตัวอย่างเช่น assembler สองตัวด้านล่างอนุญาตให้ label ยาวได้เพียง 6 ตัวอักษร และไม่มี local label สำหรับใช้เฉพาะภายใน subroutine ด้วยซ้ำ ในงานของผม แม้จะจำกัด label ไว้ที่ 40 ตัวอักษรเพื่อให้สื่อความหมาย ก็ยังรู้สึกแบบนั้น
      อย่างไรก็ตาม ความเรียบง่ายเชิงสัมพัทธ์ของสถาปัตยกรรมแบบนี้ให้ความรู้สึกสดใหม่จริง ๆ เมื่อเทียบกับงาน embedded บนระบบสมัยใหม่ การสามารถเก็บสถานะของทั้งระบบไว้ในหัวได้คร่าว ๆ นั้นเป็นข้อดีอย่างชัดเจน
      0: http://www.bitsavers.org/components/hitachi/_dataBooks/U24_H...
      1: http://www.bitsavers.org/components/motorola/6800/exorciser/...
    • ตอนนั้นพวกเราเป็นตัวเราที่ดีกว่านี้ พูดจริง ๆ คือโปรเจกต์ที่มีขนาดพอสมควรแทบจะจำเป็นต้องเขียนหรือพิมพ์โค้ดจำนวนมากลงบนกระดาษ ต้องใช้กระดาษเยอะมากจริง ๆ
    • โค้ดนี้จัดระเบียบได้ดีสุด ๆ และมีเอกสารประกอบดีมากด้วย ผมไม่รู้ว่าระดับเอกสารของโค้ดต้นฉบับเป็นอย่างไร แต่เดาว่าน่าจะมีบันทึกลายมือเขียนอยู่บนเอกสารพิมพ์ออกมาจำนวนมาก
      โดยรวมแล้วการเขียนโปรแกรมแอสเซมบลีก็ไม่ได้ต่างจากภาษา high-level มากนัก เราจัดระเบียบโค้ดเป็นฟังก์ชันและบล็อก ฯลฯ การเขียนกำแพงโค้ดยาวมหึมาที่มี jump พันกันยุ่งเหยิงคือการหาเรื่องเดือดร้อนอย่างหนัก
    • ในมุมของวิศวกรยุคใหม่ ผมไม่ค่อยเข้าใจว่าทำไมต้องเก็บสิ่งนี้ไว้ในหัวด้วย

  • น่าเสียดายที่มันไม่ใช่ซอฟต์แวร์เสรี ถ้าผมเป็นผู้สร้าง Elite ผมคงปล่อยพอร์ตของเกมทั้งหมดภายใต้ ไลเซนส์เสรี ไปแล้ว
    อย่างไรก็ตาม ทุกวันนี้เราสามารถเล่น Oolite บนเน็ตบุ๊กราคาถูกได้ และด้วยรายการแอดออนจำนวนมหาศาล ก็ให้ความสนุกได้เท่ากันหรือมากกว่า

    • นั่นเป็นเพราะ Braben เข้มงวดเรื่องลิขสิทธิ์ ส่วน Bell เป็นคนดี และเปิดเผยส่วนใหญ่ที่เขาเขียนเอง
    • ประวัติศาสตร์รอบการเปิดเผยครั้งนี้ย้อนกลับไปได้หลายสิบปีก่อน
      ฝั่ง Braben กำลังทำ Elite 4/Elite: Dangerous อยู่ จึงดูเหมือนไม่อยากทำให้ลิขสิทธิ์อ่อนลง

  • ซอร์สโค้ดทั้งหมดควรถูก จัดทำเอกสาร ไว้ในระดับนี้