ASM Sonic the Fighters - Disassembly (and discoveries from it)

biggestsonicfan · Jun 1, 2020

It's about time I finally released what I have: The Sonic the Fighters Disassembly Repo!

It's in it's infancy, and there are a few things that should be taken into consideration:

This build is not close to being build-able. Once I am able to compile a valid Model2b binary, I can then begin comparing the binary to the source ROM and made changes accordingly.

To reduce the size of the disassembly, the memory segment of the IDA file has been stripped, however the labels remain. This is why you will see some labels with no references. Bare with me until I figure out a solution for this.

There are errors. Probably lots of them. Things like loc_FFF8+7 should be 0xFFFF, I just haven't fixed them all yet.

I am new to assembly, and do not fully comprehend how to use include or macros yet.

HELP WANTED! I don't know what people can do, submit issues for what you find or even pull requests would be nice though to fix things. Keep in mind I have to make the changes in IDA Pro first, then re-export to an ASM file, so any submitted issues or pull requests will take time to fix.

I've spent probably close to two years on this now, and recently trying to reassemble the ROM helped fix a lot of things I wasn't aware of. I will try to get this repo 1:1 with the original ROM source, but I can't promise any time frame.

Enjoy!

Lostgame · Jun 2, 2020

Great work. Any progress is progress, thanks for sharing; keep it up.

biggestsonicfan · Jun 3, 2020

Lostgame said:

Great work. Any progress is progress, thanks for sharing; keep it up.
Click to expand...

Thank you! I will! I also just this morning successfully assembled and linked a ROM binary from the disassembly and hope to upload instructions soon to the git!

biggestsonicfan · Jun 7, 2020

Small update, the binary the disassembly now is bit-identical to the binary for the Sonic the Fighters ROM. It's build-able, but you will still need to split the binary in two word-interleaved files to load it into the emulator. I have a tool I made to do that but it needs further polish before release. For now, we can just celebrate the first bit-perfect Model2 disassembly to exist!

TheInvisibleSun · Jun 7, 2020

Awesome to finally see a disassembly! How far are we from things like, model imports and whatnot (if this is a ridiculous question, pardon my ignorance)? It'd be kind of fun to see VF Kids models in this game or something like that.

biggestsonicfan · Jun 7, 2020

TheInvisibleSun said:

Awesome to finally see a disassembly! How far are we from things like, model imports and whatnot (if this is a ridiculous question, pardon my ignorance)? It'd be kind of fun to see VF Kids models in this game or something like that.
Click to expand...

Quite a ways away, unfortunately. I am fairly sure the models are baked into the "main data" EPROMs, and it will take quite a bit of research to first understand the model format, more research to translate it into something that can be viewable in a computer space, and then reversing that process. @RyogaMasaki and I plan on taking a close look at how models are drawn in debug mode, but that's a ways off when his schedule clears up. But based on how I see models work and how tightly everything fits together in this game, I would say importing is going to be much further off than exporting models.

biggestsonicfan · Jun 9, 2020

A minor update:

The rom_code1.asm and rom_code1(labels).asm have been merged into rom_code1.asm. The reason they were split were so labels were human readable in rom_code1(labels).asm [eg. "debug_flag], and rom_code1.asm was able to be properly assembled without these labels [eg. 0x508000 instead of "debug_flag"]. But now, by default, there is an "include.S" file that tells the assembler that these labels should have the hex values when assembled. Et, Volia, two become one!

Aesculapius Piranha · Jun 30, 2020

To me the cool thing about this is more just hey we have an actual look at the work that went into Virtua Fighter games. I mean, in a weird way STF was itself kind of a Sonic Themed fan mod by AM2 that was based on work that went into the VF series. Want to understand the games modern 3D fighters are based off of? Here you go!

Lostgame · Jul 1, 2020

biggestsonicfan said:

Lostgame said:

Great work. Any progress is progress, thanks for sharing; keep it up.
Click to expand...

Thank you! I will! I also just this morning successfully assembled and linked a ROM binary from the disassembly and hope to upload instructions soon to the git!
Click to expand...

Oh, wow; that’s *serious* progress! Awesome!

biggestsonicfan · Aug 19, 2020

I dunno if this belongs in this thread or the other thread but I think I'm just going to post this in here:

Upon closer examination of the disassembly, I've mislabeled a few things, and in the process, identified 3 unreferenced debug menu entries. All crash upon trying to hack them into the main debug menu.

Entry 1: Not entirely sure what this one would have done. Loads Player1's parts.

Entry 2: A coin menu. Looks like this may have been used for early bookkeeping manipulation without playing the game. Keeps track of credits, which shoot they entered, and service buttons.

Entry 3: A scale menu? Lists each playable (without modification) character including grey-scale characters and each one has a float value assigned to it. The float values are all defined as 1.0, but I assume this menu allowed you to alter these float values. The floats when manipulated via hacking don't seem to have any affects.

I'm bashing away trying to document as much as I can before the next git refresh, so please look forward to it.

EDIT: Pictures.

biggestsonicfan · Aug 31, 2020

A new model of Eggman has been uncovered! Completely unreferenced data. He is larger than the Eggman seen in the beginning intro of the game, but smaller than the other unused "Eggmanb" Big Eggman.

Eggman vs New Middle Sized Eggman

Big Eggman vs New Middle Sized Eggman

There is more Eggman in this game than there is Sonic...

biggestsonicfan · Sep 9, 2020

All 4475 model objects from the game have now been added to the repo!

ValleyBell · Sep 12, 2020

I guess I should contribute what I researched regarding sound stuff:

At first, we have a disassembly of the sound driver: http://vgmrips.net/misc/schamp_SoundDriver_disasm.7z

I made this in 2013 and the labels are far from complete. There is a small list of sound RAM offsets.

The general collection of pointer lists begins at 0x008000 and is 0x2C bytes long (11 different lists).
It has pointers to the following tables:
- 0x008000: Sample Table -> 0x00A3FC
- 0x008004: Instrument Table -> 0x00C9E4
- 0x00800C: Music Track Initialization Data -> 0x0080B2
- 0x008010: SFX Track Initialization Data -> 0x008080
- 0x00801C: Music/SFX group lists -> 0x00E2E2
- 0x008028: note velocity lookup table -> 0x00FB04

Following such a pointer almost always leads to a 16-bit Big Endian word that tells you either the size or the number of entries in the table.
... except that it ALWAYS denotes (n-1).

Also note that the ROM is mapped to address 0x600000..0x7FFFFF of the 68000 address space. Thus all addresses have 0x600000 added to them.
I list the actual ROM offsets here, not the CPU addresses.

Examples:
- Sample Table 0x00A3FC: The first word reads "259F", which means that the next 0x25A0 bytes are sample data.
- Instrument Table 0x00C9E4: The first word reads "0052". It is followed by 0x53 pointers to instrument definition data. Those are relative to 0x00C9E4.
- music/SFX group lists 0x00E2E2: The first word reads "0004". It is followed by 5 (relative) pointers. (1 music + 4 SFX groups)
- music pointer list 0x00E2EE. The first word read "0018". There are 0x19 songs. Pointers are relative to 0x00E2E2. (i.e. music/SFX group list)
The first pointer ("0448") points to 0x00E2E2 + 0x0448 = 0x00E72A

The music format itself consists of a list of "chunks"/"patterns" with special commands (track initialization, loops) in between.
The pattern data itself is MIDI-based, with a slightly optimized notation that allows you to omit delays.

I'll just list a small example of how it works with song 0 (offset 0x00E72A):

Code (Text):

00E72E 00: type identifier (00 = music, 80..FF = SFX, 01..7F = special)

00E72F 00 00 00: ignored

00E732 80 A0 00 02: enqueue MIDI command A0 00 02 (reset all channels)

00E736 80 A0 07 00: enqueue MIDI command A0 07 00 (load instrument initialization number 0x00)

00E73A 0060EB16: play segment at 0x00EB16

loop:

00E73E 00610000: play segment at 0x010000

00E742 00611300: play segment at 0x011300

00E746 00611E00: play segment at 0x011E00

00E74A 00612800: play segment at 0x012800

00E74E 00613B00: play segment at 0x013B00

00E752 FFFFFFF1 0060E73E: jump to position 0x00E73E (loop)

A value of FFFFFFFF in the pattern list denotes the end of the song.

A pattern segment consists of MIDI commands, which are written to a global queue when they are to be played. (same queue as "enqueue MIDI command" in the pattern list)

Code (Text):

MIDI commands supported by MIDI segment parser + global MIDI command parser:

8c nn - Note Off (channel c), note nn (internally converted to 8c nn 7F, but the Off-Velocity is ignored anyway)

9c nn vv - Note On (channel c), note nn, velocity vv (vv == 0 -> Note Off)

Ac xx dd - execute special command xx with parameter dd (I think the channel is ignored? not sure)

Bc ii dd - Control Change (channel c), controller ID ii, data dd

The sound driver supports:

01 - Modulation

02

07 - Channel Volume

0A - Panorama

11..19

29..2B

30..35

40..4C

50

Cc ii - Instrument Change (channel c), set instrument to ii

Ec ll mm - Pitch Bend (channel c), value mmll (mm and ll is 7 bits each, just like normal MIDI)

Commands 00..7F/D0..DF/F0..FF are ignored.

The MIDI segment parser also supports these additional commands:

Dc nn - Channel Aftertouch (channel c) (copied into global MIDI command queue, but has no effect there)

F0 [dd dd ...] F7 - SysEx (the driver skips everything until/including the next F7 it finds)

F7 ll [dd dd ...] - SysEx Continuation (the driver skips ll bytes from the first dd on)

FF 2F xx - Segment End

FF ii ll [dd dd ...] - Meta Event (the driver skips ll bytes from the first dd on)

The "running status" trick is supported by the MIDI segment parser.

In the MIDI segments, they use a neat trick to save some bytes:
When the last parameter byte has bit 7 set (results in value 80..FF), then the delay byte is omitted and the next event follows immediately.

Example:

Code (Text):

0100D0 99 56 46 Note On, ch 9, note 0x56, velocity 0x46

0100D3 2E delay: 0x2E ticks

0100D4 86 45 Note Off, ch 6, note 0x45

0100D6 22 delay: 0x22 ticks

0100D7 B6 0A 7F Control Change, ch 6, Pan, value 0x7F

0100DA 0A delay: 0x0A ticks

0100DB 0A 76 (Control Change, ch 6), Pan, value 0x76

0100DD 03 delay: 0x03 ticks

0100DE 89 D6 Note Off, ch 9, note 0x56, no delay

0100E0 99 51 C6 Note On, ch 9, note 0x51, velocity 0x46, no delay

0100E3 58 46 (Note On, ch 9), note 0x58, velocity 0x46

0100E5 00 delay: 0 ticks

0100E6 96 39 41 Note On, ch 6, note 0x39, velocity 0x41

0100E9 2E delay: 0x2E ticks

0100EA 88 CC Note Off, ch 8, note 0x4C, no delay

0100EC 88 45 Note Off, ch 8, note 0x45

0100EE 00 delay: 0 ticks

I wrote a converter to convert songs from Sonic The Fighters to usual MIDI + SF2 soundfonts.
You can find the source code here: M2MidiDec.c

And now something I researched today, due to a feature request for M2MidiDec:

The sound test has all names and commands listed.
The offset list that references all items from the sound test is located at 0x0DC400 in the program ROM.
The items themselves begin at offset 0x09A270. They consist of a 4-byte MIDI command (stored in Little Endian, the highest byte is ignored), followed by a null-terminated string.

Here is the full list:

Code (Text):

No. command name

0 A00001 sd_ALL_CLEAR

1 AE1100 sd_jump_1

2 AE1101 sd_jump_2

3 AE1102 sd_ring_2

4 AE1103 sd_spin_1

5 AE1104 sd_spin_2

6 AE1105 sd_plane_1

7 AE1106 sd_plane_3

8 AE1107 sd_plane_4

9 AE1400 sd_plane_4_off

10 AE1108 sd_fall_2

11 AE1109 sd_fall_6

12 AE110A sd_fall_9

13 AE110B sd_kick_kara_1

14 AE110C sd_kick_kara_2

15 AE110D sd_punch_kara_1

16 AE110E sd_punch_kara_2

17 AE110F sd_punch_a

18 AE1110 sd_punch_b

19 AE1111 sd_punch_c

20 AE1112 sd_punch_d

21 AE1113 sd_punch_e

22 AE1114 sd_punch_f

23 AE1115 sd_punch_g

24 AE1116 sd_punch_h

25 AE1117 sd_punch_j

26 AE1118 sd_punch_k

27 AE1119 sd_punch_m

28 AE111A sd_punch_n

29 AE111B sd_punch_o

30 AE111C sd_punch_p

31 AE111D sd_punch_q

32 AE111E sd_punch_r

33 AE111F sd_punch_s

34 AE1120 sd_rope_1

35 AE1121 sd_rope_2

36 AE1122 sd_rope_2a

37 AE1123 sd_rope_2b

38 AE1124 sd_plane_2a

39 AE1401 sd_plane_2a_off

40 AE1125 sd_plane_2b

41 AE1402 sd_plane_2b_off

42 AE1126 sd_rope_3

43 AE1127 sd_rope_4

44 AE1128 sd_up_2

45 AE1129 sd_up_3

46 AE112A sd_cane_2c

47 AE112B sd_cane_2cc

48 AE112C sd_cane_2d

49 AE112D sd_cane_2dd

50 AE112E sd_cork_1a

51 AE112F sd_cork_1b

52 AE1130 sd_cork_6a

53 AE1131 sd_cork_6b

54 AE1132 sd_cork_6c

55 AE1133 sd_fence_1

56 AE1134 sd_fence_2

57 AE1135 sd_fence_3

58 AE1136 sd_g_punch_1

59 AE1137 sd_g_punch_2

60 AE1138 sd_land_1

61 AE1139 sd_wall_1

62 AE113A sd_ufo_6a

63 AE1403 sd_ufo_6a_off

64 AE113B sd_ufo_6b

65 AE1404 sd_ufo_6b_off

66 AE113C sd_ufo_esc_1

67 AE113D sd_computer_1

68 AE1405 sd_computer_1_off

69 AE113E sd_water_4c

70 AE1406 sd_water_4c_off

71 AE113F sd_plane_2

72 AE133D sd_bomb_1

73 AE133E sd_bomb_2

74 AE1142 sd_gong_1

75 AE1143 sd_gong_2

76 AE1144 sd_guard_1

77 AE1145 sd_gum_2

78 AE1146 sd_gum_2a

79 AE1147 sd_gum_2c

80 AE1148 sd_gum_2d

81 AE1149 sd_gum_2e

82 AE114A sd_pico_2a

83 AE114B sd_pico_2b

84 AE114C sd_pico_2c

85 AE114D sd_pico_2d

86 AE114E sd_pico_2e

87 AE114F sd_pico_2f

88 AE1150 sd_computer_2

89 AE1407 sd_computer_2_off

90 AE1151 sd_pinball_2

91 AE1152 sd_pinball_6

92 AE1153 sd_pinball_a

93 AE1154 sd_pinball_b

94 AE1155 sd_pinball_c

95 AE1156 sd_pinball_d

96 AE1157 sd_pinball_e

97 AE1158 sd_pinball_f

98 AE1159 sd_pinball_g

99 AE115A sd_pinball_h

100 AE115B sd_pinball_j

101 AE115C sd_pinball_k

102 AE115D sd_pinball_m

103 AE115E sd_prop_1

104 AE1408 sd_prop_1_off

105 AE115F sd_prop_11

106 AE1409 sd_prop_11_off

107 AE1160 sd_prop_2

108 AE140A sd_prop_2_off

109 AE1161 sd_prop_22

110 AE140B sd_prop_22_off

111 AE1162 sd_prop_3

112 AE140C sd_prop_3_off

113 AE1163 sd_prop_33

114 AE140D sd_prop_33_off

115 AE1164 sd_takeko_1

116 AE140E sd_takeko_1_off

117 AE1165 sd_takeko_2

118 AE140F sd_takeko_2_off

119 AE1166 sd_takeko_3

120 AE1410 sd_takeko_3_off

121 AE1167 sd_takeko_5

122 AE1411 sd_takeko_5_off

123 AE1168 sd_wall_hit_1

124 AE1169 sd_wall_hit_2

125 AE116A sd_wall_hit_3

126 AE116B sd_wall_hit_4

127 AE116C sd_wall_hit_5

128 AE1309 sd_waterfall_1

129 AE1412 sd_waterfall_1_off

130 AE116E sd_computer_3

131 AE1413 sd_computer_3_off

132 AE116F sd_xylo_1

133 AE1170 sd_xylo_2

134 AE1171 sd_xylo_mix1_22

135 AE1172 sd_swing_c

136 AE1173 sd_swing_d

137 AE1174 sd_swing_e

138 AE1175 sd_swing_f

139 AE1176 sd_swing_g

140 AE1177 sd_swing_h

141 AE1178 sd_clash_1

142 AE1179 sd_knock_2

143 AE117A sd_knock_3

144 AE117B sd_knock_9

145 AE117C sd_pecha_2

146 AE117D sd_pecha_2a

147 AE1200 sd_aou01

148 AE1201 sd_aou02

149 AE1202 sd_auch01

150 AE1203 sd_auch02

151 AE1208 sd_kyuu01

152 AE1216 sd_scream01

153 AE1217 sd_scream02

154 AE121C sd_WB01_13_03

155 AE121D sd_WB01_18_01

156 AE121E sd_WB01_18_02

157 AE121F sd_WB01_25_01

158 AE1220 sd_WB01_26_01

159 AE1221 sd_WB01_26_02

160 AE1222 sd_WB01_27_01

161 AE1223 sd_WB01_27_02

162 AE1224 sd_WB01_28_01

163 AE1225 sd_WB01_28_02

164 AE1226 sd_WB01_77_01

165 AE1227 sd_WB01_77_02

166 AE1228 sd_WB02_01_00

167 AE1229 sd_WB02_02_02

168 AE122A sd_WB02_15_01

169 AE122B sd_WB02_19_02

170 AE122C sd_WB02_24_01

171 AE122D sd_WB02_24_03

172 AE122E sd_WB02_25_02

173 AE122F sd_WB02_29_05

174 AE1230 sd_WB02_33_01

175 AE1231 sd_WB02_67_01

176 AE1232 sd_WB02_70_03

177 AE1233 sd_WB02_71_01

178 AE1234 sd_WB03_72_01

179 AE1235 sd_WB03_72_02

180 AE1236 sd_WB04_62_01

181 AE1237 sd_WB04_62_02

182 AE1238 sd_WB04_62_05

183 AE1239 sd_WB04_63_01

184 AE123A sd_WB04_64_01

185 AE123B sd_WB04_81_01

186 AE123C sd_WB04_82_04

187 AE123D sd_WB04_83_04

188 AE123E sd_WB04_90_03

189 AE123F sd_WB04_91_01

190 AE1240 sd_WB04_91_02

191 AE1241 sd_WB04_92_01

192 AE1242 sd_WB04_92_02

193 AE1243 sd_WB04_92_03

194 AE1244 sd_WB05_32_01

195 AE1414 sd_WB05_32_01_off

196 AE1245 sd_WB05_51_03

197 AE1246 sd_WB99_01

198 AE1247 sd_WB99_02

199 AE1248 sd_WB99_03

200 AE1249 sd_US02_75_02

201 AE124A sd_US02_79_01

202 AE124B sd_US02_79_02

203 AE124C sd_US02_79_05

204 AE124D sd_US02_79_3

205 AE124E sd_US03_06_01

206 AE1415 sd_US03_06_01_off

207 AE124F sd_US03_59_04

208 AE1250 sd_US04_11_01

209 AE1251 sd_US04_11_02

210 AE1252 sd_US04_12_01

211 AE1253 sd_US04_12_02

212 AE1254 sd_US04_14_01

213 AE1416 sd_US04_14_01_off

214 AE1255 sd_US04_15_01

215 AE1417 sd_US04_15_01_off

216 AE1256 sd_US04_49_05

217 AE1300 sd_bird_2

218 AE1302 sd_gong_4

219 AE1309 sd_waterfall_1

220 AE130A sd_waterfall_2

221 AE130B sd_ring_5a

222 AE130C sd_ring_5b

223 AE130D sd_ring_5c

224 AE130E sd_ring_5d

225 AE130F sd_ring_5e

226 AE1310 sd_ring_5f

227 AE1311 sd_ring_5g

228 AE1312 sd_ring_5h

229 AE1313 sd_ring_5i

230 AE1314 sd_ring_5j

231 AE1315 sd_ring_5k

232 AE1316 sd_ring_5m

233 AE1317 sd_ring_5n

234 AE1318 sd_bound_1a

235 AE1319 sd_hit_1a

236 AE131A sd_hit_1b

237 AE131B sd_hit_1c

238 AE131C sd_hit_1d

239 AE131D sd_hit_1e

240 AE131E sd_splash_2

241 AE131F sd_splash_3

242 AE1320 sd_splash_4

243 AE1321 sd_beam_10b

244 AE1418 sd_beam_10b_off

245 AE1322 sd_beam_10c

246 AE1419 sd_beam_10c_off

247 AE1323 sd_beam_15a

248 AE141A sd_beam_15a_off

249 AE1324 sd_beam_6a

250 AE141B sd_beam_6a_off

251 AE1325 sd_beam_6b

252 AE141C sd_beam_6b_off

253 AE1326 sd_beam_6c

254 AE141D sd_beam_6c_off

255 AE1327 sd_beam_7a

256 AE1328 sd_foot_1

257 AE1329 sd_foot_2

258 AE132A sd_foot_3

259 AE132B sd_foot_4

260 AE132C sd_foot_5

261 AE132D sd_foot_6

262 AE132E sd_robo_1a

263 AE132F sd_robo_1b

264 AE1330 sd_robo_1c

265 AE1331 sd_robo_2a

266 AE1332 sd_robo_2c

267 AE1333 sd_robo_3a

268 AE1334 sd_robo_3b

269 AE1335 sd_robo_5a

270 AE1336 sd_robo_5b

271 AE1337 sd_robo_5c

272 AE1338 sd_bean_damage_01

273 AE1339 sd_bean_damage_02

274 AE133A sd_bean_kwa_01

275 AE133B sd_bean_kwe_01

276 AE133C sd_bean_longescream_01

277 AE133D sd_bomb_1

278 AE133E sd_bomb_2

279 AE133F sd_b_fence_2

280 AE141E sd_b_fence_2_off

281 AE1340 sd_b_fence_3

282 AE1341 sd_ele_1

283 AE1342 sd_ele_2

284 AE1343 sd_ele_3

285 AE141F sd_ele_3_off

286 AE1344 sd_ele_4

287 AE1345 sd_engine_1

288 AE1420 sd_engine_1_off

289 AE1346 sd_shatter_1

290 AE1347 sd_shatter_3

291 AE1348 sd_torocco_2

292 AE1421 sd_torocco_2_off

293 AE1349 sd_zaza

294 AE134A sd_tyu_13a

295 AE134B sd_tyu_13b

296 AE134C sd_tyu_13d

297 AE134D sd_tyu_13e

298 AE134E sd_tyu_13ff

299 AE134F sd_tyu_13fff

300 AE1350 sd_tyu_13gg

301 AE1351 sd_tyu_13ggg

302 AE1352 sd_tyu_2

303 AE1353 sd_tyu_2a

304 AE1354 sd_tyu_3

305 AE1355 sd_tyu_3a

306 AE1356 sd_tyu_4

307 AE1357 sd_tyu_4a

308 AE1358 sd_laugh0b

309 AE1359 sd_bowling

310 AE1000 sd_game_bgm_00

311 AE1001 sd_game_bgm_01

312 AE1002 sd_game_bgm_02

313 AE1003 sd_game_bgm_03

314 AE1004 sd_game_bgm_04

315 AE1005 sd_game_bgm_05

316 AE1006 sd_game_bgm_06

317 AE1007 sd_game_bgm_07

318 AE1008 sd_game_bgm_08

319 AE1009 sd_game_bgm_09

320 AE100A sd_game_bgm_0a

321 AE100B sd_game_bgm_0b

322 AE100C sd_game_bgm_0c

323 AE100D sd_game_bgm_0d

324 AE100E sd_game_bgm_0e

325 AE100F sd_game_bgm_0f

326 AE1010 sd_game_bgm_10

327 AE1011 sd_game_bgm_11

328 AE1012 sd_game_bgm_12

329 AE1013 sd_game_bgm_13

330 AE1014 sd_game_bgm_14

331 AE1015 sd_game_bgm_15

332 AE1016 sd_game_bgm_16

333 AE1017 sd_game_bgm_17

The format is: AE 1b nn with "b" being the sound bank and nn being the ID within the bank.

biggestsonicfan · Sep 12, 2020

Thanks much for this! Is it alright if I include this in the disassembly repo?

ValleyBell · Sep 13, 2020

Feel free to do so.

biggestsonicfan · Sep 13, 2020

ValleyBell said:

Feel free to do so.
Click to expand...

Yay! Now to figure out a way to take the extracted samples and midis and put them back into the game

Tiberious · Oct 2, 2020

I'm watching this with interest. Personally, I've always wanted to see either a fan or official sequel to this game, now that there's more characters to work with, and hopefully fix up some system/balance issues in the process (some characters are outright broken within the system as it is now). I've brainstormed a few, vague ideas on what could be done, but nothing I can really turn a critical eye on.

But good thing with this is I bet you could at least make some good balance changes. Sonic shouldn't be able to completely remove the opponent's ability to block for the rest of the match in the first seconds of the first round, for instance.

What are your plans with this?

biggestsonicfan · Oct 3, 2020

Tiberious said:

What are your plans with this?
Click to expand...

Well, the main goal is to document and create a point of reference for which someone much smarter than me can use Ghidra and take that I have and compare it and eventually turn it into C-like code for mucking about, much like the Super Mario 64 disassembly. That's never going to become a reality though, so realistically this is just going to become an open-ended project where we learn a bit and get some new takeaways from secrets the game holds.

There's a lot going on in this game's engine where we can't fully understand it without also disassembling both Fighting Vipers and Virtua Fighter 2, as a lot of variables listed in the debug menu simply go unused or unrefrenced in Sonic the Fighters, where they could be implemented in the other games. So to get the full picture of the game's engine and what it is capable of may never manifest itself.

Scorched Dreamer · Oct 18, 2020

Rooting for this! I've always found it to be such a fascinating game, being developed by AM2.. The sound in particular. I'd be really interested in looking at the MIDI and SF2 files, but I'm not particularly good at compiling and using C code

Keep up the good work!!

biggestsonicfan · Oct 20, 2020

Scorched Dreamer said:

Keep up the good work!!
Click to expand...

Thank you very much!

Today, I would like to do something a little different. Cheats have traditionally been made in the scripts of the emulator's engine, like displaying numbers and values, but I wondered if I could make a "cheat" within the game's engine itself. Something that could run on hardware. Well, yes, yes I can.

There is an odd routine I've labeled as "CPU_USE_MOVE".

Code (Text):

CPU_USE_MOVE:

ldob 0xC9(g4), r3

ld debug_cpu_movesets[r3*4], r4 # Sets proper character moveset

ldob 0xBA(g4), r3

addo 0x1F, 0xD, r5

mulo r5, r3, r3

lda (r4)[r3], r5

mov r5, g0 # sets move ascii location to g0, then returns

call CPU_USE_MOVE_return

lda 0xC(r5), r6

lda 0x1C(r5), r7

ldob 0xC5(g4), r8

cmpibl 0x10, r8, loc_3E5D0

ldob (r6)[r8], g5

lda 0x7F, r5

cmpobe r5, g5, loc_3E5D0

call sub_3E6A4

stob g5, 0x1200(g7)

stob g5, 0xC7(g4)

ldob (r7)[r8], r3

stob r3, 0xC6(g4)

cmpobne 0, r3, loc_3E5CC

ldob 0xC5(g4), r14

addi 1, r14, r15

stob r15, 0xC5(g4)

loc_3E5CC:

ret

This routine loads up the current computer player's moveset and loads the currently executing move's ascii location to register g0. It then calls a subroutine which just returns, so it goes back to executing code. I bet this subroutine once provided debug information showing what move a CPU was using. So I decided to restore something like that.

To start with, I decided to use a 100% unreferenced area of ROM to start writing my own routine in, and "DEBUG_UNUSED_MENU" fits that bill perfectly. So long as I keep the same amount of bytes used in my custom code, I can do whatever I want.

First, I need to alter "CPU_USE_MOVE" to call "DEBUG_UNUSED_MENU" instead of "CPU_USE_MOVE_return". That's just a simple like so:

Code (Text):

call DEBUG_UNUSED_MENU

Next, we need to write the code that will run in DEBUG_UNUSED_MENU. Text displays using register "g0" as the ascii text and register "g9" as the coordinate. So if we look at the code above for "CPU_USE_MOVE", we can see that the location of the ascii of a move is loaded to g0, but not the ascii itself, so the first line of code we need is as follows:

Code (Text):

ld (g0), g0

Great, now g0 is loaded with the ascii value that was located at g0 previously!

Now I don't understand the coordinate system enough yet to place text wherever I want, but I DO know that when the game boots up, it lists some text in the top left corner of the screen, so I'm going to copy the disassembled code from there to use as our coordinates to place text:

Code (Text):

lda 0x1000014, g9

Alright, almost done. Now we need to call the routine that places text on the screen, like so:

Code (Text):

call uk__dispText

And finally, we need to jump back to the "CPU_USE_MOVE" routine with a return:

Code (Text):

ret

Giving us the resulting code:

Code (Text):

DEBUG_UNUSED_MENU:

ld (g0), g0

lda 0x1000014, g9

call uk__dispText

ret

Assembling this code into the ROM allows us to view the CPU player move names as they execute, like so:

But you don't have to do all this because I wrote an emulator cheat so you can play with this cheat too!

Simply add

Code (Text):

function show_cpu_move()

Romset_PatchDWord(0,0x3E584, 0x0900963C)

Romset_PatchDWord(0,0x47BC0, 0x90841000)

Romset_PatchDWord(0,0x47BC4, 0x8CC83000)

Romset_PatchDWord(0,0x47BC8, 0x01000014)

Romset_PatchDWord(0,0x47BCC, 0x09FBDAA8)

Romset_PatchDWord(0,0x47BD0, 0x0A000000)

end

To "sfight.lua" and call "show_cpu_move()" under "Init()" like so:

Code (Text):

function Init()

show_cpu_move()

end

Have fun!

ASM Sonic the Fighters - Disassembly (and discoveries from it)

Useful Searches