Balloon Fight hack - Would this actually work on hardware?

I am really getting deep into this interesting world of NES coding and hacking. The only downside is that I would like to try my hacks on real hardware, not just emulation, but lack any kind of equipment and/or knowledge to do so. Since these are all new things for me, please excuse my extreme n00bism.

So I made a hack for Balloon Fight (JU) where you can play a 2-player trip game.
The original rom is a NROM-128 16k which I made into NROM-256 by adding a new iNES header, and then reorienting code to work like the original game.
Too many small details to explain, please take a look at my code if you like. Assembles with ASM6, Balloon Fight (JU) rom is needed. IPS ready to go.

Maybe you like to try it out? Does it work?

Tried it on my PowerPak. It works for the most part, but pressing the reset button locks the game up on a black screen. Also, the menu seems to have a 5th position? Picking it just seems to start a 1-player Balloon Trip game.

Edit: The reset problem happens with the vanilla unpatched Balloon Fight too, so not your fault.

Ooooh! Love me some Balloon Fight. Gotta check it out. However, I don't have a PowerPak so I can't help (Even though I'd like to), but trust me, it can be a pain to debug your stuff on real hardware.

I actually misread the title as Balloon Fight back.

I think it sounds awesome to have a parody or hack of this game called Balloons Fight Back or Balloon Fights back.

Thanks for trying it out. Yeah, the fifth option is intentional - adding yet another mode for someone to add what ever functions into the game. More than 15k of nop's in upper bank, that is a lot to play around with

You could always do a CHR RAM conversion, with or without tile compression. This way you can replace tiles as you need them in case you need more background detail. (But then BF has a bunch of unused tiles anyway.)

For educational purposes, I will look into this. If I understand this correct, you are referring to a BNROM hack?

It could be interpreted as BNROM or as NROM-256 rewired to take a 6264. Either way, the same board RHDE uses.

I noticed that in two-player balloon trip, the game immediately ends if the first player dies, but it doesn't matter how well the second player is doing. Also, the second player starts out very low, and player 2's score does not display. And bad things happening to either player kill the music.

Ah. Well, right now the two player trip mode is just a result of number of players set to "2" and game mode to "trip", so I am not surprised there are some things not working correctly.
I haven't yet added anything to support the 2 player mode, just the possibility to select it and play. So there are some work to do apparently.

Thanks for trying it out

Is there a way to expand the ROM without making the IPS so big? In ca65 there's a way to .incbin a portion of a file, and I use that in my Solar Wars UNROM hack to insert 32K of blank space before the existing PRG ROM. You appear to do the same thing in the asm6 source of your hack. Or if you know the user is overwhelmingly likely to have Python installed, such as on Linux, you could write a Python script that inserts 16384 bytes at offset $0010 in the file, putting everything in the right place for the IPS to line up properly. Even dd, which is present in most UNIX-like operating systems, could be used for this. But not everyone who wants to try this has ca65, ASM6, dd, or Python installed to expand the ROM before applying the IPS, especially on Windows.

I'm guessing if the expanded blank space is at the end of the ROM then the IPS would result in a series of RLE block.

Otherwise if the patch involves moving ranges of data around even by 1 byte, a format like vcdiff is much more suited. For example, a vcdiff patch of your UNROM hack is about 16K. xdelta 3 is a popular tool for vcdiff.

Because of the memory layout of Balloon Fight, the empty space has to be at the beginning. In fact, most expansion patches for NES games will require insertion of blank space at the beginning because of the demands of XIP ROM on a 6502.

Dwedit suggested the xdelta UI (.vcdiff) and beat (.bps) tools, which appear to support rearrangement. But I don't think most emulators that can apply IPS on the fly can apply those. But it's still better than an IPS file that contains effectively the entire ROM.

So can we get a vcdiff for this patch?

Perhaps.
As far as I understand



Includes entire game with first 16 bytes header, will mirror $8000-$bfff and $c000-$ffff - working just fine


Skips header so you need to write it yourself. However -



Will not work. Stuck at $8000.

Since reorienting the 16k of code into upper bank, ofcourse, will cause (almost) every instruction working in absolute mode to be wrong, you somehow have to fill the space down to lower bank to get the correct address OR change (almost) every absolute mode instruction in the game to fit upper bank orientation..
With that method the ips would be 1 byte + changes in addresses I guess?

(xdelta extension not allowed for upload.. rename my file)

So..
What.. the.. 278 bytes?!

Don't just rename extensions -- that isn't guaranteed to work given how MIME types work and browsers behave. Try zipping up the file and providing that.

Yeah, that's what xdelta patches do, they are nice and tiny.