Topic: Avalanche's Project: FF2

[avalanche]

I thought I'd take a moment to post something about the project that I've been working on.  My goal when deciphering disassembly and cracking how spell visuals work, etc, has been from a slightly different point of view than many of you, who modify the game to make it do something different than the original.  What I have been doing is deciphering how the game works and getting as much data as I can from it, so that I may remake the game from scratch, as exact as possible.  My goal is to be pixel-perfect... every screen transition, the way a character walks forward to attack, and so on.  Though there have been a couple of places where I had to make some concessions or chose not to reproduce a bug that was in the original.  I'm sure I'll have enough quirky bugs of my own! : )

It is a combination of cracking how the original assembly does something, trying to decipher whether and how data is stored in the ROM and finding a way to use it, and original programming.  It's interesting to me how there is a large amount of information that is useful both to me and to those of you hacking the original game, and that there are also a few things that I need to know that you don't, or vice versa.  For example, figuring out how the game did the spell visual effects was crucial for my project, but might not quite be as interesting to other FF4 hackers.

I attached a few random screenshots.  As you can see, the platform is a browser.  I won't ever release it for general use, for obvious reasons, but it would be really great to show to some people eventually.  It's complete and fully playable nearly to the underground as of right now.

[LordGarmonde]

Awesome! - You could consider releasing code that takes an existing ROM and makes it playable in the browser. I can't think of anything that would be wrong with that.     I have no idea how complicated that would be given your current design - but either way: full marks!

[chillyfeez]

So this is an html file that when loaded into a browser acts as a SNES ROM (plus emulator, I guess)?
I don't think I've ever seen exactly that done before. Is this your own idea? Have you done this with other games?
anyway, cool stuff.

[Grimoire LD]

This would be extraordinary... now I fully understand what your end goals are, this has so much application that it's phenomenal! This would eliminate all space concerns in Every direction and really open up FFIV in a way that we can currently only Dream of!

To turn FFIV into a computer program without any limits to banks, sprites, graphics, routines, it could become anything we could virtually dream of, instead of being confined to the cage (albeit large cage) that we are in with the ROM of FFIV.

[LordGarmonde]

This would be extraordinary... now I fully understand what your end goals are, this has so much application that it's phenomenal! This would eliminate all space concerns in Every direction and really open up FFIV in a way that we can currently only Dream of!

To turn FFIV into a computer program without any limits to banks, sprites, graphics, routines, it could become anything we could virtually dream of, instead of being confined to the cage (albeit large cage) that we are in with the ROM of FFIV.

Since I'm still learning please forgive the noobish question: regarding bank switching - what is problem, speed? Because one thing that caught my eye looking up ASM references were the two block move commands: MVP & MVN

Block Move - From http://wiki.superfamicom.org/snes/show/Jay's+ASM+Tutorial

This is by far the weirdest instruction I?ve seen. It basically moves chunks of blocks from one place to another. The first $<8-bit exp> is the bank of the destination. The second is the bank of the source. X is loaded with the 16-bit address of the source, and Y is loaded with the 16-bit address of the destination. A is loaded with how many bytes to transfer. eg.

Code: [Select]

mvn $<8-bit exp>,$<8-bit exp> mvp $<8-bit exp>,$<8-bit exp>

X: ????  Y: ????  A: ????    rep #$30       ; Make accumulator and index 16-bit
X: ????  Y: ????  A: ????    ldy #$8000     ; load X with $8000
X: ????  Y: 8000  A: ????    ldx #$9000     ; load X with $9000
X: 9000  Y: 8000  A: ????    lda #$0005     ; lead A with 5
X: 9000  Y: 8000  A: 0005    mvp $80, $A0   ; block move increment

will transfer 5 bytes from $80:8000 -> $A0:9000
The only thing I could ever think it would be used for would be to change which bank things are in: I'm way at a loss on that one though. 

[Grimoire LD]

This would be extraordinary... now I fully understand what your end goals are, this has so much application that it's phenomenal! This would eliminate all space concerns in Every direction and really open up FFIV in a way that we can currently only Dream of!

To turn FFIV into a computer program without any limits to banks, sprites, graphics, routines, it could become anything we could virtually dream of, instead of being confined to the cage (albeit large cage) that we are in with the ROM of FFIV.

Since I'm still learning please forgive the noobish question: regarding bank switching - what is problem, speed? Because one thing that caught my eye looking up ASM references were the two block move commands: MVP & MVN

Block Move - From http://wiki.superfamicom.org/snes/show/Jay's+ASM+Tutorial

This is by far the weirdest instruction I?ve seen. It basically moves chunks of blocks from one place to another. The first $<8-bit exp> is the bank of the destination. The second is the bank of the source. X is loaded with the 16-bit address of the source, and Y is loaded with the 16-bit address of the destination. A is loaded with how many bytes to transfer. eg.

Code: [Select]

mvn $<8-bit exp>,$<8-bit exp> mvp $<8-bit exp>,$<8-bit exp>

X: ????  Y: ????  A: ????    rep #$30       ; Make accumulator and index 16-bit
X: ????  Y: ????  A: ????    ldy #$8000     ; load X with $8000
X: ????  Y: 8000  A: ????    ldx #$9000     ; load X with $9000
X: 9000  Y: 8000  A: ????    lda #$0005     ; lead A with 5
X: 9000  Y: 8000  A: 0005    mvp $80, $A0   ; block move increment

will transfer 5 bytes from $80:8000 -> $A0:9000
The only thing I could ever think it would be used for would be to change which bank things are in: I'm way at a loss on that one though. 

Bank switching in practical terns is a simple matter, JSL to where ever you like and there's no speed drop to my knowledge. The game uses this all the time and will sometimes jump into ROM far outside of the banks to deal with random minutiae of certain routines.

These MVP dealings mostly appear, from my experience, in opening and deciding menu parameters (mainly in the main menu). I'm unaware of them being used elsewhere.

[LordGarmonde]

Bank switching in practical terns is a simple matter, JSL to where ever you like and there's no speed drop to my knowledge. The game uses this all the time and will sometimes jump into ROM far outside of the banks to deal with random minutiae of certain routines.

These MVP dealings mostly appear, from my experience, in opening and deciding menu parameters (mainly in the main menu). I'm unaware of them being used elsewhere.

Oh - I think I get what you're saying. Menu layout doesn't change so it's most efficient to just have it laid out somewhere and then just move it into a usable space. Cool; thanks LD. One thing that hangs me up is keeping straight what makes sense from a strict ASM perspective - and what is more specific to the SNES; bank switching being one example. I'm slowly getting there though.

[chillyfeez]

Namingway also uses MVP to transfer the new name into the place in RAM where characters' names are stored.

[avalanche]

Thanks all for the feedback!

LordGaramonde: it doesn't have to be two different banks, either. There are *lots* of memory copies in the code that could be made with that instruction, but are manual loops instead. I think there are quite a number of useful instructions they just don't happen to use in the original code, and I'm not sure why.

Chillyfeez: it's a ton of javascript, really. Not an emulator; it doesn't run a ROM for example.  But is like any other web game. You go to the site, and you see the familiar title screen, and can play from there. I've worked on games before, and remaking old ones is just so much fun. But this is by far the most complete. Probably because this one is such a favorite from childhood.

Grimoire: definitely trying to avoid some of those limits like a fixed number of NPCs, sprites, all that stuff. I originally wanted it to be moddable. I still want that, but getting the original working is my priority for now, and it sure is a lot of work.  But one of the cool things about what you do is that you could technically burn a cartridge and play your game on a real console

[Grimoire LD]

Grimoire: definitely trying to avoid some of those limits like a fixed number of NPCs, sprites, all that stuff. I originally wanted it to be moddable. I still want that, but getting the original working is my priority for now, and it sure is a lot of work.  But one of the cool things about what you do is that you could technically burn a cartridge and play your game on a real console

Oh yes, I can imagine the scope of this could go beyond much of anything I can imagine as far as my fairly meager skills can realize. I also understand that due to it getting the game to work 1:1 some limits will still have to be imposed, but once the 1:1 is created I imagine it's free roam from thereon. If it is moddable.

[Gedankenschild]

What an impressive undertaking! This seems like the kind of project someone would decide to do, realize what it takes and promptly abandon it afterwards. 
Amazing you made it this far!