SDL kini mendukung DOS

 (github.com/libsdl-org)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Port DOS berbasis DJGPP telah ditambahkan ke SDL, lalu di-merge ke main dalam kondisi yang sudah cukup lengkap mencakup video, audio, input, threading, timer, filesystem, hingga build chain
  • Video VGA dan VESA 1.2+, pemutaran audio keluarga Sound Blaster, keyboard dan mouse PS/2, joystick berbasis BIOS, serta threading kooperatif dan timer PIT kini memiliki implementasi yang disesuaikan untuk lingkungan DOS
  • Masalah seek/read di DJGPP diakali dengan cara membuang dan memulihkan buffer saat seek, sehingga pembacaan yang salah dan jeda beberapa detik pada SDL_LoadWAV bisa dihilangkan; jalur audio juga disempurnakan untuk mengurangi reentrancy IRQ dan stutter
  • Layar hitam pada fullscreen ternyata terkait dengan pemilihan mode INDEX8, dan alih-alih menambahkan hint khusus DOS, penyesuaian dilakukan dengan mengurutkan mode secara logis; masalah transparansi kursor juga diperbaiki lewat commit tambahan
  • Pengujian di perangkat nyata masih terbatas; beberapa fitur seperti perekaman audio, SDL_LoadObject, dan implementasi khusus DOS untuk SDL_TIME belum ada, tetapi perubahan ini lolos 46 pemeriksaan dan ditetapkan sebagai fitur 3.6.0

Cakupan dukungan platform DOS

  • Porting DOS telah ditambahkan ke SDL, dan berbasis DJGPP dengan tingkat kelengkapan yang relatif tinggi
    • Pengerjaan dibagi di antara beberapa orang, lalu pada tahap akhir ditambahkan perbaikan stabilitas dan pelengkapan fitur yang masih kurang
    • DevilutionX telah diuji secara luas di DOSBox, tetapi tidak ada pengujian di perangkat nyata
    • Beberapa fitur memang sengaja dikecualikan bila belum ada cara pengujian yang memadai
  • Fitur yang didukung dijabarkan secara spesifik
    • Video mencakup framebuffer VGA dan VESA 1.2+, warna RGB dan indeks 8-bit, pemrograman palet VGA DAC, vsync dan hardware page flipping, serta penyimpanan dan pemulihan status VBE saat keluar
    • Audio mendukung Sound Blaster 16, Sound Blaster Pro, dan Sound Blaster 2.0/1.x, menggunakan jalur DMA berbasis IRQ dan auto-init double buffer
    • Input mencakup keyboard PS/2 termasuk extended scancode, mouse INT 33h, dan joystick gameport berbasis BIOS INT 15h
    • Threading memakai scheduler kooperatif berbasis setjmp/longjmp dan patching stack, serta memiliki fallback umum untuk mutex, semaphore, TLS, dan condition variable
    • Titik yield ditambahkan ke event pump dan fungsi delay untuk menjaga responsivitas audio dan thread lain
    • Timer menggunakan implementasi berbasis PIT dengan uclock() milik DJGPP, dengan resolusi sekitar 1,19 MHz
    • Filesystem menangani GetBasePath dan GetPrefPath melalui searchpath() milik DJGPP, serta menyertakan fallback operasi filesystem POSIX
    • Build mencakup file toolchain CMake untuk cross-compilation, job CI DJGPP, dan preseed cache untuk configure yang lebih cepat
  • Fitur yang belum disertakan juga dijelaskan dengan jelas
    • Perekaman audio belum ada, hanya playback yang didukung
    • Implementasi native SDL_TIME tidak tersedia; yang dipakai ulang adalah Unix gettimeofday melalui lapisan POSIX DJGPP
    • Pemuatan shared library tidak didukung, sehingga SDL_LoadObject tidak tersedia

Proses implementasi dan perubahan utama

  • Port DOS ditambahkan lewat banyak commit, dengan video, audio, input, timer, threading, dan build chain yang masuk secara bertahap
    • Setelah pekerjaan awal, pembaruan berlanjut ke buffering stdio, implementasi audio, subsistem video, filesystem, mouse, keyboard, CI, hingga deteksi platform
  • Pada stdio dan akses file, ada akal-akalan untuk menghindari masalah seek/read khas DJGPP
    • Sempat ada upaya mematikan buffer pada stdio SDL_IOStreams, tetapi kemudian diganti menjadi pendekatan membuang dan memulihkan buffer saat seek
    • Perubahan ini jauh lebih cepat dibanding mematikan buffer sepenuhnya, dan juga menghindari masalah pembacaan yang salah setelah fseek
    • Gejala SDL_LoadWAV yang butuh beberapa detik saat membaca test/sample.wav pun hilang, dan data yang dibaca menjadi benar
  • Cara kerja audio juga terus disesuaikan dengan fokus pada stabilitas
    • Implementasi dimulai dari Sound Blaster 16, lalu ditambah dukungan pre-SB16 8-bit mono dan SB Pro stereo
    • Pencampuran audio sempat berjalan langsung di IRQ handler, lalu dipindah lewat loop utama, dan akhirnya kembali ke thread audio SDL
    • Arah ini dipilih agar tidak memicu masalah reentrancy di dalam IRQ, dan setengah buffer DMA lama dibisukan saat loading untuk mengurangi stutter
    • Penyesuaian sample rate, polling status DSP, alasan alokasi memori DMA, hingga pelepasan wrapper IRET setelah pemulihan interrupt vector juga dibereskan
  • Video juga diperluas detailnya agar sesuai dengan batasan lingkungan DOS
    • Implementasi awal yang bekerja dengan software renderer melalui antarmuka VESA lebih dulu masuk
    • Setelah itu ditambahkan dukungan palet 8-bit, VBE page flipping, pemulihan status, vsync pada mode single buffer, dan mode VESA banked framebuffer
    • Pada VBE 1.2+ tanpa LFB, framebuffer disalin lewat bank switching, dan pada mode ini page flipping dinonaktifkan
    • Seluruh status VBE disimpan dan dipulihkan saat inisialisasi dan penghentian video agar perpindahan mode berlangsung bersih
  • Penanganan input dan interrupt juga dipoles hingga layak dipakai nyata
    • Keyboard menangani extended scancode hingga tombol Pause, dan penyimpanan event memakai ring buffer sederhana
    • Mouse memakai function 0x1B dari INT 33h untuk mengambil sensitivitas
    • Joystick membatasi polling sumbu ke sekitar 60 Hz untuk mengurangi biaya BIOS timing loop, sementara tombol tetap selalu dipoll langsung demi responsivitas
    • Kode dan data ISR dikunci untuk mencegah page fault saat interrupt berlangsung
  • Masalah build dan deteksi platform juga diperbaiki
    • Job CI untuk DJGPP ditambahkan, dan deteksi platform DOS untuk CMake ikut dimasukkan
    • SDL_PLATFORM_DOS dimasukkan ke daftar pengecualian SDL_RunApp() agar tidak bentrok dengan launcher khusus DOS
    • Walau DJGPP mendefinisikan __unix__, DOS tidak memiliki GTK atau display server, sehingga SDL_Gtk_Quit() dikecualikan pada DOS untuk mencegah error link
    • Dukungan juga ditambahkan untuk beberapa toolchain DJGPP yang memakai prefiks i386-pc-msdosdjgpp-gcc

Status pengujian dan batasan yang masih ada

  • Pengujian otomatis tidak semuanya berjalan mulus, tetapi sudah mencapai tingkat yang bisa dituntaskan dengan patch
    • Karena ada masalah pada beberapa fungsi formatting standar, pengujian otomatis tidak bisa berjalan sampai akhir, dan pengujian diselesaikan melalui patch pengakalan
    • Masih ada kasus yang gagal, tetapi tidak disertakan karena belum ada keyakinan mengenai cara yang tepat untuk memperbaiki fungsi formatting terkait
    • Sebagian besar demo dirangkum sebagai berjalan pada tingkat yang secara umum sesuai harapan
  • Hasil penggunaan nyata juga ditambahkan
    • Pada DOSBox dan DOS 6.22 di board Vortex86, mode berjendela non-fullscreen berjalan baik baik untuk program uji maupun kode pengguna
    • Namun fullscreen pada saat itu menampilkan layar hitam kosong pada contoh seperti draw.exe --fullscreen
    • Performanya memang lambat, tetapi masih dinilai cukup layak digunakan
  • Beberapa masalah pada program uji juga teridentifikasi
    • sprite.exe langsung keluar di DOSBox
    • wm.exe dan draw.exe tidak merender, tetapi akan keluar saat ESC ditekan
    • testpalette mengalami segfault

Masalah pemilihan kedalaman warna fullscreen dan penyesuaiannya

  • Penyebab langsung layar hitam saat fullscreen adalah perilaku SDL_GetClosestFullscreenDisplayMode() yang jatuh ke mode INDEX8
    • Jika aplikasi tidak bisa menangani rendering INDEX8, layar akan menjadi hitam
    • Implementasi internal menanganinya dengan hanya mempertimbangkan INDEX8 bila pengguna memang sudah memilih mode fullscreen INDEX8
  • Awalnya sempat ditambahkan penanganan untuk menyembunyikan mode INDEX8 di DOS saja lewat SDL_HINT_DOS_ALLOW_INDEX8_MODES
    • Tujuannya agar aplikasi hanya bisa ikut serta secara eksplisit bila memang dapat menanganinya dengan benar
  • Namun di branch utama ternyata sudah ada perubahan yang memilih bit depth tertinggi, bukan terendah, dan alurnya berlanjut untuk memeriksa apakah itu menyelesaikan masalah
    • Perubahan ini memang menyelesaikan masalah bpp, tetapi memunculkan masalah baru: permintaan best fit 640x480 justru memilih 1024x768
    • Perubahan itu akhirnya dibatalkan, dan perbaikan yang lebih baik diputuskan untuk ditangani lewat PR terpisah
  • Pada akhirnya, hint khusus DOS dihapus dan diganti dengan pengurutan mode yang lebih logis
    • Commit Remove SDL_HINT_DOS_ALLOW_INDEX8_MODES and order modes logically ditambahkan
    • Jika #15442 di-merge, maka aplikasi yang tidak mengatur palet atau tidak memilih mode fullscreen secara langsung pun dapat tetap memperoleh pemilihan mode otomatis yang benar
    • Juga ditegaskan bahwa PR ini tidak akan terus menggali semua masalah lama lain di SDL tanpa batas

Perbaikan render demo dan kursor

  • Masalah demo yang tampak hitam tidak ditentukan oleh PR ini saja, tetapi juga bergantung pada status merge #15442
    • Selama SDL_GetClosestFullscreenDisplayMode() masih lebih menyukai kedalaman warna terendah, port ini akan memilih INDEX8, dan jika aplikasi tidak mengatur palet maka hasilnya layar hitam
    • Setelah PR tersebut di-merge secara lokal, dikonfirmasi bahwa semua target pengujian berjalan
  • Masalah visual yang tersisa adalah transparansi kursor
    • Setelah dicek secara lokal, ditemukan tambahan bahwa hanya kursor yang belum transparan
    • Untuk memperbaikinya, dimasukkan commit Don't convert cursor if dest is not INDEX8
    • Setelah perbaikan, versi yang kurang optimal dipakai pada mode RGB, tetapi perilakunya menjadi benar baik pada RGB maupun INDEX8
    • Masih ada ruang untuk performa yang sedikit lebih baik pada XRGB1555 dan RGB565, tetapi prioritasnya rendah

Tinjauan dan keputusan merge

  • PR ini dinilai cocok untuk squash merge
    • GitHub tetap mempertahankan referensi PR pada commit hasil, sehingga proses pengerjaannya tetap bisa dilacak
    • Ada juga usulan untuk menambahkan kredit kontribusi tambahan pada commit hasil
    • Bahkan disertakan kalimat konkret untuk menambah dua Co-authored-by dan satu Tested-by
  • Reviewer menyebut bahwa setelah merge ia akan merapikan kembali sebagian ekspresi dalam script build
  • Tepat sebelum merge final, arahnya diputuskan untuk menggabungkan PR terkait lainnya sekaligus dan lanjut dengan PR DOS ini
    • Setelah “Last call on DOS pull request!”, status merge PR terkait turut dikonfirmasi
    • Setelah itu, perubahan ini di-merge ke main dengan status 46 checks passed
  • Cakupan rilis setelah merge juga dijelaskan dengan jelas
    • Perubahan ini diperlakukan sebagai fitur 3.6.0

    • Tidak di-cherry-pick ke 3.4.x

      • Sehari setelah merge, branch kerja DOS dihapus

Tugas lanjutan dan isu hardware yang masih tersisa

  • Masalah implementasi 4f07(SetDisplayStart) pada sebagian GPU Nvidia yang tidak bekerja dengan benar juga diangkat
    • Bersama tautan ke thread VOGONS, dijelaskan bahwa menurut laporan ada GPU yang terlihat mendukung fitur itu tetapi pada praktiknya tidak berfungsi
    • Disebutkan bahwa cakupan pengujian mungkin lebih luas dari GeForce 9300 hingga 3060, tetapi itu bukan rentang lengkap karena bergantung pada perangkat yang dimiliki
    • Pada pengujian proyek juga teramati gejala tampilan yang sama
  • Menonaktifkan fitur di SDL berdasarkan vendor GPU dianggap bukan pendekatan yang ideal, dan kemungkinan hint untuk kontrol pengguna juga dibahas
    • Arah yang muncul adalah bahwa hint baru agar pengguna dapat mengendalikan page_flip_available secara langsung mungkin lebih baik
    • Hal ini tidak ditangani segera, tetapi ditutup dengan kemungkinan ditambahkan nanti
  • Setelah merge, juga disebutkan hint untuk penggunaan framebuffer langsung
    • Jika SDL_HINT_DOS_ALLOW_DIRECT_FRAMEBUFFER diaktifkan, masalah SetDisplayStart di atas mungkin menjadi jauh kurang penting

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Sekarang, asal ada SDL untuk UEFI, game bisa dijalankan bahkan di lingkungan sebelum OS boot

    • Jadi penasaran apakah Intel Management Engine / Minix yang berjalan di semua chipset Intel itu masih sama seperti sekarang
      Penasaran juga apakah keamanannya sudah jauh lebih ketat, atau masih tetap bisa diakses https://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/
    • Sebenarnya sepertinya tidak sesulit itu
      Hanya saja, setahu saya UEFI tidak punya driver suara, dan sekarang bahkan chip codec audio pun sering hanya punya datasheet khusus NDA, jadi sulit juga kalau harus menulisnya sendiri
      Yang lebih absurd, graphics output protocol tidak punya informasi vsync, jadi blitting tanpa tearing tidak memungkinkan, dan ini secara harfiah lebih buruk daripada VGA
    • UEFI terasa seperti DOS modern
    • Jujur, ini gambaran yang sangat keren
      Bayangkan boot dengan menu seperti grub lalu muncul daftar game klasik, rasanya cukup bikin semangat
    • Singkatnya, ini SDL untuk bare metal

  • Screenshot ini terasa makin lucu karena DosBOX sendiri dibangun di atas SDL

    • Berarti sekarang kita butuh dosbox yang berjalan di dalam DOS
    • Ini benar-benar SDLception

  • Ini memakai DJGPP, jadi CPU dialihkan ke mode 32-bit lewat DPMI
    Jadi nuansa old-school sungguhan dengan segmented memory, near pointer, dan segala macam batasan 64KB tidak terlalu terasa

  • Keren
    Jadi penasaran bagaimana kalau dipakai bersama file executable MS-DOS target 386+ dari FreeBASIC yang mendukung binding SDL
    [1] - https://github.com/freebasic/fbc

    • Saya berniat mencobanya sendiri
      Sudah bertahun-tahun saya berpikir harus mem-porting kembali OHRRPGCE, yang memang berasal dari DOS, ke DOS lagi
      Dan mengingat dulu SDL cukup agresif membuang hampir semua port dan dukungan OS yang ada di era SDL 1.2, cukup mengejutkan bahwa SDL3 mendapatkan kembali dukungan DOS

  • Sempurna
    Pagi ini saya sedang mengembangkan sesuatu di Turbo C di dalam DOSBox-X di dalam Debian GNU/Linux di dalam VMware Fusion di dalam macOS, jadi ini pas sekali

    • Saya benar-benar ingin tahu apakah itu bercanda atau serius
    • Saya sempat bertanya-tanya apakah pernah ada varian turboc untuk Linux
      Saya masih punya ingatan samar pernah mengerjakan sesuatu dengan turboc puluhan tahun lalu
    • Kalau begitu, kemungkinan besar dia juga akan menikmati film Inception :)

  • Secara teknis, ini sebenarnya sudah mungkin dengan HXDOS
    Karena ia mengemulasikan DirectDraw dengan cukup baik sampai SDL bisa memakainya

    • Tunggu, apa?
      Kalau begitu saya jadi penasaran ini dikompilasi untuk target SDL yang mana
      Apakah fullscreen eksklusif Win32, atau resolusi VESA seperti 640x480

  • Dalam proyek open source seperti SDL, dukungan seperti ini biasanya bergantung pada seberapa invasif perubahannya, dan apakah kontributornya benar-benar akan terus merawatnya
    Tiap proyek punya kebijakan berbeda, dan saya tidak tahu kebijakan SDL, tapi karena port-nya sudah banyak, saya rasa mereka tahu sendiri apa yang sanggup mereka tanggung

    • Dukungan untuk arsitektur langka seperti ini hampir selalu ditopang oleh satu orang yang punya mimpi, dan satu pahlawan yang benar-benar mewujudkan serta merawatnya
      Contoh favorit saya adalah openbsd luna88k https://www.openbsd.org/luna88k.html
      Saya sama sekali tidak tahu berapa banyak pengguna nyatanya. Sepertinya itu mesin yang cukup langka dan hanya dirilis di Jepang, dan kalau memang ada penggunanya pun kemungkinan besar kebanyakan ada di Jepang, jadi di luar jangkauan saya, secara praktis terasa seperti hanya ada satu pengguna, yaitu si porter itu sendiri
      Tapi di setiap rilis, beberapa minggu setelah tanggal rilis resmi, dia seperti muncul begitu saja dari hutan lalu mengunggah file dan paket luna88k
      Mungkin memang butuh waktu lama karena dia mengompilasinya di luna88k sungguhan, dan bagaimanapun itu sudah cukup untuk mempertahankannya sebagai platform hardware resmi OpenBSD
      Saya sendiri tidak ingin punya luna88k, tapi saya sangat menghormati orang yang terus membuatnya tetap berjalan

  • Rasanya seperti SDL kembali ke akar era Loki

  • Keren
    Kenapa? Tidak tahu, tapi kalau keren ya keren saja

    • Sekarang kita bisa menjalankan Dota 2 di DOS
    • DOSBox berbasis browser begitu mudah dan cepat dijalankan, sehingga DOS menjadi target yang portabel untuk game kecil maupun game yang cukup serius
      Seperti yang bisa dilihat di Internet Archive, selama ada keyboard dan mouse, tingkat kompleksitas AAA pertengahan 90-an pada dasarnya bisa berjalan hampir di mana saja
      Game seperti Tomb Raider, Command & Conquer, dan Quake termasuk di situ, jadi kalau Anda menginginkan platform yang tinggal jalan, ini cukup menarik
      Dengan adanya SDL, semuanya jadi jauh lebih mudah
    • FreeDOS secara teknis adalah DOS modern yang masih aktif didukung sampai sekarang
    • SDL adalah library multimedia lintas platform, dan DOS juga sebuah platform

  • Senang sekali
    Ini benar-benar membuat saya sangat bahagia