I don't understand what you just said.  Your sentences almost seemed to taper off without completing your thought.

If you're really porting DDP, what does the prototype (or anything marioxb is doing) have to do with your attempt?  I'm confused.

Due to the DDP files being loaded into very strange addresses in RAM (not aligning at all with typical bank lines), I decided to go with the MMC5 approach and just try to emulate the FDS BIOS in an MMC5 cart.  I have written a file loading routine to load the "files" from ROM into the appropriate area in RAM.  However FCEUXD is giving me problems.

It looks like FCEXUD is really starting to show its age.  Its MMC5 support is a little off.  It doesn't seem to be handling PRG-RAM swapping properly.  I have tried the ROM in my own emu, NEStopia, and Nintendulator, and they all get the expected sky-blue screen, whereas FCEU seems to be crashing shortly after I jump to the game's code.

I'll keep this up just because I'm having fun.  But I'm not going to bend over backwards to support FCEU.  So odds are if/when I finish this, you won't be able to play this hack/port in FCEU or any other emu with lacking MMC5 support.

I'm not big on private E-mails for this kind of thing.  So I just uploaded it:

http://dischmeister.googlepages.com/nesddp_crap.zip

I just sloppily zipped everything in my work folder and uploaded it.  All the bin files with the long names are the individual files off the game disk (with their headers stripped).  Naming convension is "[diskside]-[filenumber]_[filesize] at [address to load to]__[file name].bin

I then merged all those together into 1 file, and padded it to 120K ("files.bin").  This 120K plus my 8K fake BIOS will produce an even 128K ROM.

"header.bin" is the iNES header

"newbios.asm" is the code I'm putting in to make a sort of FDS emu with MMC5 (ie:  this is the actual hack).

running build.bat will produce "ddp.nes"

Currently it loads and plays the intro just fine (although the FDS sounds are missing of course), but it crashes on soft reset (I'm looking into that now).  Once I figure that out, I'll probably replace the "wait for side B" code with some "wait for start to be pressed" code -- then I'll have more BIOS work to do.

I'm thinking of using one of the MMC5's square channels to fill in for the FDS channel in the intro (and anywhere else it's used for melody).  I plan on putting in the DMC samples from SMB2 for the FDS sound effects (like when you lift stuff, get hurt, etc).  But sound is the very last thing on the list



EDIT

Fixed the soft reset problem.  Apparently DDP was using some RAM area that the normal BIOS prepped that I wasn't prepping.  Anyway -- fixed.  Tried the hack again in Nintendulator and it runs, but CHR doesn't display.  I'm guessing Nintendulator just doesn't like MMC5 with CHR-RAM (since all commercial games use CHR-ROM).  So scratch that one off the list as well.

Still works great in my emu and NEStopia.  I'll have to try some other popular emus.  Next... to look at the "wait for side B" thing.

That implies the equation

Disch >= Pirates

but wherein lie the Ninjas?

ninja = those who practice ninjutsu
ninjutsu = "the art of stealth"
Disch = mix of "dash" and "invincibility"

Ladies and gentlemen, I think the connection is clear.

I knew to use the plus and minus in yychr thats why I suggested that it would be a better tool then tlp. But I looked at this prototype and yielded no result with it. The normal SMB2 rom is twice the size of the prototype. So I assumed that it was compressed. Not knowing the specifics of it. I'll look over it again still tho I don't like the prototype myself. Hacking the normal rom is much easier. But Marioxb has done a good job with it already. So I would stick with the prototype even tho it's a pain that can keep you going. It's not like I have something else to do right now I am bored. Also I would suggest getting the tlp fix from here maybe one could see more with it.

I'm pretty sure BMF never got finished his hack.

You can see that it still says "IN PROGRESS" on his page. I will happily share my patch(es) when I'm done.

The reason why the SMB2 prototype is a smaller rom is because of the additional frames of animation in the final version and the ending with the sleeping Mario that is absent from the proto.

Well I got the game playable

http://dischmeister.googlepages.com/ddp.zip

I noticed graphical problems in NEStopia -- like the CHR wasn't being loaded properly.  I suspect this is due to MMC5+CHRRAM weirdness.  I have an idea for what might fix it -- but I'm thinking of making another effort to use MMC3.  This first attempt actually got me a lot more familiar with the FDS from the game's point of view.  Now that I'm more familar with what the game needs to do and when -- I think I'll be able to do it.

Try out this MMC5 version if you like.  Note it probably doesn't work in several emulators for the reasons previously mentioned.  Pressing start when the intro story with the kids reading the book doesn't work (but pressing start during the title screen with the blimp does).  It will make a .sav file, but won't actually save your game.  And I didn't test it much past Chapter 1.

The game sounds hollow without the FDS sound channel kicking in.  I'll definately have to put in the DMC replacements for the MMC3 version.



UPDATE:

I want to punch the DDP developers.  They load the files like so:


What sucks is the Game Data block.  $BF00-$D0FF.  What the hell.  If they would've just shifted that over to $C000 I'd have a nice clean spot to split the pages.  That would allow me to just have a single 8K page swapped in for the chapter with minimal PRG duplication.

So I figured that would be the best approach to this situation.  So I looked at the $BF00-BFFF and $D100-D1FF sections in the appropriate files and started to tally up what I would need to flip them.  Seemed managable at first -- until I started getting into jump tables and other crap.  Long story short, it ended up being a nightmare.  So I've decided to scrap this plan.

Plan B is to swap out both 8K pages (at $A000-BFFF and $C000-DFFF) for each chapter.  This means that I'll have 16K PRG (2 full pages) assigned to each chapter, but only 4.5K of that is actual chapter data.  That means that the other 11.5K will be the engine (from the MAIN-PRO file) duplicated for each chapter!  Talk about a major waste of space.

I haven't worked out whether or not this will push the filesize up to 256K.  I suspect it will.  It will also make hacking this ROM (if someone were inclined to do so) a real bitch, because if they want to change something at $A000-BEFF or $D100-DFFF they'll have to make the change at eight different places in the ROM!

The good news is... aside from that chapter nonsense... the rest of the files seem to be loaded into $6000... which is very easy to do (don't have to mess with PRG swapping, can just copy the files to RAM and be done with it).  The end game stuff I can probably just put on its own 16K like I do with the chapters.  I'll have some duplicated code there but I don't expect that to be much of an issue.  Only file that will be sketchy, I think, is that SOUND-DT file.  I have no idea when it is loaded (haven't seen/noticed it loaded yet in my test runs) or what function it serves.  Judging from the file title it's something I'll probably remove anyway because of the absense of the FDS channel.  Also, judging from where it's loaded, it might be used for the ending sequence... and if that's the case, I'll easily be able to fit it in the same 16K I put the other ending files.

Fortuantely, though... nothing but the MAIN-PRO file ever gets put at $8000-9FFF.  This means MMC3 is possible without major code adjustments!  I can have $8000 fixed, and have $A000 and $C000 swappable.  $E000 can be all my own code to make the hack work (after I carry over a few FDS BIOS routines the game uses) and can be free space if I need to tweak some things in the game.  I can also put DMC samples there when I need them!  8K is huge and there's no way I'll run out of space!

Last big hurdle will be to isolate all the places the game writes to $8000-DFFF.  That area is RAM on an FDS and the game can manipulate it at will.  On MMC3, however, writes to those addresses will change mapper registers which will royally fuck up the works.  Though at first glance there doesn't appear to be many areas in the game where it writes to it (at least none that aren't easily removable).

Once I resolve the issue with $8000-FFFF writes -- slapping together a functioning MMC3 ROM will be a relatively easy task!  Hooray!