Welcome to the Shining Force Central Forums!
SFC Forums Index Shining Forums Shining Force II
Register for your free forum account now or Login to remove this advert.

[GitHub] ShiningForceCentral/SF2DISASM

For documentation and new fan-projects.

Discussion about this classic Genesis/Mega Drive game.

[GitHub] ShiningForceCentral/SF2DISASM

Postby Wiz » Thu May 01 2014 9:20pm

Here is project SF2DISASM : a split disassembly of Shining Force II, resulting from project SF2RE.

The project is hosted on a git repository on GitHub, under the ShiningForceCentral account :


The main purposes of SF2DISASM are :
- to produce tools and sourcecode capable of building a bit-perfect replica of the game,
- to identify, split, label, comment and document the game's content,
- and ultimately, to provide a flexible way of creating new games, hacks and mods based on Shining Force II.


Original post :
WARNING: SPOILER!
Last edited by Wiz on Sat Aug 22 2015 12:12am, edited 6 times in total.
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: Project SF2DISASM on GitHub

Postby Stordarth » Thu May 01 2014 11:58pm

Good to have you back, Wiz.

I'm not sure how much I'll be able to contibute to this myself; the CP is taking up a fair bit of my time these days, so my focus is there. I'll pop into the irc on occasion still, in case I can assist in some manner.


Not to hijack the thread, but you're a bit of a whiz with the genesis music if i recall, right? I was wondering if I could point Chef Boyardee in your direction. He's looking into composing some music using the genesis sound chips and I wondered if you could give him some guidance. Lord Oddeye sama has already mentioned CubeTools, but if there's anything you could help with, your insight would prove invaluable.
---

Carry on.
Stordarth

User avatar
The L-Block Anomaly
Administrator
 
Posts: 15517
Joined: Thu Sep 16 2004 3:30pm
Location: The Midlands, Staffordshire, England

Re: Project SF2DISASM on GitHub

Postby Wiz » Fri May 02 2014 12:08am

Hey, thank you Stordarth ! It would be nice to se you again on irc indeed !

It will be a pleasure to help Chef Boyardee or anybody else about SF2's sound driver and/or genesis sound in general. After some years with no practice my knowledge is a bit rusted but it will be the occasion to get back into the subject. :)

I myself had some technical questions about the CP actually, so I'm really looking forward to seeing you on IRC soon !
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: Project SF2DISASM on GitHub

Postby Earl » Fri May 02 2014 5:27am

Is this based on the disassembly that's up at sf2hack?

Because combing through that over the past few years, I've noticed that some instances...
TRAP 5 is used for dialogue lines, so where it's used the next two bytes indicate dialogue line #.
There are some places where those next two bytes are interpreted as instructions instead.

I can't tell you off the top of my head where they are, though.


I'm kind of in the same boat now... Saturday is pretty much my only free day.
But I added some stuff to the RAM map on the wiki.
Also, my flag map is bigger than your flag map :รพ
Although I never did figure out the region trigger stuff you did.

I should actually update that at some point... After the battle unlocks, mid-battle scenes, and battle completes, there's another chunk of ~50 unused flags (presumably also originally intended for some battle-related usage).
Earl

User avatar
Shining Legend
Shining Legend
 
Posts: 2905
Joined: Sat Apr 24 2004 6:39am

Re: Project SF2DISASM on GitHub

Postby Wiz » Fri May 02 2014 2:06pm

Wow Earl, awesome flag map :excited: !
And thank you so much for already contributing to the wiki ! That's the spirit :)

About trap #5 I totally agree, every call to this trap should be followed by a properly formatted word (two bytes).
If that's not the case everywhere in the disassembly, it's because IDA automatically tries to parse this word as ASM code and neither me nor BNC did take the time to re-format all these calls properly.

It still builds properly, of course, but I agree we have to tidy up all these calls at some point in the future.

By the way, thanks a lot for all your discoveries these last years, I saw some of them here and there in the forum (especially map events I think) and that's definitely the kind of new stuff we'll have to add in the disassembly too !

EDIT : by the way, all these notes I put on the wiki are not "my" work especially, I should have made it clear from the beginning that I'm actually putting online BNC's notes, which we've written and formatted together mainly between 2007-2010, but really this is mostly the result of BNC's work here, not mine. ;)
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: Project SF2DISASM on GitHub

Postby Earl » Sat May 03 2014 4:58am

Strike while the iron's hot, right? Or at least before you forget to strike at all.

Finished up adding the RAM map stuff I was able to piece together, and added a few more references to the SFX indexes. While you were away, I actually made a patch that restores the sound test to the US version (along with a few other things).
Earl

User avatar
Shining Legend
Shining Legend
 
Posts: 2905
Joined: Sat Apr 24 2004 6:39am

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby Wiz » Tue May 06 2014 6:55pm

Thank you Earl, and here is some news :
BNC and I have agreed on the creation of a new repository which will be complementary to SF2DISASM.
It is named SF2RE, for Reverse-Engineering : https://github.com/ShiningForceCentral/SF2RE

More info in a new topic soon, but here's what I think about the wikis :
- SF2DISASM's wiki should contain documentation-oriented information : stuff discovered once and for all, published so that people can understand how the game works and how they can modify it.
- SF2RE's wiki should contain research-oriented information. It's a tools for reverse-engineers as well as a space for drafts before publishing new information in SF2DISASM's wiki.

SF2RE is the place to make progress in understanding SF2, and SF2DISASM benefits from SF2RE's progress with new wiki pages and new versions of the ASM disassembly, with more labels, more comments, and more versatility for new hacks.

In any case, this is how I see it :)


EDIT :
Thanks to project SF2RE's new work methodology, SF2DISASM has been updated with a newer disassembly.

Nothing major here, but there are a few new "align" directives that should allow some more ASM romhacking with no undesirable data shifting.

Enjoy :)
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby ronnen » Mon Sep 26 2016 6:45pm

Wiz,

https://github.com/ShiningForceCentral/ ... 3bbae15f25

Thanks for this, having to port my (less robust) fix around in my fork for all my branches was the suck.
ronnen

Shining Member
Shining Member
 
Posts: 162
Joined: Fri Jan 20 2012 9:01pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby Wiz » Mon Sep 26 2016 8:12pm

Ahah yes, sorry for commiting a broken build, actually I realized my mistake by giving a look at your work, so thank you for this ! :)

I also screwed this commit you linked by including everything but what I actually wanted to include, hence two commits in a row with the same description and no real description for the first one. :damnit: Silly me but oh well, looks like you know well what you're doing despite my little mess. :shifty:
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby ronnen » Sun Oct 16 2016 3:08pm

That feeling when you blindly rebase your fork from the upstream... and discover that Wiz totally reorganized the asm files :D

Note, when I try to build current master, I get:

Code: Select all
...\EMULATORS\FUSION364\SF2DISASM\DISASM\ROMLAYOUT\SF2-01-0X0-0X8000.ASM(38) : Error : Could not open file x
'...\Emulators\Fusion364\SF2DISASM\disasm\SYSTEM\DEBUG\BATTLETEST.ASM'
 include 'system\debug\battletest.asm'
...\EMULATORS\FUSION364\SF2DISASM\DISASM\ROMLAYOUT\SF2-01-0X0-0X8000.ASM(41) : Error : Could not open file '...\Emulators\Fusion364\SF2DISASM\disasm\SYSTEM\DEBUG\CONFIGURATIONMODE.ASM'
 include 'system\debug\configurationmode.asm'
...\EMULATORS\FUSION364\SF2DISASM\DISASM\ROMLAYOUT\SF2-02-0X8000-0X10000.ASM(9) : Error : Could not open file '...\Emulators\Fusion364\SF2DISASM\disasm\SYSTEM\DEBUG\DEBUGMODEBATTLEACTIONS.ASM'
 include 'system\debug\debugmodebattleactions.asm'
Errors during pass 1 - pass 2 aborted
Assembly completed.
3 error(s) from 165348 lines in 0.17 seconds


Looks like the 'disasm/system/debug' folder doesn't even exist. See:
https://github.com/ShiningForceCentral/ ... asm/system

I see produce script for the missing bits in SF2RE, for example:

Code: Select all
produceAsmScript(file,"system\\debug\\battletest",0x769C,0x7956,"Battle test functions");


Just don't see the output saved in SF2DISASM.

Looks like the cause is the .gitignore file in SF2DISASM:
https://github.com/ShiningForceCentral/ ... .gitignore
Code: Select all
# Build results

[Dd]ebug/


So, either need exemptions for the specific file paths in question in .gitignore.
Or (probably better) change the generation code in SF2RE to generate better paths.

Created a PR to resolve gitignore and add missing files:
https://github.com/ShiningForceCentral/SF2DISASM/pull/1
ronnen

Shining Member
Shining Member
 
Posts: 162
Joined: Fri Jan 20 2012 9:01pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby Wiz » Mon Oct 17 2016 6:40pm

That feel when you realize you gotta stop pushing shitty builds because you're not alone on that thing. :D
Awesome, my first pull request ever ! Never had to manage that kind of thing before. So simple actually !

Your analysis is correct indeed, I hadn't seen this ignored directory ... but a debug-related directory still makes sense in our context, so I believe your pull request is a good solution. Merged ! ;)

I'm afraid you've found yourself in the middle of quite a big re-organization and I'm sorry if this has a big impact on your previous work.
But I think splitting the code will help everybody figure out and play with distinct parts of the game engine more easily, once it's structured properly.
Now that I've made this big and rough first split, I'll do a second pass and think about how to make it more coherent for a first approach of how the game globally works.

Once again, please do not hesitate to suggest anything about this, if you still think debug shouldn't be a directory name or things like that.
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby ronnen » Mon Oct 17 2016 6:58pm

I'd have renamed it to something more like "test" functions rather than "debug." But meh.

Some other concerns I have can be seen on this file:
https://github.com/ShiningForceCentral/ ... sstart.asm

1. There is not an "easy" way to determine where this function "normally" appears in a vanilla ROM (useful for debugging bad IPS patches such as what I had to do this weekend with SF1 level up patch).

Not to mention that kind of information is useful in determining what kind of jump / branch addressing is needed when making changes.

Even just a comment on the file "header" would be useful indicating start location (and a bonus would be expected end location).

2. Unnamed external references are hard to figure out.
bne.w loc_47D54
"What does that mean?" I happen to know that this refers to "ExecuteAfterBattleCutscene", and even if I didn't, grep is a good friend... but still annoying.
ronnen

Shining Member
Shining Member
 
Posts: 162
Joined: Fri Jan 20 2012 9:01pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby Wiz » Mon Oct 17 2016 10:09pm

Ok,

About the debug dir, I think I'll put debug mode and conf mode together into some kind of "specialmodes" directory.

About vanilla locations, I'm currently applying start/end offsets in asm file headers AND in rom layout files, at the beginning of comments. That should help !
EDIT : Actually no, only in ASM file headers ; adding offsets in comments made layout files potentially a bit silly to keep properly up to date as soon as you'd want to change them.

In a linux environment I must admit it might be tedious to grep with subdirs ... windows text editors generally allow to search in subdirs so it's quite convenient in this case.
But that kind of situation should not exist in the target situation : all subroutines will have to be named properly, especially when referenced from other files. A few hundreds of subroutines still remain unnamed, so this will take time before we really figure out every tiny piece of code in the game, but in the end you shouldn't have to worry about that kind of situation.
In your specific case, I think we should split "ExecuteAfterBattleCutscene" into two subroutines even though they're technically only one : ExecuteAfterBattleCutscene_Start and ExecuteAfterBattleCutscene_End should do it, in my opinion.
EDIT : actually no, I'll take the time to make those subroutines one file again, with a proper include directive for the table in the middle.

EDIT :
Current major rehaul is going to make 3 main directories :
- code : SF2 engine. Contains every piece of code which won't need to be edited to make new SF2 adventures. Can be edited with ASM skills, but be aware that this directory structure can still be subject to a bit of re-organization here and there when new reverse-engineering discoveries will suggest it.
- data : SF2 content. Contains everything which is not code, but also some pieces of code when they're part of bigger data structures (cutscenes, map events, etc.)
- layout : ROM layout. This can be edited to make a bigger ROM with any layout, depending on which data/code parts need more space, and how much. Beware though, any ROM bigger than original 2MB size will need to manage SRAM bankswitching (easy ASM patching solution still to determine. Git patches ?)
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby rubixcuber » Thu Nov 17 2016 5:09pm

Well, I don't step out of SF1 too often but I happened to see your post here and the talk of expanding ROMs and thought I'd share some of my findings when I was doing the same thing in the original game. Forgive me if this is all stuff you already know, but I'll just cover my whole process here.

A while back I expanded SF1 to 4MB. I discovered that using the A130F1 register for enabling and disabling SRAM seemed to be universally supported across emulators and all you really had to do was write 0 to it on game init, and then take the SRAM routines for the game and add a wrapper function to them that turns SRAM on and back off again.

But you can't go past 4MB without memory mapping and recently I have been playing with a very large copy of SF1 and made some interesting discoveries.

Using registers A130F3-A130FF to control the ROM pages mostly works as you'd hope, and in fact in Kega Fusion it seems to work flawlessly. But it looks like in a number of emulators (Gens,Gens+,Regen at the very least) there is a bug in their bank switching implementation. In using the tracer build of Gens I found that if you try to jump into a location on a re-mapped bank it will trace the correct instruction but execute the code at the original unmapped offset leading to a confusing log and usually a crash. Reads seem to work properly though, so I think I've decided just to relegate code to the first 4MB and the rest be reserved for data only.

So, I dunno. Hopefully maybe that saves somebody somewhere a little bit of head-scratching. There was a moment where I saw it trace the right code and was like "Oh hey, it's working!" only to be very confused by the next line!

On top of that, most (all?) emulators didn't bother allocating space/resources to load a ROM larger than 6MB, even though the bank switching would technically allow a 32MB ROM to be usable, and they will refuse to load a ROM expanded past 6MB.
rubixcuber

User avatar
Shining Hero
Shining Hero
 
Posts: 1092
Joined: Tue Nov 18 2008 4:36am

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby Wiz » Wed Nov 23 2016 12:14am

Hey rubixcuber, it's great to see you on the SF2 side, you should come more often with such interesting knowledge to share ! ;)

Indeed we already knew about the SRAM management process, as BNC needed that to expand ROMs to 4MB in The Caravan.

But the ambitous thought of going past 4MB had not crossed my mind yet, so this is really interesting to get your feedback on such experiments !
This might not be of a real short-term interest for current projects, but I do hope this will be put to good use at some point, so thank you very much ! :)
Wiz

User avatar
Member
Member
 
Posts: 87
Joined: Sun Mar 18 2007 2:43pm

Re: [GitHub] ShiningForceCentral/SF2DISASM

Postby rubixcuber » Wed Nov 23 2016 2:56am

Sure, no problem. I'm running a 6MB copy of SF1 at this point which seems stable and well supported and I think that's enough to suit most purposes so I'm just going to stop there. The bank switching is really not that hard once you get past the weird compatibility / implementation issues... It's a shame code on those banks isn't supported on most emulators, but only a minor setback.
rubixcuber

User avatar
Shining Hero
Shining Hero
 
Posts: 1092
Joined: Tue Nov 18 2008 4:36am


Return to Shining Force II

Who is online

Users viewing this topic: No registered users and 1 guest