Pada bulan Maret-Mei tahun ini, saya menghabiskan beberapa minggu (di malam hari dan akhir pekan) untuk memindahkan mainan Lode Runner dari BK-0010 ke UKSC.Cuplikan layar menu porting:
Layar permainan versi porting:
BK-0010 adalah komputer rumah tangga pada akhir 1980-an dan awal 1990-an, dan sebagian lagi komputer sekolah (kelas KUVT-86). UKSC adalah komputer sekolah tahun 1990-an. BC dan UKSC sebagian kompatibel dalam arsitektur dan sistem perintah - kedua komputer berasal dari keluarga PDP-11.Pilihan permainan
Sampai tahun ini, saya tidak menulis sesuatu yang serius di bawah UKSC, tetapi saya harus memahami kode mesin. Ada keinginan untuk menulis sesuatu, tetapi biasanya saya memiliki masalah besar dengan waktu luang, sehingga tidak akan berhasil dari awal. Dan sebagai permulaan, lebih baik mengambil tugas lebih mudah. Saat porting, jumlah pekerjaan biasanya jauh lebih sedikit daripada saat menulis dari awal - Anda terutama menghadapi masalah ketidakcocokan antara kedua sistem.Di forum zx.pk.ru (salah satu tempat di mana penggemar retrocomputing pada umumnya dan mesin yang kompatibel dengan PDP-11 pada khususnya nongkrong), peserta hobot memuji implementasi Lode Runner di BC - ini sebenarnya alasannya, untuk awalnya saya mencoba untuk “melihat” pada kode mainan , yah, terlibat.Menu versi asli:
Layar game dari versi asli (pada monitor warna):
Rekayasa terbalik
Beberapa minggu di malam hari dan akhir pekan saya menghabiskan waktu menganalisis dan membongkar. Dalam emulator, BKBTL menambahkan kemampuan untuk mengumpulkan jejak - yaitu, setiap instruksi dibongkar dan disimpan ke file teks.Saya menjalankan bagian yang menarik minat saya dengan merekam jejak, kemudian saya mematikan jejak (sort & uniq) - Saya mendapatkan potongan-potongan logika. Saya menambahkan komentar untuk ini, saya secara bertahap mendapatkan file umum.Kedengarannya sederhana, tetapi sebenarnya itu adalah pekerjaan yang agak rumit berdasarkan dugaan dan konfirmasi atau sanggahan mereka. Sebagai contoh, kita melihat bahwa alamat 001756 sebelum dimulainya permainan mendapat nilai 10, kemudian dikurangi, ketika mencapai 0, permainan berakhir - tampaknya, ini adalah jumlah nyawa. Kami menemukan konfirmasi ini, kami menempatkan komentar pada teks di mana alamat ini muncul. Ini adalah contoh yang cukup sederhana, dalam kasus yang lebih kompleks saya menghabiskan banyak waktu untuk mencari tahu apa yang terjadi.Ketika volume yang diterima menjadi cukup besar (40+ KB teks, lebih dari 1.500 baris) dan saya menemukan setidaknya secara umum apa yang terjadi, bagaimana itu disimpan dan ditampilkan - saya mulai berpikir bagaimana menerjemahkannya ke UKSC.Di sini Anda dapat melihat daftar akhir yang dihasilkan dari pembongkaran:github.com/nzeemin/uknc-loderunner/blob/master/original/loderunner.lstLabirin
Setiap labirin adalah 20 garis 30 blok, total 600 blok.Jenis blok dikodekan oleh angka dari 0 hingga 7 - tiga bit, triplet. Untuk satu kata 16-bit, 5 triplet lengkap diperoleh.Ketika bekerja dengan mesin seperti PDP-11, sistem 8-desimal banyak digunakan, oleh karena itu cukup nyaman untuk menggunakan kembar tiga.Akibatnya, setiap labirin cocok menjadi 240 byte.Jenis Blok:; 0
; 1
; 2
; 3
; 4
; 5
; 6
; 7
Sprite dari objek-objek ini disusun dalam urutan penomoran tipe blok. Ketika labirin didekodekan, pada saat yang sama "gambar labirin" dibuat dalam memori (dengan byte per blok), dan keadaan awal labirin digambar di layar.Organisasi layar
Pada BC, layar dialamatkan langsung oleh akses memori, garis-garis berjalan satu demi satu, sebenarnya itu adalah "framebuffer", dan saya akan mengatakan bahwa ini hebat - sangat nyaman untuk pemrograman grafis. Line BC - 256 piksel warna, 64 byte per baris. Tetapi berapa banyak piksel dalam satu baris tergantung pada bagaimana Anda menghubungkan monitor:jika dalam warna hitam dan putih, maka itu adalah 512 b / w piksel dalam satu baris (1 bit per piksel, 8 piksel per byte),dan jika itu untuk output warna , maka ini adalah 256 piksel warna per baris (2 bit per piksel, 4 piksel per byte).Di UKSC, organisasi layar benar-benar berbeda, dan jauh lebih rumit. Layar terletak di tiga blok memori, tiga "paket". Dan setiap piksel adalah tiga bit, sedikit di setiap bidang - kami mendapatkan 8 warna. Di UKSC kami memiliki beberapa mode video - 640 × 288, 320 × 288, 160 × 288, lebih tepatnya, kami selalu memiliki tepat 288 garis dan Anda dapat menerapkan pembagi Anda sendiri untuk setiap baris individu, mendapatkan resolusi horizontal yang berbeda. Untuk central processing unit (CPU), paket layar tidak dapat diakses secara langsung, hanya melalui akses ke port. Selain itu, hanya dua dari tiga paket yang tersedia untuk CPU.Dalam hal ini, mode 320 × 288 cocok untuk saya - garis diperoleh dalam 320 piksel warna sepanjang 80 byte di masing-masing dari tiga paket. Jika Anda menggunakan dua paket, maka pikselnya juga empat warna - hampir seperti pada BC.Perpaduan
Dia mulai menulis contoh dalam assembler dari UKSC dan sedikit tertekan - karena siklus "dikompilasi - terhubung - diluncurkan" agak lambat. Masalahnya ada di alat. Ada MACRO11 lintas-assembler, meskipun agak buggy. Tetapi tidak ada cross-linker. Tapi untungnya, belum lama berselang Patron memposting konsol RT-11: zx-pk.ru/showthread.php?t=24755 - sebenarnya itu adalah emulator dari mesin yang kompatibel dengan PDP11 yang berinteraksi dengan baris perintah OS seperti halnya dengan terminal. Dengan demikian, menjadi mungkin untuk menyusun dan menghubungkan sarana asli RT-11. Ini saya anggap sebagai terobosan nyata, secara dramatis mempercepat pekerjaan.Setelah itu, semuanya berjalan dengan baik, saya membuat gambar dari frame lapangan bermain, merender sprite, menemukan cara mencampur bit dalam sprite (saya menulis sebuah program dalam C # untuk mencampurnya), kemudian dalam blok saya mulai mentransfer kode dari file bersama dengan disasma ke sumber baru. Saya mengambil dump memori dari BC, mengalokasikan blok di mana levelnya, utilitas RT11 DUMP membuat buku teks untuk level-level tersebut.Pertama, saya mentransfer satu blok kode yang menampilkan level, dalam hal ini saya mengurangi output sprite. Kemudian dia mulai mentransfer logika permainan. Itu secara umum, transfer hampir satu-ke-satu, dengan pengecualian tempat di mana layar berjalan. Oleh karena itu, ada beberapa tempat dalam logika yang saya tidak mengerti bagaimana mereka bekerja (AI AI yang sama), tetapi itu tidak masalah - yang utama adalah mereka bekerja.Sebagai hasilnya, pada awal Mei (ketika pekerjaan utama menyerap saya lagi), sebuah opsi kerja diperoleh, meskipun tanpa suara.Foto permainan yang sedang bekerja di mesin nyata (terima kasih hobot):
Referensi