1 คะแนน โดย GN⁺ 2023-08-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นโปรเจ็กต์ที่พอร์ต semu ซึ่งเป็นอีมูเลเตอร์ RISC-V32 แบบมินิมัลสำหรับรัน Linux มายัง C-64 ของ Commodore
  • เนื่องจากหน่วยความจำ 64KiB เพียงอย่างเดียวไม่สามารถบรรจุองค์ประกอบทั้งหมดได้ จึงต้องใช้ RAM Expansion Unit(REU) และความเร็วในการรันก็ช้ามากจนถูกอธิบายว่า “extremely slowly”
  • ไฟล์ปฏิบัติการ semu ที่สร้างขึ้นเป็น RISCV32 อีมูเลเตอร์ แบบทั่วไป และสมมติว่า REU ถูกแมปอยู่ในช่วงแอดเดรสตั้งแต่ 0x00000000 ถึง 0x01000000
  • การรัน Linux ใช้การอีมูเลตหน่วยความจำเสมือนและ MMU โดย UART ที่ถูกอีมูเลตจะจัดการแปลงตัวพิมพ์ใหญ่-เล็กระหว่าง PETSCII และ ASCII
  • การบิลด์ทำด้วย make และต้องใช้ mos-c64-clang
  • เมื่อต้องการรันบน VICE ต้องใช้ไฟล์ .d64 ที่บรรจุไฟล์ปฏิบัติการ semu ที่คอมไพล์แล้วร่วมกับ reufile.linux จากนั้นเปิดใช้งาน RAM Expansion Module และเลือกขนาดเป็น 16MiB
  • ฝั่ง C-64 ใช้วิธีรันด้วยการพิมพ์ LOAD "SEMU",8,1 แล้วตามด้วย run และตาม README ต้องรอค่อนข้างนานกว่าจะบูตได้
  • ไบนารี semu สำหรับพีซีสามารถโหลด reufile.linux ได้ด้วยออปชัน -k และใช้เพื่อให้ได้ลำดับการบูตแบบกำหนดผลลัพธ์ได้แน่นอนจนกว่าจะมีการกดคีย์ครั้งแรก
  • ฟีเจอร์ persistence ใช้วิธีบันทึกสถานะของอีมูเลเตอร์เพื่อโหลด Linux ที่บูตแล้วได้เร็วขึ้น โดยจะโหลดสถานะของรีจิสเตอร์ CPU แบบ RISC-V, UART และอินเทอร์รัปต์คอนโทรลเลอร์จากแอดเดรส REU 0xfff000
  • รีลีสต่าง ๆ ถูกระบุว่าเป็น “highly experimental” และไม่เหมาะสำหรับงาน production

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

 
GN⁺ 2023-08-28
ความคิดเห็นจาก Hacker News
  • Onno Kortman นำ semu ซึ่งเป็น อีมูเลเตอร์ RISC-V ขนาดจิ๋ว ไปครอสคอมไพล์ด้วย llvm-mos ซึ่งเป็นพอร์ต LLVM สำหรับ MOS 6502 ทำให้ Linux รันบน Commodore 64 ได้
    Kortman เขียนว่า “แค่ทำสกรีนช็อตก็ใช้เวลาหลายชั่วโมงแม้ใน ‘warp mode’ ของ VICE แล้ว ถ้าสภาพตอนนี้ บน C64 จริงก็น่าจะบูต Linux ได้ภายในราวหนึ่งสัปดาห์”

    • 6502 ขึ้นชื่อว่าแย่มากในฐานะเป้าหมายคอมไพล์ C โดยเฉพาะถ้าเป็น C ที่ไม่ได้คำนึงถึงข้อจำกัดของ 6502
      ถ้าเขียนอีมูเลเตอร์ RISC-V แบบ 6502 เนทีฟ อาจทำให้บูต Linux บนเครื่องจริงได้ภายในหนึ่งวัน ไม่ใช่หนึ่งสัปดาห์ก็ได้ คิดดูสิว่าจะช่วยชีวิตได้มากแค่ไหน
      https://www.folklore.org/StoryView.py?story=Saving_Lives.txt
    • วิธีบูตสแตรปนี้ทำให้นึกถึงโปรเจกต์ Linux บนไมโครคอนโทรลเลอร์ 8 บิตอีกตัวหนึ่ง
      https://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bi... ใช้อีมูเลเตอร์ ARMv5 บน AVR 8 บิต แต่ครั้งนี้เหนือกว่าในแง่ ความเท่แบบกี๊กเพี้ยนๆ
    • อยากเห็นมันรันบนฮาร์ดแวร์จริง และหวังว่าจะมีใครทำสำเร็จ
  • ถึงจะเจ๋ง แต่ความคิดแรกที่ผุดขึ้นมาคือ “มันไม่มีทางใส่ใน RAM 64KB ได้หรอก!” และจริงๆ ก็ใส่ไม่ได้
    ต้องใช้ 16MB REU ตอนนั้น REU สำหรับ C64 มีขนาด 256KB และ 512KB และมีวงจรเผยแพร่สาธารณะ จึงมีการทำของโคลนกันโดยมากในฝั่งนี้
    ช่วงปลายยุค 90 ก็มี “ส่วนขยาย” สำหรับ C64 ที่ใส่ SuperCPU (65816) ซึ่งเป็น CPU รุ่นใหม่ที่เข้ากันได้กับโค้ดของ CPU เดิม และอุปกรณ์นี้น่าจะรองรับได้สูงสุด 16MB
    ต่อมามีการทำใหม่บน FPGA และ 16MB REU ก็ปรากฏขึ้นด้วย วงจร SuperCPU ดั้งเดิมหายไปแล้ว และแม้จะว่ากันว่าบอร์ดขยายแบบ FPGA ตอนนี้ซื้อได้ในราคาหลายร้อยยูโร แต่ก็ไม่รู้จักใครที่ซื้อจริง
    ดังนั้นแม้จะเป็นความสำเร็จทางเทคนิคที่สวยงาม แต่คำว่า “รันบน C64” ให้ความรู้สึกคล้ายกับการบอกว่า “รัน Doom 3 บน 386 ได้แล้ว เพียงแต่ 386 นั้นเป็นการ์ด PCI ของพีซีสมัยใหม่”
    ถ้ามันรันบน C64 ของผมด้วยฮาร์ดแวร์ที่หาได้ในยุคนั้น หรือฮาร์ดแวร์ที่ในทางปฏิบัติสามารถสร้างได้ในยุคนั้นไม่ได้ ก็เรียกว่า “รันบน C64” ได้ไม่เต็มปาก
    กลับมาที่เรื่อง REU ผมก็สงสัยว่าทำไมยังไม่มีวงจรเปิดเผยออกมา ชิป SRAM ราคาถูกมีเยอะบน eBay ดูเหมือนจะทำได้ง่าย แต่ความจริงไม่ง่าย เพราะต้องอีมูเลตองค์ประกอบสองส่วนคือ SuperCPU และคอนโทรลเลอร์ DMA ด้วย FPGA ที่ค่อนข้างใหญ่
    ถ้ามี FPGA ที่ถูกกว่านี้ หรือไมโครคอนโทรลเลอร์ที่มีความสามารถคล้าย FPGA ออกมา บางทีอาจมีใครทำ SuperCPU แบบโอเพนซอร์สก็ได้ เท่าที่ได้ยินมาผู้ใช้ทั้งหมดดูเหมือนจะใช้อีมูเลชันกัน อีมูเลชันมีประโยชน์มากสำหรับการพัฒนา แต่ความสนุกของงานอดิเรกเรโทรของผมอยู่ที่การรันบนฮาร์ดแวร์ต้นฉบับมากที่สุด

    • ถ้าใช้เกณฑ์ว่า “ถ้าไม่ใช่ฮาร์ดแวร์ที่หาได้ในยุคนั้น หรือฮาร์ดแวร์ที่ในทางปฏิบัติสามารถสร้างได้ในยุคนั้น ก็เรียกว่ารันบน C64 ได้ยาก” แล้วละก็ 16MB REU สร้างได้แม้ในยุค 80
      แค่มันมีราคาแพงระดับดาราศาสตร์ ไม่ได้มีเหตุผลทางเทคนิคที่ทำให้เป็นไปไม่ได้ ดูเหมือนคุณจะสับสนระหว่าง SuperCPU กับ REU ธรรมดา
      REU เป็นแค่ก้อน RAM กับ ASIC ที่สื่อสารกับ C64 เพื่อให้บันทึกหรือดึง RAM bank กลับมาเท่านั้น และไม่มี CPU เนื่องจาก 6502 ไม่สามารถ address มากกว่า 64KB ได้โดยตรง จึงใช้วิธีสั่งให้สลับ RAM ของระบบ
      SuperCPU (65816) สามารถ address 16MB ได้โดยตรงจริง แต่เป็นคนละอย่างกัน โปรเจกต์ต้นฉบับรันบน C64 พื้นฐานและ CPU C64 พื้นฐาน เพียงแต่ต้องใช้ RAM มหาศาล ซึ่งในยุคนั้นคงมีราคาเท่าบ้านหนึ่งหลัง
    • สงสัยว่าถ้าแทน FPGA แล้วใช้ ARM SoC เอนกประสงค์บนบอร์ดอย่าง RPi Pico/Nano ให้ทำงานเดียวกันด้วยซอฟต์แวร์ได้ไหม
      หรือแบบนั้นก็ชนขีดจำกัดของพวกเคร่งความบริสุทธิ์ของอีมูเลชันแล้วหรือเปล่า
    • “386 ของผมจริงๆ แล้วเป็นการ์ด PCI ของพีซีสมัยใหม่” ฟังแล้วตอนนี้อยากได้ขึ้นมาเลย
      ทุกวันนี้น่าจะยัด 386, 486, Pentium และ SoC อื่นๆ ลงในการ์ด PCIe ใบเดียวได้ แถมระบายความร้อนแบบพาสซีฟก็น่าจะไหว
    • ถ้าต้องเพิ่มหน่วยความจำ 16MB ก็ค่อนข้างอยู่บนเส้นแบ่งว่าจะพูดว่า “บน Commodore 64” ได้ไหม
  • ไม่ใช่เรื่อง Linux แต่ช่วงนี้กำลังลองใช้อุปกรณ์เสริม C64 รุ่นใหม่ๆ อยู่
    ได้ลอง Kung Fu Flash แล้ว เป็นคาร์ทริดจ์แบบ software-defined ราคาถูกที่ทำจาก STM32 ตัวเดียว และทำได้แทบทุกอย่าง ผมซื้อมาเพื่อพยายามจำลองประสบการณ์การพัฒนาแบบที่เห็นใน “8-bit show and tell” และมันอีมูเลต “Super Snapshot” ได้ แต่ REU ไม่ได้ เหมาะมากสำหรับลองซอฟต์แวร์และเกม C64 จำนวนมากอย่างรวดเร็ว
    https://8bithardware.wixsite.com/website/post/kung-fu-flash
    https://github.com/KimJorgensen/KungFuFlash
    ผมมี SD2IEC ด้วย และได้เรียนรู้ว่าน่าจะซื้อรุ่นที่มีซ็อกเก็ต DIN เพิ่มมาด้วย มันก็ใช้ได้ แต่เดิมผมไม่ชอบ DOS ของ C64 อยู่แล้ว และอุปกรณ์นี้ยิ่งตอกย้ำความรู้สึกนั้น การเมานต์อิมเมจดิสก์ D64 ต้องพิมพ์ OPEN1,8,15,"CD:MYIMAGE.D64":CLOSE1 ซึ่งไม่น่าใช้
    JiffyDOS ซึ่งเป็น ROM ทดแทนสำหรับ C64 ช่วยปรับปรุงเรื่องนี้ ทำงานเร็วขึ้น และมี DOS wedge ติดมาให้ตลอดเวลา ผมสั่งไว้แล้ว และอยากลองใช้กับไดรฟ์ 1541 จริงๆ
    สิ่งที่ทำให้ผมเริ่มสนใจของพวกนี้เมื่อไม่นานมานี้คือคาร์ทริดจ์ “Penultimate +2” สำหรับ VIC-20
    https://www.youtube.com/watch?v=eNGyneXHKJQ
    จริงๆ แล้วผมซื้อ VIC-20 มาแทบจะเพื่อจะได้ลองคาร์ทริดจ์นี้เลย

  • เป็นการสาธิต ความเทียบเท่าทัวริง ถ้าเวลาไม่ใช่ปัญหา คอมพิวเตอร์ที่ทัวริงสมบูรณ์เครื่องใด ๆ ก็ทำสิ่งที่คอมพิวเตอร์ทัวริงสมบูรณ์อีกเครื่องทำได้

    • แต่ก็ต้องใช้เวลาและหน่วยความจำด้วย
    • แล้วจะรัน Linux ในแลมบ์ดาแคลคูลัสได้อย่างไร?
  • แบบนี้ก็ทำให้อยากรู้ว่า ฮาร์ดแวร์ที่เก่าที่สุดที่สามารถบูต Linux รุ่นใหม่ และยังใช้งานประจำวันได้คืออะไร?

    • ข้อจำกัดสำคัญของการใช้งานประจำวันน่าจะเป็น การคำนวณเข้ารหัส ที่จำเป็นต่อการเข้าถึงเว็บไซต์สมัยใหม่ส่วนใหญ่
      เราอาจสร้างระบบที่เบาและเร็วที่สุดเพื่อให้ทำงานได้ดีบนเครื่องช้า ๆ แต่ทุกวันนี้อินเทอร์เน็ตเป็นที่ที่ไม่ปรานีใคร
    • ถ้า “ใช้งานประจำวัน” หมายถึงการรันเว็บเบราว์เซอร์รุ่นใหม่และแอปเพิ่มประสิทธิภาพการทำงานบนเว็บรุ่นใหม่ ก็คงมองว่าเส้นขั้นต่ำอยู่ราว ๆ Core 2 Duo กับหน่วยความจำ 4GB
      มันคงไม่เร็วมาก แต่ถ้ามีความอดทนนิดหน่อยก็น่าจะไม่ติดขัดเพราะฮาร์ดแวร์ ถ้าใส่ GPU ที่ถอดรหัสวิดีโอด้วยฮาร์ดแวร์ได้ด้วย ก็อาจดู YouTube ได้ดีกว่าคุณภาพแบบมันฝรั่ง
    • เพื่อให้ถกกันได้ สมมติว่าเป็นคอมพิวเตอร์ที่ติดตั้ง Debian 12 ได้ รัน window manager กับเบราว์เซอร์ได้ และไม่ช้าจนทรมาน
      อยากตั้งเป้าไว้ประมาณยุค Pentium 4 / Athlon XP ตามเอกสารแล้ว Pentium รุ่นแรกไม่รองรับ ดังนั้นถ้ายอมทนจริง ๆ ก็คงย้อนกลับไปได้ถึง Pentium II
    • น่าจะเป็นอะไรสักอย่างที่มี Core 2 Duo แน่นอนว่า CPU 230MHz ก็อาจ “รัน” Linux ที่มีเดสก์ท็อปได้เหมือนกัน
    • ไม่ใช่ Linux รุ่นใหม่แน่นอน แต่ตอนที่ผมได้ Slackware 2.0 มาในฤดูร้อนปี 1995 ตอนนั้นใช้ Pentium 75MHz, RAM 8MB, การ์ด Trident ที่ทำ 1024x768 ได้ (แต่ใน X ได้แค่ 800x600), IDE CD-ROM และ HDD
  • อันนี้ต่างจาก LUnix ไหม?
    https://en.wikipedia.org/wiki/LUnix

    • LUnix เป็นระบบปฏิบัติการเนทีฟของ C64 จึงเขียนแอปแล้วรันโดยตรงบนฮาร์ดแวร์ C64 ได้
      แต่อันนี้คือรันอีมูเลเตอร์ RISC-V บน C64 แล้วจำลองการบูต Linux บนอีมูเลเตอร์นั้นอีกที
  • พูดอย่างเคร่งครัด Linux ไม่ได้รันบน C64 โดยตรง
    C64 จำลอง สภาพแวดล้อม RISC-V แล้ว Linux จึงรันอยู่บนนั้น แน่นอนว่ายังน่าประทับใจ แต่การแยกความหมายนี้สำคัญ

  • สงสัยว่าจะทำให้มันทำงานโดยใช้ฟลอปปีดิสก์หลายสิบแผ่นเป็น RAM แทน REU ได้ไหม
    แล้วให้ผู้ใช้เปลี่ยนดิสก์ทุกครั้งที่ต้องการเป็นอย่างไร ถ้ามีใครมีเวลาว่างสักหลายเดือนหรือหลายปี อยากเห็นสิ่งนั้นบนฮาร์ดแวร์จริงแบบไทม์แลปส์

  • ถ้าเพิ่ม RAM ให้ Commodore 64 มันยังเป็น Commodore 64 อยู่ไหม?

    • ถ้าใช้ REU ผมว่ายังใช่ เพราะเป็นการอัปเกรดหน่วยความจำที่เข้ายุคเดียวกับ C64
    • ขยายความจากคำอธิบายของ johnwbyrd แถวนี้ Commodore เคยขาย RAM Expansion Unit ชื่อ “1764” ที่เพิ่ม RAM ของ C64 เป็น 256KB และยังใช้ “1750” ซึ่งเป็น REU สำหรับ C128 เพื่อเพิ่ม RAM ของ C64 เป็น 512KB ได้ด้วย
      นอกจากนี้ยังขยายไปถึง REU ขนาด 2MB สำหรับ C64 ได้ด้วย ดู https://www.neperos.com/article/rlut8ce90fbb7701
      บน C64 การมี 2MB ถือว่าค่อนข้าง “ถูกต้องตามกติกา”
    • ไม่ใช่ นั่นคือ Commodore 16384 ต่างหาก
      หน่วยความจำสูงสุดที่ C64 REU ระบุแอดเดรสได้คือ 16MB
  • ช่วงนี้ได้ TRS-80 Model 4 ที่ใช้งานได้สมบูรณ์มา และมักจินตนาการลาง ๆ ว่าจะเอาอะไรสักอย่างที่คล้าย Unix ไปลงบนนั้น
    จินตนาการนั้นยังดำเนินต่อไป

    • น่าจะอัปได้ถึง 128KB พอถึงจุดนั้นก็มีโอกาสพอสมควรที่จะรัน Fuzix ได้
      ถ้าเริ่มจากตรงนั้น ก็คงเจอโพรงกระต่ายที่ลึกพอดี ๆ