Bunkai's Tinkering, Serve yourself (games with table and text offsets included)

Started by Bunkai, September 09, 2022, 01:21:38 PM

Previous topic - Next topic

Bunkai

Since I've been tinkering with a few 'simple' games to see what complexities they have to be still untranslated, making the progress as far as getting the font and the text located. I decided to follow some threads like filler's https://www.romhacking.net/forum/index.php?topic=27126.0 (Don't expect my work to be that precise and well writen tho, I'm pretty dispersed).

I will probably keep tinkering about these games or add more names to the list, the info will be updated in such case, that was why I decided to create this thread. Besides, this are just random tinkering days, not actual full projects of mine.

If anyone is interested in working on them, just leave a comment and copy whatever it helps you (I may have a bit more behind the curtains but the key parts are here).

// I'll put the offsets with commands in a way that work in Cartographer (tested myself) so I belive it would be easy to use with atlas and abcd.

Anyways, here's the current list & info:

Ojarumaru : Tsukiyo ga Ike no Takaramono GBC
Text offsets:
  Story
Spoiler
 
#GAME NAME:      Ojarumaru - Tsukiyo ga Ike no Takaramono

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $7815E
#SCRIPT STOP:      $7B0A0
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $79F02
#SCRIPT STOP:      $7B0A0
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $7B16D
#SCRIPT STOP:      $7B1B6
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $800E6
#SCRIPT STOP:      $80124
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $803E0
#SCRIPT STOP:      $804AA
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80530
#SCRIPT STOP:      $80556
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $805DA
#SCRIPT STOP:      $80600
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80709
#SCRIPT STOP:      $807AB
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80861
#SCRIPT STOP:      $80896
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $808E9
#SCRIPT STOP:      $8090D
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80940
#SCRIPT STOP:      $80956
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80BB9
#SCRIPT STOP:      $80C90
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80EF9
#SCRIPT STOP:      $80F5E
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81053
#SCRIPT STOP:      $810B0
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81257
#SCRIPT STOP:      $812AE
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 01(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $813E6
#SCRIPT STOP:      $813FE
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 02(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $814B5
#SCRIPT STOP:      $8154E
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 03(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81772
#SCRIPT STOP:      $8181A
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 04(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81A02
#SCRIPT STOP:      $81ADF
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK
[close]
Dialogue
Spoiler
#GAME NAME:      Ojarumaru - Tsukiyo ga Ike no Takaramono

#BLOCK NAME:      Dialogue 00(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $7815E
#SCRIPT STOP:      $7B0A0
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 01(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $79F02
#SCRIPT STOP:      $7B0A0
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 02(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $7B16D
#SCRIPT STOP:      $7B1B6
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 03(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $800E6
#SCRIPT STOP:      $80124
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 04(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $803E0
#SCRIPT STOP:      $804AA
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 05(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80530
#SCRIPT STOP:      $80556
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 06(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $805DA
#SCRIPT STOP:      $80600
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 07(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80709
#SCRIPT STOP:      $807AB
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 08(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80861
#SCRIPT STOP:      $80896
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 09(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $808E9
#SCRIPT STOP:      $8090D
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 10(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80940
#SCRIPT STOP:      $80956
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 11(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80BB9
#SCRIPT STOP:      $80C90
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 12(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $80EF9
#SCRIPT STOP:      $80F5E
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 13(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81053
#SCRIPT STOP:      $810B0
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 14(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81257
#SCRIPT STOP:      $812AE
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 15(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $813E6
#SCRIPT STOP:      $813FE
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 16(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $814B5
#SCRIPT STOP:      $8154E
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 17(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81772
#SCRIPT STOP:      $8181A
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK

#BLOCK NAME:      Dialogue 18(RAW)
#TYPE:         NORMAL
#METHOD:      RAW
#SCRIPT START:      $81A02
#SCRIPT STOP:      $81ADF
#TABLE:         Ojaru_tsukiyo_GBC.tbl
#COMMENTS:      Yes      
#END BLOCK
[close]
Table:
Spoiler
00=
01=あ
02=い
03=う
04=え
05=お
06=か
07=き
08=く
09=け
0A=こ
0B=さ
0C=し
0D=す
0E=せ
0F=そ
10=た
11=ち
12=つ
13=て
14=と
15=な
16=に
17=ぬ
18=ね
19=の
1A=は
1B=ひ
1C=ふ
1D=へ
1E=ほ
1F=ま
20=み
21=む
22=め
23=も
24=や
25=ゆ
26=よ
27=ら
28=り
29=る
2A=れ
2B=ろ
2C=わ
2D=を
2E=ん
2F=っ
30=ぁ
31=ぃ
32=ぇ
33=ぉ
34=ゃ
35=ゅ
36=ょ
37=ア
38=イ
39=ウ
3A=エ
3B=オ
3C=カ
3D=キ
3E=ク
3F=ケ
40=コ
41=サ
42=シ
43=ス
44=セ
45=ソ
46=タ
47=チ
48=ツ
49=テ
4A=ト
4B=ナ
4C=ニ
4D=ヌ
4E=ネ
4F=ノ
50=ハ
51=ヒ
52=フ
53=ヘ
54=ホ
55=マ
56=ミ
57=ム
58=メ
59=モ
5A=ヤ
5B=ユ
5C=ヨ
5D=ラ
5E=リ
5F=ル
60=レ
61=ロ
62=ワ
63=ン
64=ッ
65=A
66=B
67=ェ
68=ォ
69=ャ
6A=ュ
6B=ョ
6C=。
6D=゛
6E=゜
6F=、
70=‐
71=「
72=」
73=!
74=?
75=ー
78=月
79=光
7B=丸
7C=<lagrima>
7D=<heart>
7E=~
7F=...

FE=[BRK]\r
FF=[END]\n\r
[close]
Images to prove it:
Spoiler
[close]

Gakkyuu Ou Yamazaki (Rev A) GBC
Text offsets: None (Look at the images for an starting point)
 Hiragana Table:
Spoiler
20=
21=!
28=(
29=)
2D=ー
2E=.
30=0
31=1
32=2
33=3
34=4
35=5
36=6
37=7
38=8
39=9
3F=?
7E=~

A6=を
A7=ぁ
A8=ぃ
A9=ぅ
AA=ぇ
AB=ぉ
AC=ゃ
AD=ゅ
AE=ょ
AF=っ
B0=ー
B1=あ
B2=い
B3=う
B4=え
B5=お
B6=か
B7=き
B8=く
B9=け
BA=こ
BB=さ
BC=し
BD=す
BE=せ
BF=そ
C0=た
C1=ち
C2=つ
C3=て
C4=と
C5=な
C6=に
C7=ぬ
C8=ね
C9=の
CA=は
CB=ひ
CC=ふ
CD=へ
CE=ほ
CF=ま
D0=み
D1=む
D2=め
D3=も
D4=や
D5=ゆ
D6=よ
D7=ら
D8=り
D9=る
DA=れ
DB=ろ
DC=わ
DD=ん
DE=゛
DF=゜

0D0D=[BRK]
0E=[KANA_End]
0F=[KANA_Ini]
[close]
The Katakana table uses identical data, it swappes both in running time, which mean you can do mostly everything only with one.

Images to prove it:
Spoiler

Animastar GBC
Text offsets:
Spoiler

 #GAME NAME:      Animastar

 #BLOCK NAME:      Story 00(RAW)
 #TYPE:         NORMAL
 #METHOD:      RAW
 #SCRIPT START:      $17C020
 #SCRIPT STOP:      $17D710
 #TABLE:         Animastar.tbl
 #COMMENTS:      Yes      
 #END BLOCK
[close]
Table
Spoiler
00=グ
01=ゲ
02=ゴ
03=ザ
04=ジ
05=ズ
06=ゼ
07=ゾ
08=ダ
09=ヂ
0A=ヅ
0B=デ
0C=ド
0D=バ
0E=ビ
0F=ブ
10=ベ
11=ボ
12=パ
13=ピ
14=プ
15=ペ
16=ポ
17=ァ
18=ィ
19=ゥ
1A=ェ
1B=ォ
1C=ャ
1D=ュ
1E=ョ
1F=ッ
20=ー
21=、
22=。
23=!
24=?
25=.
26=:
27=(C)
28=+
29=-
2A=*
2B=/
2C=「
2D=」


30=0
31=1
32=2
33=3
34=4
35=5
36=6
37=7
38=8
39=9
3A='ST'
3B='E'
3C='SP'


3F= 
40=A
41=B
42=C
43=D
44=E
45=F
46=G
47=H
48=I
49=J
4A=K
4B=L
4C=M
4D=N
4E=O
4F=P
50=Q
51=R
52=S
53=T
54=U
55=V
56=W
57=X
58=Y
59=Z

5E=@

7F=[BRK]

80=あ
81=い
82=う
83=え
84=お
85=か
86=き
87=く
88=け
89=こ
8A=さ
8B=し
8C=す
8D=せ
8E=そ
8F=た
90=ち
91=つ
92=て
93=と
94=な
95=に
96=ぬ
97=ね
98=の
99=は
9A=ひ
9B=ふ
9C=へ
9D=ほ
9E=ま
9F=み
A0=む
A1=め
A2=も
A3=や
A4=ゆ
A5=よ
A6=ら
A7=り
A8=る
A9=れ
AA=ろ
AB=わ
AC=を
AD=ん
AE=が
AF=ぎ
B0=ぐ
B1=げ
B2=ご
B3=ざ
B4=じ
B5=ず
B6=ぜ
B7=ぞ
B8=だ
B9=ぢ
BA=づ
BB=で
BC=ど
BD=ば
BE=び
BF=ぶ
C0=べ
C1=ぼ
C2=ぱ
C3=ぴ
C4=ぷ
C5=ぺ
C6=ぽ
C7=ぁ
C8=ぃ
C9=ぅ
CA=ぇ
CB=ぉ
CC=ゃ
CD=ゅ
CE=ょ
CF=っ
D0=ア
D1=イ
D2=ウ
D3=エ
D4=オ
D5=カ
D6=キ
D7=ク
D8=ケ
D9=コ
DA=サ
DB=シ
DC=ス
DD=セ
DE=ソ
DF=タ
E0=チ
E1=ツ
E2=テ
E3=ト
E4=ナ
E5=ニ
E6=ヌ
E7=ネ
E8=ノ
E9=ハ
EA=ヒ
EB=フ
EC=ヘ
ED=ホ
EE=マ
EF=ミ
F0=ム
F1=メ
F2=モ
F3=ヤ
F4=ユ
F5=ヨ
F6=ラ
F7=リ
F8=ル
F9=レ
FA=ロ
FB=ワ
FC=ヲ
FD=ン
FE=ガ
FF=ギ
[close]
Images to prove it:
Spoiler

Doraemon - Aruke Aruke Labyrinth
 Text Offset: Not found yet, however the font and many graphic texts can be seen uncompressed. See images.
Images to prove it:
Spoiler

Ultraman Chou Toushi Gekiden
 Text Offset: See images.
 
Spoiler
00=
10=あ
11=い
12=う
13=え
14=お
15=か
16=き
17=く
18=け
19=こ
1A=さ
1B=し
1C=す
1D=せ
1E=そ
1F=た
20=ち
21=つ
22=て
23=と
24=な
25=に
26=ぬ
27=ね
28=の
29=は
2A=ひ
2B=ふ
2C=へ
2D=ほ
2E=ま
2F=み
30=む
31=め
32=も
33=や
34=ゆ
35=よ
36=ら
37=り
38=る
39=れ
3A=ろ
3B=わ
3C=を
3D=ん
3E="
3F=
40=?
43=ゅ
44=ょ
77=.
FE=[BRK]
FF=[END]
[close]
Images to prove it:
Spoiler

Ojarumaru - Gekkouchou Sanpo de Ojaru
Font:
Spoiler
Address 0x3E6394
4BPP GBA
Pattern: 16x32
[close]
Curiosity leads to knowledge,
be curious.

Bunkai

Mindseeker .nes
CRC32: AA6D602C

Text from the begining of the game at 00008B00.

Note that the control codes in the text are:
   FF + a number, and 00 00 00 FF
Reminder: the NES console is Little Endian

Table (incomplete):
Spoiler
00=[LN]\r
FF21=[INI]
00FF=[PAGE]\n\r

01=
02=
03=
04=
05=が
06=ぎ
07=ぐ
08=げ
09=ご
0A=ざ
0B=じ
0C=ず
0D=ぜ
0E=ぞ
0F=だ
10=ぢ
11=づ
12=で
13=ど
14=
15=
16=
17=
18=
19=ば
1A=び
1B=ぶ
1C=べ
1D=ぼ

24= 

40=ア
41=イ
42=ウ
43=エ
44=オ
45=カ
46=キ
47=ク
48=ケ
49=コ
4A=サ
4B=シ
4C=ス
4D=セ
4E=ソ
4F=タ
50=チ
51=ツ
52=テ
53=ト
54=ナ
55=ニ
56=ヌ
57=ネ
58=ノ
59=ハ
5A=ヒ
5B=フ
5C=ヘ
5D=ホ
5E=マ
5F=ミ
60=ム
61=メ
62=モ
63=ラ
64=リ
65=ル
66=レ
67=ロ
68=ヤ
69=ユ
6A=ヨ
6B=ワ
6C=ヲ
6D=ン
6E=
6F=ュ
7C=ョ
7D=ッ

80=あ
81=い
82=う
83=え
84=お
85=か
86=き
87=く
88=け
89=こ
8A=さ
8B=し
8C=す
8D=せ
8E=そ
8F=た
90=ち
91=つ
92=て
93=と
94=な
95=に
96=ぬ
97=ね
98=の
99=は
9A=ひ
9B=ふ
9C=へ
9D=ほ
9E=ま
9F=み
A0=む
A1=め
A2=も
A3=ら
A4=り
A5=る
A6=れ
A7=ろ
A8=や
A9=ゆ
AA=よ
AB=わ
AC=を
AD=ん
AE=っ
AF=ゅ

B1=っ
B2=
B3=
B4=ょ
B5=
B6=。
B7=ー
BA=!
BF=「
C0=」

C5=ガ
C6=ギ
C7=グ
C8=ゲ
C9=ゴ
CA=ザ
CB=ジ
CC=ズ
CD=ゼ
CE=ゾ
CF=ダ
D0=ヂ
D1=ヅ
D2=デ
D3=ド
D4=
D5=
D6=
D7=
D8=
D9=
DA=
DB=
DC=
DD=
DE=
E0=パ
E1=ピ
E2=プ
E3=ペ
E4=ポ
[close]
Curiosity leads to knowledge,
be curious.

MontyMole

Gakkyu Oh aka Class King Yamazaki or Rey de Clase for Spanish speakers. Can remember seeing the anime of that about 20 years back on holiday in Portugal. Not sure how good the game is or how much there is to translate, the anime was quite fun IIRC. 
A log of some kind.
. Videuss (Youtube)
it's not the official way and relies on luck\randomized placement of bears. USC

Bunkai

Quote from: MontyMole on October 29, 2022, 09:26:17 AMGakkyu Oh aka Class King Yamazaki or Rey de Clase for Spanish speakers. Can remember seeing the anime of that about 20 years back on holiday in Portugal. Not sure how good the game is or how much there is to translate, the anime was quite fun IIRC. 

The game is mostly about breeding a poop (yes, you read it right, like a Vpet). It's full of word plays, and puns like in the anime.

---

Back to the thread Idea:

One of my first attempts to romhacking was when the digivice ver. Portable, for the PSP, released (Beginning of 201X... Old times x)

- ISO: Digivice_Ver_Portable_JPN_PSN_PSP-PLAYASiA.iso
       CRC32:  986e0198
       SHA1:   e15cd56748525babbb402868ea3df8b44bb6a5c8
       SHA256: ae16195736eb15ba9b2b93f1af31a55401097bc8dff2edf22f304cf4abc69fbc

I found text for activating/deactivating Wi-Fi was, so I decided to check if I can find it again with more knowledge now, and make it public. (I had no luck this time, maybe trying just 1 hour because I have other priorities was not enough). I did find text (EDIT 28/Dec/2022). More info later.

My memory wants to believe I used the CPK and I didn't have to put any language format, but in case it's tricking me, remember this for windhex:
https://www.romhacking.net/utilities/291/
> Options > View text data as Japanese (ctrl+D)



Anyway, here's the info for those who want to try themselves for the first time.
The first steps are:

- Open and extract your ISO files with umdgen (https://www.romhacking.net/utilities/1218/)



- Then somehow following part of this tutorial, or at least using the tools here
https://dbxvmods.freeforums.net/thread/3/cpk-unpack-repack

- Drag n Drop your data.cpk file (\PSP_GAME\USRDIR\FILEDATA.CPK) in the CriPakTools-master
folder

- Double-click on 1-EXTRACT_ALL(no_decompression).bat



- Open files with Windhex, they are in UTF8, so you shouldn't have problems to see the text in there. From here on, you'll know how's everything sorted in the files.




> The problem now is where i went from here... What I do remember tho is finding a website where someone had half of the game text, but not the exact part I found (the system part).

I deleted my files since I thought the authors of the web were to find the remaining text. Sadly now I am not able to find that web, and unable to see any game/system text, even if only to show a proof...   There are some images and videos of a patch that existed with it, and you can see system text later here: (EDIT 28/Dec/2022).

As things are at present, with all this info, going farther is up to the reader (you).
[From current knowledge and some of those files text, you'll want to check the .bin for in-game texts. ]



Images from this post in a batch at https://imgur.com/a/6U3A2X5


UPDATE: when I did this for the first time being a complete noob I went full hex, but today (2022) I know I have read about this in https://haroohie.club/blog/2022-11-02-chokuretsu-archives/ Where they use the debugger, spoiler to avoid flooding.
Spoiler
Find this text in the link and read from that on:

"First, we should try to find the code where these archives are parsed. "

After that, remember that the link's guide is for the NDS, you'll have to extrapolate the procedure and do it with the PPSSPP emulator & debugger (https://www.ppsspp.org/downloads.html).
[close]


EDIT 28/Dec/2022: I did find text, but I forgot to look for the proper words this time (Dec 14th), that happens for trying to use words from memory instead of replaying. So I had to try using the same app I used in the past, and voilà.
Open https://astrogrep.sourceforge.net/ and look for はじめから


From that you can also guess the file with that text is the "33" from the extracted above (which is proven true).
Here the next questions arise, should you work on the cpk as one file, or should you work in the "33" file. And in both cases, what's the best method to work from this point on.




PS: Since I believe this one should have very short text and mostly menus and system (which means it can be done fairly quick), I would like to help with the translation had someone decide to do it.
Curiosity leads to knowledge,
be curious.

Bunkai

Quote from: Bunkai on December 14, 2022, 02:04:46 PMOne of my first attempts to romhacking was when the digivice ver. Portable, for the PSP, released

Update:

With help from the rhdn discord in general and Fothsid in particular I understood that:

Opening the file with the hex editors:
Crystal tile
https://www.romhacking.net/utilities/818/

windhex and the Shift-JIS Table:

table: https://www.romhacking.net/documents/442/
https://www.romhacking.net/documents/179/

We can learn that

Text version with all they said:
Spoiler
so, 16 byte header with "TXTD", 4 byte version number, 4 byte string count number and 4 bytes of padding. then a table of 4 byte numbers, each one of them contains an offset to a string

0x1D (29) total string count

at 0x84 starts the first string
at 0x109 starts the second
at 0x17c startd the third
etc
[close]
We could now make a change of the text with length variation as a proof if we wanted.

After this update we had on the text, the next part I want to do is finding the rest of the info we need to make the translations and other modifications, for that, as I said I am gonna use the https://haroohie.club/blog/2022-11-02-chokuretsu-archives/ guide. Besides, I also check some sites like: https://datacrystal.romhacking.net/wiki/Blaze_Union:Tutorials about the PPSSPP debugger and https://github.com/uofw/upspd or
https://gbatemp.net/threads/psp-debugging.452408/ To find info about PSP and in some cases info on UMDs (this is not of our interest right now, but for those who is, i'll leave you the spoiler)
Spoiler
The PSP's user memory space starts at 0x08800000, so if that's what you dumped, you need to add 0x08800000 to the address you data is on the dump.

Each UMD sector is 0x800 bytes (2Kb)
[close]

Back to the debugger, to get the gist of it, We'll try to find the font using the file and the text we have.

An update here will be done when I have the time to do it in a few days. Until then, happy incoming new year, and happy romhacking.

With emulation running, we can open the debugger by pressing CTRL+D, however for our case, push CTRL+G to open GE (for graphics) debugger . The window appears with blank data at first.


Click the "Step Frame" button on the upper left of the window, now you'll see data:


After that, you should Click "Step Tex" until you get to the full English font texture and click "Step Prim". However (in this digivice case it won't show a full font and you'll need to click "Step Prim" from the beginning until you see an image like the one below:

* The はじめから text is in white and with that background it's a bit difficult to see, this is a dump of it:

However you can see the red square signaling は.
Curiosity leads to knowledge,
be curious.

Bunkai

Ok, I decided to work around the last debugger options and went to Using step tex until the very moment before the text,

If we read a few lines below, we see the  "set Vertex Type."

From past info, we know that's the routine to print the text, so those instructions load the text from memory into vAddress. If we go to the calling address (0x 0893D730) in the CPU debugger (CTRL+D) we can see there's some data in there.
We can set a break point here and see what happens...
We are at:

let's continue with step into until we got to the exact previous call before the text.

Now we have the address of the line when the routine loads each character into the screen, the sanity check is setting a break point here and step through, the next break should be right before the next character. But working on VRAM
we better just "step count" and set a number of character to see if that exact number is printed

Useful reading

https://haroohie.club/blog/2022-11-02-chokuretsu-archives/

https://gbatemp.net/threads/psp-asm-hacking-for-variable-width-font.374967/page-3

https://gbatemp.net/threads/psp-debugging.452408/

https://ffhacktics.com/smf/index.php?topic=12359.0  (PSP docs)

(PSP's CPU module for ghidra)
https://github.com/kotcrab/ghidra-allegrex/blob/master/README.md
Curiosity leads to knowledge,
be curious.

Bunkai

I'll write this down before I forget or something.

After the previous post block, I read and asked a few things in the RHDN discord.
Thanks to that, and Mugi for answering, I got new info about how to approach the PSP romhacking.

Summarized in TXT
Spoiler
    well, PSP translations are just a move from PS2
    literally same thing except better organized lol'

    as far as PSP itself goes, its MIPS, ppsspp debugger is god tier,
    ghidra can literally reduce it back to C and there's tools for basically all
    the commonly used formats you find from most games
    proprietary files are as they are with anything else, just figure it out
    that's more general reverse engineering than just "how to hack PSP"

    to get started, get armips for writing assembly,  https://www.romhacking.net/utilities/635/
    deceboot for decrypting the elf files, https://www.romhacking.net/utilities/1225/
    UMD stream composer for video and Sony's atrac3decoder for audio
    the rest pretty much goes to the "general reverse engineering" which is platform-agnostic
    its little endian and PSP games love using zlib for compression (HW decoder)
    gimconv for graphics I guess. most nonstandard files are indexed 256 colors something something
    that's about the TLDR of it

    pointer tables are generally relative if they're in an external file
    strings in an elf are relative to 8804000 or 8804000 + 10000
    they can either be 32bit values or 2 16bit values depending on how its implemented
[close]

That lead to go back at the file and info we got in
Quote from: Bunkai on December 31, 2022, 07:43:50 AMUpdate:

With help from the rhdn discord in general and Fothsid in particular, I understood that:

Opening the file with the hex editors:

windhex and the Shift-JIS Table:

table: https://www.romhacking.net/documents/442/
https://www.romhacking.net/documents/179/

We can learn that

Text version with all they said:
Spoiler
so, 16 byte header with "TXTD", 4 byte version number, 4 byte string count number and 4 bytes of padding. Then a table of 4 byte numbers, each one of them contains an offset to a string

0x1D (29) total string count

at 0x84 starts the first string
at 0x109 starts the second
at 0x17c started the third
etc
[close]
We could now make a change of the text with length variation as a proof if we wanted.

From that, Mugi pointed out that it was time to make a tool to look into those files

Spoiler
Mugi
    well there you go
   
Bunkai
    but that's not all the text and there are more files and similar pointer tables,
    I need to use that info to look through the other files
    I'm dumb, I know
   
Mugi
    if you have an external file like this, it's always a good idea to search for
    the start addresses of the strings pointer tables are seldom overcomplicated

Bunkai
    I have that in the foremost part of the cpk. But I got a question then,
    how do i use that to open the files??
   
Mugi
    I mean, if you want to edit them, avoiding examining them is probably
    not a good idea :P
    you make a tool that reads the file now that you know the specification and dumps
    it into something more convenient to edit for such files as your image,
    i generally just make a tool that stores the strings and constructs the header
    and pointers at rebuild

Mugi
    or just do it in armips
    because it's easy
    and it takes me a forever to code tools in C

Bunkai
    i'll try that. Time to learn properly how to do such tools
    (it will be my first on that matter)
   
Mugi
    I don't really program myself either, so it's always a pain in the ass
    I mean I do, but only assembly :P
    honestly, if I have a file like this with nothing but a pointer table and strings
    I just use armips https://www.romhacking.net/utilities/635/
    because you can just have the string, then assign a label for it and make a table for the pointers, then whatever you do with the strings it'll just deal with the pointers automatically
    so you can literally just write the strings and you're done
[close]
Mugi also give an example to base on
.psp
.open "whatever.bin" 0x0

; header

    .ascii TXTD    ; signature
    .word 0x01    ; version
    .word 0x1D    ; file count
    .word 0x00    ; unknown

: TOC

    .word    string001, string002        ; ...... continue until all the pointers are listed

; string data

    string001:
    .asciiz "this is text"
    .align 4

    string002:
    .asciiz "this is more text"
    .align 4

.close
After that a few more guidelines and/or reasons have been said:
Spoiler
Mugi
   and you're literally done
   now you can just use armips to patch it over a file
   or you can change the .opne to .create and make it generate a new file for you
   just dont copy that file verbatim, no idea if the syntax is correct since i
   just wrote it off my head :P but gives you the idea

Bunkai
   I'll try and use it a bit and then I'll be using it as a base to create some for the other files
   thanks
   
Mugi
   nowadays I used it for basically everything I do assuming it's capable of it
   (so generally just simple files like this)
   i see no reason to write a new tool for everything because you can just do it
   with armips and store it neatly as .asm files

   armips has a pretty good readme for how to use its functions
   for this kind of file I really just write it out into an asm file and see if i
   can rebuild it identical to the original
   once that's done

   like
   just put the original strings into the asm file
   then assemble it, and compare it to the original file
   if your asm file generates an identical file, you succeeded

Bunkai
   disassamble without dissassembling
   
Mugi
   also use .sjis and .sjisn instead of .ascii and .asciiz if you store
   japanese text otherwise it's not going to like you
   
   the cool thing with the way I use armips is that you can literally just do that,
   and that's your patch, no need to make xdeltas or whatevers
   
Bunkai
   and the step about understanding the file and opening is needed in any case

Mugi
   the .asm file is your patch and your tool :P
   of course, this is just a very simple example
[close]

With that in mind, the next steps are precisely create and test those new script/tools.

An update here will be done when I do it.
Curiosity leads to knowledge,
be curious.

Bunkai

Quote from: Bunkai on January 05, 2023, 08:57:13 PMI'll write this down before I forget or something.

Tried "The Mugi way" of creating an exact copy from scratch, using https://github.com/Kingcom/armips , it really does show a good eye at this. Not many people can see a file and create a copy like that.
Here's a working sample code (basically fixed a few simple syntax mistakes and add a bit of info to make an easy comparison):

.psp
.create "new33" , 0x0

; header

    .ascii "TXTD"    ; signature
    .word 0x01    ; version
    .word 0x1D    ; string count
    .word 0x00    ; unknown
    .word 0x84    ; offset_first_string
    .word 0x0109   ; offset_second_string
    .word 0x017C   ; offset_third_string
    .word 0x01A9   ; offset_forth_string
   
    ; remaining string dir go here, for this sample we'll jump those
    ; offset_first_string - num_Bytes_already_Writen = 0x84 - 0x07 = 0x7C
    .org 0x7C      ; Goes to first string offset to start writing 

; TOC

    .word    string001, string002        ; ...... continue until all the pointers are listed

; string data

    string001:
    .sjis "記録メディアを検出することができませんでした。"
    .align 4

    string002:
    .asciiz "this is more text"
    .align 4

.close

Image Proof below


For those images with PNG format:

If you're lucky, you can just add the extension and you'll have the original:

For this PSP game, the files 26, 27, and 28 are PNG files that work just like that.

I have learned a good 'out of the box' approach, very useful for giving new points of view. However, I am not even close to that good, and it would take me light years to create everything. So I decided to try the commoner method of tinkering with the actual original file next (it means using a high language to dump it). Time to make a sample with this one.

Will update the post or the thread when I have more to show.
Curiosity leads to knowledge,
be curious.

Bunkai

I'm still dealing with the tool from the previous post, meanwhile I decided to repack the ISO and see an effect in the actual game. To do that, I was going back again to https://dbxvmods.freeforums.net/thread/3/cpk-unpack-repack but after introducing the edited files and the FILEDATA.CPK in the Repacker CPK folder.


I didn't get to make it work. So I decided to try with other methods. Being one of them http://aluigi.altervista.org/quickbms.htm with the README at https://aluigi.altervista.org/papers/quickbms.txt and selecting the script for CPK http://aluigi.altervista.org/bms/cpk.bms 

Files I used: FILEDATA.CPK ; cpk.bms ; quickbms.exe ; reimport2.bat


Following the on-screen instructions, I made it work easily to extract and reimport. When It was done, I just went to UMDgen again and changed the FILEDATA.CPK with the new one to make sure it worked. IT DID!

Note: Some of the files extracted from quickbms hinted at GIM files, to use those go to  https://forum.xentax.com/viewtopic.php?t=6313
Spoiler
Re: Tool for encoding image (png, jpg, etc) to GIM (PSP)?

Post by akadewboy » Fri Apr 01, 2011 9:11 pm
This is what I do when I work with PSP GIM files:

1. Convert it to PNG using GimConv

gimconv "s_ui_mp_01.gim" -o "s_ui_mp_01.png"
2. Convert the new 8bit+Alpha PNG to 32bit PNG using pngout.

pngout "s_ui_mp_01.png" "s_ui_mp_01(32bit).png" /c6 /force
3. Edit s_ui_mp_01(32bit).png with whatever graphic program you want (I use Gimp).

4. Convert s_ui_mp_01(32bit).png to 8bit+Alpha PNG using pngnq

pngnq -s 1 -n 256 "s_ui_mp_01(32bit).png"
5. Use GimConv to convert s_ui_mp_01(32bit)-nq8.png into a GIM

gimconv "s_ui_mp_01(32bit)-nq8.png" --format_style psp _ End Of Post _


Later with help, I learned that you need to add this code block to the GimConv.cfg file, in order to make this game's PSP GIM files. Then you can add -qbb to the CLI (command line instruction)

Code from Ethanol:
//--------------------------------------------------------
//  PSP digivice GIM specific options
//--------------------------------------------------------

option -digi {
    image_format = index4
    format_style = psp
    format_endian = little
    output_image = on
    output_palette = on
    output_sequence = on
    check_limit = off
}
Which means that now we can do a "input.GIM" == "output.GIM" sanity check:
gimconv "input.GIM" -o "output.GIM" -digi
[close]
This means we have the proper format of the gim file, and we can now keep going with the other steps.
My happiness didn't last long tho, because when I tried to modify the same text from before, and save it.


The game booted up but crashed at the start screen.

To find where the problem was, I checked changing the CPK with CrystalTile


And saved the project in UMDGen again. Since It worked, I know the problem has something to do with how I changed the text in the file, and the size of the string.
 

EDIT Jan/18/2023 : After updating the ASM file and rerunning quickbms, I got it to work properly (still needs some twists tho)


My next target is unpacking this:


After that, I guess I'll have to use this
https://www.psdevwiki.com/ps3/GimConv (this is only the doc, you'll have to find the tool on your own)
To use as a test file, I took a GIM file from here: https://www.romhacking.net/forum/index.php?topic=25396.0 and the process from akadewboy above worked, giving me a proper PNG.

After that,  I've been talking with Mugi today about this very file, and he has teached me a lot of things. I'll be doing that now. I leave the info here for anyone who is interested in learning about it.

Spoiler
Mugi
   figuring out how the file works is just a matter of analysis,
   
   it looks like its just 24 bit header,
    a toc (table of contents, its the address table)
        and data;
   signature, something, something, something, probably packing mode, and number of files,
   
   the TOC seems to be filesize, offset, signature, and a null
   null could be used for something like compression flag or what not.
   
   for simple extracting and rebuilding it with modified files, you dont really need
   anything else than the TOC and the actual data anyway
   also notice how the TOC says 20E0 but the file starts at 20D8 it accounts for the header
   possibly unless its filesize, lol

   the 3836F8 is the start offset and its absolute
   you can see it on the first picture its the first file
   the first picture shows the first TOC entry to be 20E0 (filesize) and 21D8 (start address)
   the second picture shows the header of the first actual file which is 21D8

   on the second picture you just see the last entry of the TOC, which is again 20E0 (filesize)
   and 3836F8 (start address)
 
   that picture also confirms that the last entry of the header is indeed a file count
   it says that the file count is 21C
   and in the TOC each entry is 16 bytes wide, so you have 0x21C0 x 0x10
   21C0 + the size of the header is 21D8
   which is the start of the first file

   simply by knowing one value in such a file you can determine the rest by process of
   elimination its just simple math

.psp
.open "00000000.pbi", 0x0

; header

    .asciiz "BIN"
    .word 1
    .word 1
    .word 0
    .word 4
    .word 0x0000021C

; TOC
    ; filesize / startaddr. / extension / null

    .word filesize("file000001.gim"), file00001addr
    .asciiz "GIM"
    .word 0

; --------add rest of TOC here

file00001addr:
    .incbin    "file00001.bin"

    ; ------add rest of files here


.close

   it just takes a moment to fill them up with that many files
   thats the downside of how i do it :P

   the point is you can label the included files, and use the labels to write the TOC
   for dumping its a bit more annoying.
   for small containers with only few files you can do it by hand, you can just do like

.create "bndres/jis2ucs.bin", 0x0
.import "AdvSys.bnd", 0x800, 0x20000
.close

   you create the file you want, and you use armips to import the data
   from given offset into the new file
   import takes arguments for start offset and size, its pretty self explanatory
   i really dont recommend doing that for containers with hundreds of files though
   it'll take a good while to write
[close]
With Mugi's explanations and this https://www.vg-resource.com/thread-28180.html I'm writing a script to unpack them.

Will update the thread when I do it with some images and info.
Curiosity leads to knowledge,
be curious.

Bunkai

I got the file unpacked, here's the first GIM sprite in PNG as proof:


And this is a preview of the unpacker script:
# script for QuickBMS http://quickbms_aluigi_org
# script for unpacking 00000000.pbi file from the CPK in Digive Ver. Portable (PSP)

endian little             # The file is for a PSP game, hence little endian 


# Header

idstring "pBin"            # File format

get unknown long        # 0x01     
get unknown long        # 0x01     
get null long
get unknown long         # 0x04     
get num_Files long        # 0x1C02 Number of files in the pack

# Table Of Contents

# First and Second as example
# 1: 0xE020 (filesize) and 0xD821 (start address)
    # get fileSize long        # 0xE020
    # get offset long        # 0xD821
# 2: 0x47494D (header of the first actual file), 0xE020 (filesize), and 0xB842 (start address)
# ...


# Actual unpacking

# get the first file since it's different from the rest
    get length long            # getting eight bytes and storing it as the variable 'length' (filesize).
    get pointer long            # getting eight bytes and storing it as the variable 'pointer' (offset).

    log pbi_file pointer length    # takes values from above: an offset of a file, an output name and a length of the file,
                                # and writes a new file.
Full version will be released when the project is finished, with a nice github repo with everything used organized

For the record, the commands from the screen (outside of the lcd part) are still missing. Oh, and the font, I need to find that too.
The text inside the LCD is all there (from the look of it).
Spoiler
コウゲキ Atacar
シンカ Digievolución > Digi-Evo (reduced size to fit)
ナカマ Aliado
ニゲル Huir
パラメーター Parámetros
マップ Mapa
チリョウ Curar
ツウシン Conectar/link

バトルスタート Iniciar batalla/Start batlle
ニク Carne
プロテイン Proteína
PW-B   Píldora DP+
P-ドラッグ Píldora HP+

エリアクリアー Acabado/Cleared
ノウホスウ ( 総歩数 = Total steps) Restante/Remaining
サウンド Sound
オン On
オフ Off

アグモン Agumon
ガブモン Gabumon
ピヨモン Piyomon
パルモン Palmon
テントモン Tentomon
ゴマモン Gomamon
パタモン Patamon
グレイモン Greymon
ガルルモン Garurumon
バードラモン Birdramon
トゲモン Togemon
カブテリモン Kabuterimon
イッカクモン Ikkakumon
エンジェモン Angemon
メタルグレイモン MetalGreymon
ワーガルルモン WereGarurumon
ガルダモン Garudamon
リリモン Lilimon
アトラーカブテリモン AtlurKabuterimon
ズドモン Zudomon
ホーリーエンジェモン HolyAngemon
ブイドラモン Veedramon
プロットモン Plotmon
テイルモン Tailmon
エンジェウーモン Angewomon
ウォーグレイモン WarGreymon
メタルガルルモン MetalGarurumon
ホウオウモン Hououmon
ロゼモン Rosemon
ヘラクラカブテリモン HeraclesKabuterimon
ヴァイクモン Vikemon
セラフィモン Seraphimon
オファニモン Ophanimon
オメガモン Omegamon
クワガーモン Kuwagamon
デビモン Devimon
エテモン Etemon
メタルティラノモン MetalTyranomon
メタルシードラモン MetalSeadramon
メガドラモン Megadramon
ムゲンドラモン Mugendramon
アポカリモン Apocalymon
クネモン Kunemon
ギザモン Gizamon
ガジモン Gazimon
バケモン Bakemon
オーガモン Ogremon
スカモン Sukamon
シェルモン Shellmon
ダークティラノモン DarkTyranomon
ゲコモン Gekomon
エアドラモン Airdramon
[close]
Next step is edit one of those images and repack it. As double check and preparation for later.

I made a mistake, the PBI file doesn't give specific names to each GIM file. quickBMS uses the default renaming system and adds no extension, if you add the extension one by one or with a script like I did, you can work with the images, but reinsertion doesn't recognize the new files because they are not "000000".
 I have to fix that, and then everything should work without problem, until then:


More info will be up when I have it
Curiosity leads to knowledge,
be curious.

Bunkai

Since I made that mistake with the unpacker and I was more interested in finding the rest of the text, I did so...

Looking around I remembered some files are stored in the boot and eboot bin,
http://gitaroopals.shoutwiki.com/wiki/PSP:Patching_the_executable_(BOOT.BIN)
So I decided to try my luck with those files, inside SYSDIR:
(BOOT.BIN ; EBOOT.BIN ; OPNSSMP.BIN)


I see nothing apparently useful in BOOT.BIN or OPNSSMP.BIN. My last chance of something easy was in the unencrypted version of EBOOT.BIN, I created a new clean folder, I put my EBOOT.BIN and used DecEboot: https://www.romhacking.net/utilities/1225/
deceboot EBOOT.BIN
LUCKY! I hit another jackpot,

Seems like I will have to read this ( http://gitaroopals.shoutwiki.com/wiki/PSP:Patching_the_executable_(BOOT.BIN)  ) very carefully because it will be more useful than it has been already.

Now I have to see how to deal with that to get it working for my intentions.
[And I also have to find a few images: Title from title screen, warning / loading / intro screen, and save icons again]

I tried to exchange the old EBOOT.BIN with the new decrypted EBOOT.BIN obtained with DecEboot and it worked flawlessly. Steps to check:
Open the decrypted EBOOT with crystal tile and make a text edit in some text you can see easily:

Then reinsert that EBOOT file and save it with UMDGen

Check results and enjoy your achievement



Edit Jan / 24th / 2023:
With slight modifications, we can use the unpacker of 00000000.pbi for 00000001.pbi
And the file PLYT seems to have a few images, and guess what? We unpack it with the same script
This file contains the Wi-Fi icon of the right upper corner has the right upper connection icons.
After looking at the icons, I remembered about astrogrep and did the search for PNG and GIM strings in the files:  https://imgur.com/a/3DjqlMX

I discovered how to add the extension properly to the files, and it fixed the reinsertion.
# get the first file since it's different from the rest
    get length long            # getting eight bytes and storing it as the variable 'length' (filesize).
    get pointer long            # getting eight bytes and storing it as the variable 'pointer' (offset).
    string pbi_file + ".extension"
    log pbi_file pointer length    # takes values from above: an offset of a file, an output name and a length of the file,
                                # and writes a new file.
To be reinserted with this method needs to be equal or less than the original size tho.

All strings have now a beta in game version.

Next is trying to make edited images back into the iso
To be found yet: Title-Screen, Icons, Caution Screen (They are low priority for the game to be playable tho)
Spoiler
And a QOL bonus, in relation to the steps to clear the areas
Using artmoney  https://www.artmoney.ru/e_download_se.htm
I got this RAM address:
00959724 Remaining steps
00959728 Walked steps
 that used in the cheat.db for the PPSSPP following this guide https://www.almarsguides.com/retro/walkthroughs/PSP/HowToUsePSPCodes/
_S NPJH-00126
_G Digivice Ver. Portable (Japan) PSP ISO
_C0 Edit remaining Steps
_L 0x000000959724 0x00000000    // remaining steps
_C0 Edit walked Steps
_L 0x000000959728 0x00000000    // Walked steps
It needs a bit of work but that's the beginning.
[close]

_____________________________

I wanted to know an approximation of the patch size, so I create a patch to see:
(All text is changed here, not the sprites yet tho)

I put all the needed files in a folder to make it quick and easy, but you can have them anywhere you want.  We'll use this tool: https://www.romhacking.net/utilities/598/
(Digidemo.iso ; Digivice_Ver_Portable_JPN_PSN_PSP-PLAYASiA.iso ; xdelta.exe ; xdeltaUI.exe)



Now open (double-click on) xdeltaUI.exe and go to Create Patch.
Click in each button or write the file routes and fill the blankets. You'll have something like this:



Now click on the patch button, wait a few seconds and a window will appear to tell you everything went well. You have successfully created your patch.



As you can see, my current beta patch is 2.31 MB:



Hopefully the size won't be outrageous after the images are edited.
Curiosity leads to knowledge,
be curious.

Bunkai

After fighting with The Gim files for some time, I started talking with Ethanol about the non 1:1 gimconv command. Then thanks to him I could make a "copy filed" with the tool, which means I have the proper and exact format I need to create those for reinsertion.

We also ended up talking about the reinsertion and the pbi files that has those, which leads to me finding and fixing what I had wrong in my script.
# First file explained as example
# 1: 0xE020 (filesize) and 0xD821 (start address), 0x47494D (header of the first actual file)
    # get fileSize long            # 0xE020
    # get offset long            # 0xD821
    # getdstring pbi_file 0x8    # 0x47494D
Then create a loop for all files in the pbin archive using the header I already had.

Once I had that, We talked about the 2nd pbin file being over dumped, which lead me to discover the bms script I was using for unpacking the CPK was Wrong. And once more talking with them, I was told about another tool for repackaging related with the one I used at the very beginning of the project but this time I was guided to review the version and thanks to that I have now a proper unpack with the remaining files I didn't have.
Here you can see:
The font  (file 29, open with CrystalTile2 to see: BGA 4bpp "tiled" with 16x16 tiles, thanks to Ethanol for that one, I overlooked it completely)


And the other images I wanted for a proper translation
(files: 14 - Saving_Icon ; 16 - Title_Screen ; and 18 - CautionMessage+Intro)


With all of these, I wanted to reinsert and check if the new tool version worked. So I did, thanks to his help I got the version I needed for the project to work. You can see the CriPackedFileMaker (from the proper "crifilesystem" version) in the works.
First, it was required to get the CPK original info, so we use that to reinsert.
Data alignment: 2048 ; File Mode: ID ; any other box unmarked.

After that, we can extract and start the repackaging without edits as a sanity check (if it hadn't worked, we would've known it was some config on the tool):

Finally, we have our "complete" prompt


I did that and later changed an image to be completely sure I can mod the game now:
With that, it's proven.

Edit 29 / Jan / 2023

Create a procedure to make the PNG back into gim with same size as the original:
:: Script to get a 1:1 size from a full process
:: of image conversion GIM to PNG to GIM
:: (It will use the GIS format as a bridge).


:: First sanity check
:: GIM to GIS
:: gimconv A_input.gim -o A_outputGIM.gis -digi
:: and GIS to GIM
:: gimconv A_outputGIM.gis -o A_output.gim -digi
:: Then compare both GIM files to see if they are the same
:: pause
:: Our first sanity checked concluded happyly, we can now start our work now:


:: Second sanity check
:: GIM to PNG
:: gimconv A_input.gim -o A_outputGIM.png -digi
:: GIM to GIS to PNG
:: gimconv A_input.gim -o A_outputGIM.gis -digi
:: gimconv A_outputGIM.gis -o A_outputGIS.png -digi
:: Then compare both GIM files to see if they are the same
:: pause
:: Our second sanity checked concluded happyly, we can now start our work now:


:: Let's see what are the differences between
:: PNG to GIS output
gimconv A_outputGIM.png -o A_outputPNG.gis -digi
:: and the original GIM to GIS ouput
gimconv A_input.gim -o A_outputGIM.gis -digi
pause
::Now with those differences is time to make an edit to A_outputGIM.gis
:: to be equal to A_outputGIM.gis
:: I did the comparison with https://winmerge.org/downloads/
Working out png to Gim details

Lines added to GimConv.cfg
option -png2gis_digi {
    image_format = index4
palette_format = rgba4444
}
Problem solved, proof below:


there are still some things to polish, the next steps are:

The bms script needs polish to put proper string format, so the extraction can be fully automatized and work as expected. Otherwise doing the rename by hand work, but I want to avoid such slave task for more than 540 images. edit: IT'S FIXED
string pbi_file + i # adds an id to the string for the file name
string pbi_file + ".GIM" # adds extension to the string for the file name

To Do List

The GIM still needs a second round, but has a workable patch to do tests if needed.

The work with the font to print Spanish letters (for some languages this will be needed and for others it won't).

Once those are done, the next is the image editing part. And lastly, the style reviews plus beta testing.

Will update when I have more info about the remaining tasks.
Curiosity leads to knowledge,
be curious.

Bunkai

BREAKING NEWS
As I was told, we can load the table from https://www.romhacking.net/documents/765/ in armips. So I did a few changes to the letters:

And edited the code to insert the text with:
    .loadtable "Font_Esp.tbl"
    block010_str1:
    .string "¿Españit" ; はじめから
    .align 4
save both files (armips and table) with utf8 encoding
Also, don't forget to make an edit to those offsets in the actual font (go to the file ID00029 with crystal tile like before and edit it):


Then check if the new font works:


Since everything seems correct, I can now proceed to edit it properly to have the letters I want.

To-Do List

The GIM still needs a second round, but has a workable patch to do tests if needed.
Edit 5 / February / 2023: The GIM problem was fixed via running the PNG through https://tinypng.com/ and some people have said https://pnggauntlet.com/ works too.

Make proper adjustments to font, sprites and text, so it looks nice and prints the things we want, as known as the actual translation. And lastly, the style reviews plus beta testing.

Unless anything unexpected comes from this project in the next stages, this thread can go back to general tinkering again. The next digging will probably be about GBA.

Curiosity leads to knowledge,
be curious.