Ninja mèo

File table thực chất là một file text, nội dung của nó là những phép gán: gán một giá trị Hex với một chữ cái. Chẳng hạn, gán 09=A, 0A=B, 0B=C thì chuỗi hex 0x09, 0x0A, 0x0B sẽ được xem tương đương với chuỗi text "ABC". Ta dùng file table vào hai việc: trích xuất text và chèn text. Do vậy cần có hai table khác nhau. Table ngôn ngữ nguồn thì dùng chung với phần mềm trích xuất text như Cartographer. Qua ví dụ các entry trong table trên, khi phần mềm gặp các giá trị hex 0x09, 0x0A, 0x0B thì nó sẽ xuất chuỗi text là "ABC". Còn với table ngôn ngữ đích thì dùng chung với phần mềm chèn text như Atlas. Khi phần mềm gặp chuỗi text "ABC" thì nó sẽ chèn vào rom chuỗi giá trị hex là 0x09, 0x0A, 0x0B.

Để lập file table thì trước hết cần biết giá trị text nào tương đương với ký tự nào trong game. Đối với game Famicom/NES thì đây là việc cực kỳ đơn giản. Hầu hết các phần mềm giả lập kiêm debugger đều có chức năng xem Vram của máy Famicom/NES. Bật game bằng debugger, đến đoạn có text trên màn hình thì bật chức năng CHR Viewer để xem các CHR (viết tắt của "character", nghĩa là thành phần đồ họa) trong Vram tại thời điểm đó. Font chữ cũng là một thành phần đồ họa, nên khi chữ hiện trên màn hình thì có nghĩa là nó đang tồn tại trong Vram tại thời điểm đó. Giá trị của mỗi ký tự trong bộ font chính là số ID/số thứ tự của chr (character/thành phần đồ họa) đó trong Vram.

Chẳng hạn như qua đoạn text mở đầu game, khi xem CHR Viewer thì ta biết ký tự あ có số thứ tự là 0x01, ký tự リ có số thứ tự là 0x14. Do vậy ta lập table là file text có phần mở rộng .tbl với các entry như sau:

01=あ

02=い

03=う

04=え

05=お

....

File table ngôn ngữ nguồn (tiếng Nhật) cần được lưu ở định dạng Shift-JIS. Sau khi lập file table thì bật WindHex, load Rom rồi load file table vừa lập. Lúc này ta có thể xem được text trong Rom, nếu như nó không bị nén. Bước xem text bằng WindHex không phải là bước bắt buộc, hoàn toàn có thể bỏ qua. Ta có thể xác định được vị trí của text trong Rom bằng cách debug. Tuy nhiên, "Ninja mèo" là một trong số ít ỏi game Famicom có lượng text khá nhiều (so với mặt bằng chung của Famicom/NES) nên việc dùng WindHex sẽ giúp ta nắm bắt được vị trí của text trong Rom tốt hơn.

Mở rộng Rom là một khái niệm thường gặp trong mảng hack Rom. Việc này giúp ta có thêm không gian trống để chứa code mới cũng như bản dịch. Thường thì bản dịch sẽ tốn nhiều không gian hơn ngôn ngữ gốc, và đôi khi là cần phải thêm code mới, nhiều chức năng mới để hỗ trợ ngôn ngữ đích. Nếu như Rom gốc còn nhiều không gian trống thì ta có thể lợi dụng những chỗ trống đó để chứa code mới, bản dịch ngôn ngữ đích. Nếu như Rom gốc không còn đủ chỗ trống thì ta cần phải mở rộng Rom. Kích thước của Rom NES được quy định ở 0x10 byte ở phần header, tuy nhiên thủ thuật mở rộng Rom không chỉ đơn giản là chèn thêm byte trống vào trong Rom gốc. Có một số công cụ giúp việc mở rộng Rom trở nên đơn giản hơn, chẳng hạn như phần mềm Nflate. Tuy nhiên, những phần mềm này không hoạt động đúng với 100% Rom. Lúc đó, ta cần phải mở rộng Rom bằng tay với kiến thức về Mapper. May thay, Ninja mèo không phải là Rom đặc biệt cần phải mở rộng theo cách thủ công. Tính khả thi của việc mở rộng Rom còn nằm ở yếu tố dung lượng của Rom gốc so với dung lượng tối đa của kiểu Mapper đó cho phép. Do vậy ta cần xác định kiểu Mapper cũng như dung lượng của Rom gốc.

Đối với Ninja mèo, Rom gốc có kích thước (gồm cả PRG và CHR) là 256 KB và kiểu Mapper là MMC3. Một số Debugger như Mesen hay FCEUX đều có chức năng thông báo kiểu Mapper của Rom.

Sau khi xác định được kiểu Mapper, việc cần làm tiếp theo là xác định dung lượng tối đa của nó. Theo thông tin tại trang này (click) thì kiểu Mapper MMC3 cho phép dung lượng PRG tối đa là 512 KB và CHR là 256 KB. Như vậy, ta hoàn toàn có thể nới rộng dung lượng của Rom gốc Ninja mèo. Khi mở rộng Rom, ta có hai lựa chọn là mở rộng PRG bank và mở rộng CHR bank. Nếu không có nhu cầu vẽ thêm hình ảnh vào bản dịch thì thông thường, chỉ cần mở rộng phần PRG bank là đủ không gian trống để chứa code mới và bản dịch.

Sau khi mở rộng Rom, ta đã sẵn sàng để dịch từ ngôn ngữ nguồn sang ngôn ngữ đích. Tất cả mọi đoạn hội thoại trong game này đều được hiển thị trong một khung thoại. Quan sát kỹ thì sẽ thấy khung thoại được vẽ với chiều cao chiếm gần một nửa chiều cao của màn hình, bề ngang chiếm gần hết màn hình, trừ 2 khoảng đen như hình dưới đây.

Ta có thể mở rộng khung thoại này, để nó mở rộng về hai bên tả hữu, tận dụng được không gian viết chữ. Nhưng đầu tiên cần phải tìm hiểu về cách mà máy vẽ khung thoại này như thế nào. Đầu tiên, ta cần xác định cách mà một thành phần đồ họa bất kỳ thuộc khung thoại này được ghi vào PPU như thế nào. Muốn biết được cách mà tile đồ họa đó được ghi vào PPU như thế nào thì cần xác định vị trí (địa chỉ) trong PPU mà tile sẽ được ghi vào. Đối với các Debugger có chức năng cho xem Nametable thì việc xác định này cực kỳ đơn giản. Chẳng hạn như tile đồ họa ở góc trái trên cùng của khung thoại xuất hiện ở màn hình đầu tiên có địa chỉ PPU là $2201, số ID của tile đó là 0x77.

Việc tiếp theo là đặt break point trong chức năng Debugger. Break point được hiểu nôm na là "điểm dừng". Khi CPU đọc đến lệnh thỏa mãn điều kiện được đặt ra trong break point thì nó sẽ tạm dừng xử lý tại vị trí đó, cho ta biết mọi thông tin về địa chỉ lệnh, dữ liệu liên quan đến mệnh lệnh đó. Có 3 kiểu break point là: đọc, ghi, thi hành. Ở đây, ta cần xác định cách mà giá trị tile 0x77 được ghi vào địa chỉ PPU $2201 như thế nào, do đó ta cần đặt break point ghi vào PPU với địa chỉ $2201. Khi có bất kỳ giá trị nào được ghi vào địa chỉ $2201 trong PPU thì toàn bộ hệ thống sẽ tạm dừng hoạt động. Cách đặt break point như hình minh họa dưới đây.

Sau khi đặt break point như vậy, ta sẽ thấy CPU dừng xử lý mỗi khi có giá trị được ghi vào địa chỉ $2201 trong PPU, nhưng không phải tất cả chúng đều là thứ ta cần tìm. Chỉ khi giá trị 0x77 được ghi vào $2201 mới là lúc ta cần quan tâm.

Ta có thể đặt điều kiện khi đặt break point để CPU chỉ dừng khi có giá trị chỉ định được ghi vào địa chỉ chỉ định. Cách này sẽ giúp ta tìm ra được routine mong muốn nhanh hơn.

Khi CPU thi hành tới dòng lệnh thỏa mãn với điều kiện được đặt ra trong break point thì nó sẽ tạm dừng mọi hoạt động. Lúc này ta có thể thấy giá trị 0x77 được ghi vào PPU tại dòng lệnh STA $2007 ở địa chỉ $E1FA trong PRG Rom. Địa chỉ này tương ứng với $81FA trong CPU Memory. Do Ninja mèo là Rom với Mapper MMC3, kích thước mỗi bank là 0x2000 byte nên địa chỉ $E1FA tương ứng với bank $07 ($E1FA chia cho $2000 = $07). Bank $07 bắt đầu từ địa chỉ $E000 trong PRG Rom ($07 x $2000 = $E000), mà ta đã biết các bank trong PRG Rom được copy vào CPU map mỗi khi cần đến. Cụ thể, các PRG bank được chiếm vị trí từ $8000 đến $FFFF trong CPU Memory. Do vậy, địa chỉ $8000 trong CPU Memory sẽ là nơi bắt đầu của các PRG bank khi chúng được copy vào đây. Và như vậy, địa chỉ $E1FA trong PRG Rom sẽ tương đương với địa chỉ $81FA trong CPU Memory.

Nhìn lên một chút thì ta thấy routine này bắt đầu tại địa chỉ $E1EC trong PRG Rom, tương đương với $81EC trong CPU Memory tại thời điểm đó. Đặt break point thi hành tại địa chỉ $E1EC trong PRG Rom thì ta có được toàn bộ routine như dưới đây.

org $81EC

JSR $8F6D

LDA #$00

STA $00

_81f3:

JSR $820D

LDY #$00

-

LDA ($01),y //$9034

STA $2007

INY

CPY #$0E

BNE -

INC $00

LDA $00

CMP #$20

BNE _81f3

JMP $81BE

_820D:

LDA #$0C

STA $2000

LDA #$22

STA $2006

LDX $0000

STX $2006

LDA $900A,x

TAX

LDA $902A,x

STA $01

LDA $902B,x

STA $02

RTS

org $8F6D

SEI

LDA $1C

AND #$7F

STA $2000

LDA $1D

AND #$E6

STA $2001

RTS

Mở đầu routine này là một đoạn code tại subroutine tại $8F6D với nội dung ghi giá trị vào Register $2000 và $2001. Đây là các Register trực tiếp điều khiển các chức năng của màn hình, nhưng ở đây chúng không đóng vai trò quan trọng lắm. Tiếp theo, ta để mắt tới subroutine tại $820D. Giá trị 0x0C được ghi vào Register $2000. Giá trị này có bit 2 được set, cho thấy sau mỗi lần ghi vào PPU, địa chỉ PPU gia tăng thêm 32 tile, mà màn hình Famicom/NES gồm 32 tile (mỗi tile 8x8 pixel) nên điều này có nghĩa là sau mỗi lần ghi tile đồ họa thì tile đồ họa tiếp theo sẽ nằm ngay bên dưới tile liền trước. Điều này cho thấy khung thoại được vẽ lần lượt từ trên xuống dưới, từ trái qua phải.

Cũng tại subroutine này, ta thấy địa chỉ PPU, nơi bắt đầu được ghi hình ảnh là $2200. Đây là nơi bắt đầu được vẽ của cột khung thoại đầu tiên. Những cột tiếp theo được bắt đầu từ địa chỉ $2201, $2202,... và tất cả chúng đều được chỉ định ở địa chỉ $00 trong CPU Memory. Các ID của tile đồ họa cấu thành nên khung thoại được chỉ định ở địa chỉ ($01), cụ thể là $9304 trong CPU Memory. Các địa chỉ từ $900A trở đi là pointer chỉ đến các địa chỉ chứa ID đồ họa của khung thoại. Ta chỉ cần chỉnh sửa lại phần dữ liệu này là ta có thể thay đổi cách vẽ để mở rộng khung thoại như dưới đây.

Trong phần trước, ta đã lập được file table. Thực chất đây chỉ là file text đơn giản mà nội dung chính của nó là phép gán. Gán một giá trị hex nào đó cho một ký tự nào đó, khi đó thì những phầm mềm xem text như Windhex sẽ thể hiện text tương ứng với giá trị hex mà nó đọc được. Chẳng hạn, nếu trong file table của ta có phép gán 90=G thì khi phần mềm gặp giá trị hex 0x90 thì nó sẽ hiển thị chữ cái "G". 

Sau khi lập table, ta dễ dàng tìm thấy đoạn text mở đầu game trong Windhex. Tuy nhiên, vẫn còn một số chỗ chưa hiển thị được text như những vùng khoanh trắng dưới đây.

Điều này có nghĩa là trong file table mà ta vừa lập vẫn còn thiếu các giá trị gán. Nói cách khác là nó chưa hoàn chỉnh. Nhưng mà trong phần trước, ta đã ghi lại toàn bộ chữ cái trong Nametable vào file table này rồi, sao lại có chuyện thiếu được! Thật ra thì code table hiển thị text của một game bất kỳ không chỉ là mã hex của bảng chữ cái, mà còn bao gồm cả code điều khiển các chức năng đặc biệt, chẳng hạn như: code thông báo chấm hết câu thoại, CPU đừng đọc thêm nữa, đừng ghi ra màn hình nữa; code thông báo xuống dòng, dòng tiếp theo sẽ được viết ở vị trí thấp hơn so với dòng đầu; code thông báo thay đổi nhạc nền; code điều khiển màu chữ; code điều khiển tốc độ hiển thị chữ; vân vân. Người ta gọi chung những code chức năng này là "control code". Những code này không làm hiển thị chữ cái ra màn hình, nhưng trực tiếp điều khiển các chức năng liên quan tới văn bản như vừa kể. Control code xuất hiện trong tất cả game có hiển thị chữ ra màn hình, và Ninja mèo không phải là ngoại lệ.

Như vậy, nhiệm vụ tiếp theo của ta là bổ sung những control code này vào table để có được cái nhìn đầy đủ nhất về cách hiển thị chữ ra màn hình. Việc này khá đơn giản. Đầu tiên, cần xác định những mã hex chưa xuất hiện trong table. Sau đó, thay thế giá trị hex của một đoạn text bất kỳ mà ta đã biết trước bằng mã hex còn thiếu đó rồi quan sát sự biến đổi trên màn hình. Ví dụ, nếu thay một giá trị text bất kỳ bằng 0xF8 và kết quả là đoạn text ngay sau 0xF8 được viết thấp hơn dòng trước đó thì ta biết 0xF8 là code báo hiệu xuống dòng. Lặp lại quá trình trên cho những mã hex chưa biết khác thì ta được những kết quả sau.

F5=MTE

F7= tốc độ text

F8= xuống dòng

F9= xóa cả text

FA= đợi

FB= xóa một ký tự

FC=chuyển đổi bản chữ Kana

FD=cử động miệng cho nhân vật

FE=dừng cử động miệng cho nhân vật

FF= kết thúc text

Trong tất cả các control code này thì đáng chú ý nhất là F5. Đây là code thể hiện MTE (Multi Tile Encoding), một kỹ thuật nén text đơn giản, cho phép dùng một hoặc một số byte nhất định để thể hiện nhiều ký tự. Với cách hiển thị chữ thông thường, trên màn hình có bao nhiêu ký tự thì trong Rom chứa chừng đó mã hex tương ứng. Còn với MTE, một mã hex trong Rom có thể tương đương với nhiều ký tự trên màn hình, thậm chí là cả một đoạn văn bản. Do vậy, kỹ thuật này được vận dụng để tiết kiệm dung lượng Rom, nhưng thời gian xử lý của CPU sẽ kéo dài hơn. Mọi việc đều có cái giá của nó. Đây là một khía cạnh khác của định luật bảo toàn, một quy tắc bất di bất dịch của vũ trụ.

Thông thường, cú pháp của MTE sẽ là một byte báo hiệu MTE (trong game này là F5), nối tiếp sau đó có thể là một hoặc nhiều byte index tương đương với từng chuỗi text. Chẳng hạn:

F500=ABCDE, F501=FGHIJKLMNOPQRS, F502=TUV, vân vân.

Không khó để xác định các entry của MTE trong Ninja mèo. Ta chỉ cần làm theo cách mà đã xác định control code là được: thay thế lần lượt các giá trị F500, F501, F502,... vào vị trí text đã biết rồi quan sát kết quả thay đổi ra sao. Làm xong bước này là ta đã hoàn thiện toàn bộ table cho Ninja mèo. Kết quả như dưới đây.

Ý nghĩa của việc lập table là để dễ dàng xác định được địa chỉ của text trong Rom mà không cần debug; và để dump (trích xuất) text từ Rom, chuẩn bị cho bản dịch. Tuy nhiên, để dịch được thì trước hết ta cần hiểu được cách vẽ chữ ra màn hình, để từ đó chỉnh sửa thành routine hiển thị đầy đủ dấu tiếng Việt cho bản dịch. Để xác định được routine vẽ chữ thì cần set break point tại vị trí mà chữ cái được ghi ra màn hình.

Trước khi đi vào phần chính là hack routine hiện chữ thì ta cần trích xuất (dump) text. Mục đích của việc này là để xuất toàn bộ lời thoại trong game (tiếng Nhật) ra file text để thuận tiện cho việc dịch thuật. Với Windhex, ta dễ dàng xác định được địa chỉ của khối text trong game. Địa chỉ của những đoạn text này được chỉ định qua pointer ở địa chỉ $0C trong CPU memory. Routine đọc text ở $8E50 trong CPU memory.

org $8E50

LDA ($0C),y

INC $0C

BNE +

INC $0D

+

RTS

CPU sẽ đọc 1 byte tại địa chỉ được chỉ định ở $0C và $0D. Giả dụ, giá trị tại $0C là 53 và giá trị tạo $0D là A0 thì CPU sẽ đọc dữ liệu tại $A053 trong CPU. Do vậy, ta có thể dùng phần mềm Cartographer để trích xuất text theo giá trị pointer theo script và được kết quả như dưới đây.

 Tuy nhiên, cần lưu ý là trong Ninja mèo, không phải tất cả mọi câu thoại đều có pointer. Đây là một điểm khá lạ lùng, khác biệt với phần lớn game khác. Lời thoại trong Ninja mèo nằm trong chuỗi hoạt cảnh (anime), và người ta đặt timing cho mỗi câu thoại. Chỉ có những câu thoại mở đầu chuỗi hoạt cảnh là có pointer. Còn những câu thoại sau đó được đọc tại địa chỉ ($0C) bằng cách gia tăng giá trị tại địa chỉ này sau khi kết thúc câu thoại trước. Điều này có nghĩa rằng trong Rom không chứa pointer của những câu thoại nối tiếp những câu thoại mở đầu hoạt cảnh. Do vây, việc trích xuất text theo pointer như trên là chưa đủ, mà cần phải trích xuất theo địa chỉ tuyệt đối của text (kiểu RAW trong Cartographer).

Còn khi dịch thì cần dịch theo pointer cho câu thoại mở đầu hoạt cảnh, nối tiếp sau đó là những câu thoại sau không cần pointer. Dĩ nhiên những câu thoại phải được ngăn cách với nhau bằng Control code báo kết thúc câu (end) như ví dụ dưới đây. Đoạn text mở đầu hoạt cảnh đụng độ trùm ở màn 1 (hóa ra người ngoài Địa cầu...) được chỉ định ở pointer ($F9CA), nhưng đoạn text sau đó (Sàm xí đú....) không có pointer, mà được CPU đọc liền mạch sau khi chuỗi ở $F9CA kết thúc.

Ta đã biết giá trị của ký tự được ghi lên màn hình trong kỳ Nmi, mỗi "ký tự" được ghi 2 lần, gồm phần trên (các dấu trọc âm, bán trọc âm) và phần dưới (chữ Kana). Do vậy, có thể dùng luôn chức năng này để ghi dấu tiếng Việt (phần trên) và chữ cái (phần dưới). Đoạn code dưới đây bổ sung thêm chức năng ghi dấu nặng ngay bên dưới chữ cái.

lda {text_trigger}

beq +

lda {sitaten}

sta $2007

lda #$00

sta {text_trigger}

lda #$4c

sta {sitaten}

+

jmp _fce7

Nguyên lý hoạt động ở đây là ngoài phần dấu bên trên, phần chữ cái thì còn ghi thêm giá trị của dấu nặng bằng cách đọc ram tại địa chỉ {sitaten}. Nếu đó là text không chứa dấu nặng thì địa chỉ này chứa giá trị của khoảng trắng. Giá trị này được ghi ngay bên dưới ký tự qua register $2007 mà không cần tính toán lại địa chỉ PPU nếu như bit 3 của register $2000 được set. Nếu trạng thái của bit này là reset thì cần phải tính toán lại địa chỉ PPU, nếu không thì dấu nặng sẽ xuất hiện theo hàng ngang, bên cạnh chữ cái thay vì ngay dưới chữ cái. Cần lưu ý trong đoạn code trên nó là một thành phần của routine đa mục đích. CPU dùng routine này để vẽ mọi thứ ra màn hình, gồm sprite, background và cả text (cũng là background), cho nên nếu mọi giá trị đều được ghi thêm một giá trị khác ngay bên dưới nó thì trên màn hình sẽ xuất hiện nhiều thành phần đồ họa không mong muốn. Do vậy ta cần giới hạn để đoạn code ghi dấu nặng trên chỉ hoạt động khi ghi text, bằng cách kiểm tra flag {text_trigger} trước khi ghi. Flag này được set tại routine đọc giá trị của chữ ngoài kỳ nmi.

Một vấn đề khác cần lưu ý khi ghi dấu nặng, là hiện tượng dấu nặng của dòng chữ bên trên bị che mất bởi dấu trên đầu (sắc, huyền, hỏi, ngã, móc, mũ,... hay không dấu) của hàng dưới. Chi tiết về khuyết điểm này cũng như cách khắc phục đã được nêu rõ trong bài viết về Contra (click).

Một điểm lưu ý khác là text gốc (tiếng Nhật) có dung lượng nằm gọn trong một bank (0x2000 byte), nhưng khi dịch thì dung lượng này sẽ phình ra rất nhiều. Đó là quy luật tất yếu của mọi bản dịch. Do vậy, một bản dịch đàng hoàng tử tế luôn chiếm dung lượng gấp vài lần so với bản gốc. Để khắc phục giới hạn này thì ta cần mở rộng Rom bằng phần mềm nflate rồi ghi dữ liệu text vào những bank trống, buộc CPU đọc dữ liệu text ở bank mới bằng cách chuyển đổi bank.

Ninja mèo là Rom với mapper MMC3, có cách chuyển đổi bank bằng cách ghi giá trị vào register $8000 và $8001. 

Ngoài phần ghi text thì bản dịch cần phải trải qua rất nhiều công đoạn chỉnh sửa để hoàn thiện. Chẳng hạn như chỉnh lại vị trí của con trỏ di chuyển, vì độ dài của text gốc và test sau dịch khác nhau; chỉnh lại vị trí khung thoại; sửa lại những đoạn text phụ như màn hình Game over, màn hình nhập Password; chỉnh sửa lại màn hình đầu tiên;... Những công đoạn này tốn nhiều thời gian và đôi khi là khó hơn cả phần text chỉnh. 

Bản dịch Việt ngữ của Ninja mèo này ở mức hoàn thiện 100% những thứ cần chỉnh sửa. Bạn có thể tìm thấy mọi thứ từ tập mã nguồn bản dịch ở phần bên dưới.