News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Ben Boldt

Pages: [1] 2 3 4
1
ROM Hacking Discussion / Re: Zelda II Title Music - VRC7
« on: September 24, 2020, 11:47:40 pm »
I got Music-A working pretty well now, and sound effects are now handled properly.  The "fast" version of the music is still original.  Not sure how the normal music stops when you proceed to the 2nd menu screen but my code is not aware of it and not stopping, so that is the only known bug so far.  I had started some work on using the triangle channel in this music, which I think has potential to make it sound more authentic to the original.  For this patch, I disabled the triangle though.

Download patch:
https://sites.google.com/site/benboldt2/files/tetris_vrc7.bps

This is to be applied to "Tetris (U) [!].nes".

Let me know if you like it and would like to see more work done on it.

2
ROM Hacking Discussion / Re: Zelda II Title Music - VRC7
« on: September 12, 2020, 03:23:36 am »
Update:
Getting closer on the Music-A score (Dance of the Sugar Plum Fairy):
https://youtu.be/-6XARnfIZgE

I noticed am intermittently missing a few FM note-off events here and there.  I will need to debug my code and see if I can fix that.  It seems all of my note-on events work, which do also push a note off then note on, so I think maybe my rests have an intermittent problem pushing a note-off.

Except for part of the initialization, this code now has all the necessary delays for VRC7 audio register writes.  I have removed my circular buffer and now I write directly and added cycle burn loops where necessary.  I feel kind of dirty putting cycle burns in there but they are more efficient than that buffer was!

Edit:
I found the bug with note-offs.  I first narrowed it down that it was not a problem with coexiting with Tetris by copy/pasting the music score into my original ROM that has just the gray screen with no game running.  It also had this same bug when run that way.  Additionally, I turned off the pulse channels in the emulator to prove it was not a pulse channel making these sounds.  It was definitely an FM channel.

Once per frame, I parse the next step(s) of the score for each channel.  Some items in the score invoke a delay and exit, such as "play note", "play rest", etc.  The code parses an unlimited number of items until it hits one of these delay-invoking items.

To make things a lot more efficient, I keep the 3 FM registers for each channel in RAM, and I write to the RAM copy while parsing and set a flag.  Then when I complete a delay-invoking item, I check those flags and write only the registers that got touched to the VRC7, one time.  This is especially important to optimize this way because each VRC7 FM register write has delay requirements.  (The code does not keep track if the register stayed the same though, it will write any register that got touched.)

The problem is that I never cleared the flags!  To set the flags, I did an 'INC' to the flag.  I figured I would never have 256 updates before a delay-invoking item so I wasn't too concerned about a rollover.  But since I never cleared these flags, if the update flag ever ended up a 0, the register got its update skipped that time, which tended to affect note-off events the most noticeably.  I heard a few other peculiar things that I didn't quite understand, probably other registers being skipped.  Anyway, very happy to have that fixed.

3
ROM Hacking Discussion / Re: Zelda II Title Music - VRC7
« on: August 31, 2020, 01:12:40 am »
Sort of an update on this, I successfully got this engine running in Tetris:

https://youtu.be/tX-3elRAmbw

I got the "TetrisNESDisasm" Github project compiling which made life much easier for this sort of thing!!

September 03, 2020, 01:11:17 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Another update,

Music start/stop mostly working and original sound effects patched in.  Pretty glitchy but making progress!

https://www.youtube.com/watch?v=SqAf23aCR7Y

Edit:
I kind of like this idea more and more making Tetris VRC7...  I am looking at writing a score for Music-A (i.e. "Dance of the Sugar Plum Fairy" from The Nutcracker Suite).  The original Tetris score definitely is a unique take on this piece, partially due to limitation of sound channels but also some of its own charm that I would be a fool to ignore and replace with something more accurate to The Nutcracker.  It is also in a different key than the real song.  Maybe this was so that it got along better with Music-B and Music C??  Or the sound effects?  It's easy to throw something together but hard to keep its charm with these things.  I could easily make it sound like a generic Windows 95 MIDI file playing for example, but that's not what we would want here.

4
ROM Hacking Discussion / Re: Zelda II Title Music - VRC7
« on: June 14, 2020, 02:16:39 pm »
It is pretty much up to each game how it wants to handle its sound code.  It might be messy and scattered around, or it might be nice and organized with very specific entry points.

Most games have an NSF dump, and typically the the NSF contains only the sound-related code and data.  So someone already did the work identifying and isolating the music code/data.  I am not speaking from experience on this, but it might help to see how the NSF correlates to the original ROM, to help understand where the music code and data is and how it is accessed.

5
ROM Hacking Discussion / Re: Zelda II Title Music - VRC7
« on: May 20, 2020, 10:53:07 pm »
I know what you mean about CPU overhead.  The Zelda II overworld has lag just walking around the way it is.  Any little bit extra is destined to be a disaster.  Hopefully the title screen has some spare cycles though, that sounds reasonably possible.

Very good point with the RAM, I forgot all about that.  I am using somewhere on the order of 256 bytes new.  I also used a few bytes on the zero-page which, thinking about it now, I stole from the old music engine so I have bound to screwed something up with that if I plan to use the existing engine for sound effects.  In Zelda II, the title screen music stops when you are able to start using the menu, so a switch-over is possible there, avoiding conflicts I guess.

I am not very experienced hacking existing ROMs like this, so I have probably really understated the amount of work or potential pitfalls that I may soon face.  I can tell you from my experience though that any time someone uses the term "drop-in" (like I did), that's your sign they don't have any clue about what is involved to make that really happen.  :thumbsup:

I just want to get the noise channel working and sound as best as possible, that is my main goal.  A new project can be getting it into the real game.

6
ROM Hacking Discussion / Re: Zelda II Title Music - VRC7
« on: May 20, 2020, 12:56:16 am »
@OP : So you're replacing the entiere music engine to support VRC7 ? Or just extending the existing engine ?
Once finished, will on be able to use it to replace a song in a rom with another one?

I wrote a whole new music engine, is not extended from the existing one.

Typically music engines in games are 1 self-contained chunk of code that gets run once per frame.  In Zelda II, the code does a JSR $8000 once per frame during the title screen and returns when done doing all the music stuff.  It also uses RAM location $EA to control the music engine.  Writing $01 to $EA starts the title screen music, $80 stops it, and some other values play sound effects as you enter your name, etc.  The music engine resets $EA back to $00 once it uses it, to acknowledge and prepare for the next command.

My code is set up to add a JSR to my code first before the JSR $8000.  So any things that I want my music engine to take control of, it takes the value of $EA and sets it to $00 so that the original music engine doesn't see it.  And if there are things I want the original music engine to still do, I can just leave $EA alone, and let it pass through to the old engine take care of it.  All of this pertains just to the title screen.  Once you get into the game, apparently there is a different music engine at $9000, and it uses RAM addresses slightly differently.  I had planned to do just the title screen and leaving the original sound effects.

Adding this FM engine to an existing game is actually a lot easier than it sounds, at least in most cases.  The first thing you have to do is get the game running with the VRC7 mapper.  You have to find all the places where the original mapper is being written to, and then understand what that is doing, such as changing ROM pages, H/V mirroring, etc.  Then change those bits of code to do the same thing writing to VRC7 registers.  Nesdev wiki has all the info needed for that and emulator debuggers can help find them all.

Once the original game runs on VRC7, you would then expand the ROM.  VRC7 supports up to 512kiB PRG-ROM.  Then in this new extra space, drop in my music engine.  Then it will be only a matter of hooking in a call once per frame to the music engine on the new page (probably in place of the original call to the original music engine), and restoring the original page(s) when returning.

Right now my code has a circular buffer for sending commands to the VRC7 FM registers, and I did this because there are required delays between writing to FM registers.  I find that my buffer is inefficient enough that it defeats its own purpose, and I ought to just do some cycle burns.  But as it is now it does require an additional hook to pull commands out of the buffer.  I plan to make that go away though.

7
ROM Hacking Discussion / Zelda II Title Music - VRC7
« on: May 17, 2020, 07:29:57 pm »
Inspired by this youtube video:

https://www.youtube.com/watch?v=wRCjkFQuMKs

I thought I would try my hand at making this happen in a real NES ROM, and maybe even get it hacked into Zelda II.  Staring by looking at Zelda II, it seems that its title screen music engine runs from a call to ROM address $18000 once per frame, and is controlled by RAM address $EA.  Normal game has its own music engine entry point located at $19000.

Infidelity has hacked Zelda II to run on MMC3 already, so it seems following his changes tweaked to VRC7 should be approachable.

Disch has hacked Final Fantasy I with a FANTASTIC Namco-163 music engine.  So to get things started, I decided to write a music engine similar to Disch's for VRC7.  And here we are with a demo:

https://sites.google.com/site/benboldt2/files/zelda_vrc7_v1.zip

I wrote the score using FCEUx, which sounds considerably different than Mesen.  I am thinking Mesen is probably the more accurate one...  So in this case you will want to use FCEUx to listen to it.  I will tweak it to sound best on a real cart eventually, which would likely to match Mesen.

This supports:
 - Similar music score format as Disch's
 - All Pulse, Triangle, and FM channels supported
 - Playing all notes at all octaves, register values in ROM tables
 - score loops and gotos
 - Envelopes for pulse channels via table
 - Arbitrary length envelopes
 - Envelopes can stop or loop back to an arbitrary index
 - Constant volume for pulse and FM channels
 - Vibrato for pulse channels via table of deltas
 - Vibrato pulse period MSB register update using the sweep trick
 - Vibratos can stop or loop back to an arbitrary index
 - FM sustain enable/disable
 - Pulse duty cycle
 - Main program can start and stop song writing to RAM location $EA
 - Snap-to notes, i.e. new frequency but envelope does not restart (not demonstrated, not found anywhere it sounds good)

Not supported yet:
 - Noise channel (at all)
 - Envelopes for FM channels (could be interesting)
 - Vibrato for Triangle or FM channels (needed)
 - Writing to the FM custom patch (needed)
 - Music scores stored on additional ROM pages, will be necessary if doing multiple songs.

I wanted to share and get some feedback.  I am new to writing 6502 ASM, wondering if my code could be more efficient.  It is a lot of code but only small chunks of it should run at a time.  I made a circular buffer for sending FM commands to the VRC7.  I find that simply checking and updating the buffer provides the necessary delays -- that doesn't say much for how efficient it is.  :S

I think it could be interesting to hack Zelda II with this.  Personally, and I don't mean to offend anyone, I found Zelda II to be flop, with the exception of the title screen.  Is anyone else interested in seeing this happen?  At the very least, I think this is becoming a good FM engine.

8
ROM Hacking Discussion / FCEUX Text Hooker, .tht table format
« on: February 02, 2020, 03:49:29 pm »
I was playing with Text Hooker for the first time, trying to get it to make some sense of the game "Jarinko Chie - Bakudan Musume no Shiawase Sagashi".  I have not used Text Hooker before so I googled info on it, and it seems the first thing I have to do is build a THT table.  From what I gather, this is a text file, where each line is like this:

00=A
01=B
02=C
etc.

The first 2 digits are a hex code corresponding to the NES PPU's background pattern table, which would correspond to the right side of the window in FCEUX's PPU Viewer.  So, I built up a text file with all 256 hex codes, and filled in the corresponding Japanese Hiragana and Katakana characters, the special tenten and maru keywords per FCEUX help docs, and backfilling the graphics and ones I didn't know with @ symbols:

Code: [Select]
00=
01=あ
02=い
03=う
04=え
05=お
06=か
07=き
08=く
09=け
0A=こ
0B=さ
0C=し
0D=す
0E=せ
0F=そ
10=た
11=ち
12=つ
13=て
14=と
15=な
16=に
17=ぬ
18=ね
19=の
1A=は
1B=ひ
1C=ふ
1D=へ
1E=ほ
1F=ま
20=み
21=む
22=め
23=も
24=や
25=ゆ
26=よ
27=ら
28=り
29=る
2A=れ
2B=ろ
2C=わ
2D=を
2E=ん
2F=ア
30=イ
31=ウ
32=エ
33=オ
34=カ
35=キ
36=ク
37=ケ
38=コ
39=サ
3A=シ
3B=ス
3C=セ
3D=ソ
3E=タ
3F=チ
40=ツ
41=テ
42=ト
43=ナ
44=ニ
45=ヌ
46=ネ
47=ノ
48=ハ
49=ヒ
4A=フ
4B=ヘ
4C=ホ
4D=マ
4E=ミ
4F=ム
50=メ
51=モ
52=ヤ
53=ユ
54=ヨ
55=ラ
56=リ
57=ル
58=レ
59=ロ
5A=ワ
5B=1
5C=ン
5D=@
5E=@
5F=@
60=@
61=@
62=@
63=@
64=@
65=tenten
66=maru
67=2
68=@
69=?
6A=!
6B=3
6C=.
6D=@
6E=@
6F=@
70=@
71=@
72=@
73=@
74=@
75=@
76=@
77=@
78=8
79=@
7A=@
7B=@
7C=@
7D=@
7E=@
7F=@
80=@
81=@
82=@
83=@
84=@
85=@
86=@
87=@
88=@
89=@
8A=@
8B=@
8C=@
8D=@
8E=@
8F=@
90=@
91=@
92=@
93=@
94=@
95=@
96=@
97=@
98=@
99=@
9A=@
9B=@
9C=@
9D=@
9E=@
9F=@
A0=@
A1=@
A2=@
A3=@
A4=@
A5=@
A6=@
A7=@
A8=@
A9=@
AA=@
AB=@
AC=@
AD=@
AE=@
AF=@
B0=@
B1=@
B2=@
B3=@
B4=@
B5=@
B6=@
B7=@
B8=@
B9=@
BA=@
BB=@
BC=@
BD=@
BE=@
BF=@
C0=@
C1=@
C2=@
C3=@
C4=@
C5=@
C6=@
C7=@
C8=@
C9=@
CA=@
CB=@
CC=@
CD=@
CE=@
CF=@
D0=@
D1=@
D2=@
D3=@
D4=@
D5=@
D6=@
D7=@
D8=@
D9=@
DA=@
DB=@
DC=@
DD=@
DE=@
DF=@
E0=@
E1=@
E2=@
E3=@
E4=@
E5=@
E6=@
E7=@
E8=@
E9=@
EA=@
EB=@
EC=@
ED=@
EE=@
EF=@
F0=@
F1=@
F2=@
F3=@
F4=@
F5=@
F6=@
F7=@
F8=@
F9=@
FA=@
FB=@
FC=@
FD=@
FE=@
FF=@

I saved this with Notepad++ with UTF-8 encoding and when I open it in FCEUX, make a selection, and press snap, I get garbage in the "Hooked Text" window.  Going back to Notepad++ and converting it to ANSI encoding, the garbage then corresponds to the ANSI shown in Notepad++.  I also tried saving another .THT file using Japanese Shift-JIS encoding in Notepad++, and it just has a different garbage.

Does anyone know how to correctly encode FCEUX .THT files for Japanese?  Or should I be using something other than FCEUX for this?

9
News Submissions / Re: Homebrew: Chicken of the Farm : Original Game
« on: February 17, 2019, 07:58:43 pm »
For infinite health:

SZKUPOVK

10
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: June 23, 2018, 11:06:09 pm »
Oh my, I got the 60+ days old warning when making this post......  This is a pretty slow-going project.  Slowly but surely!

I got Underwater Temple ("future chaos temple") done today!

MP3:
https://sites.google.com/site/benboldt2/files/ff_namcot_underwater_temple_nestopia.mp3

Files:
https://sites.google.com/site/benboldt2/files/ff_namcot_underwater_temple.zip

You can use this Game Genie code to start the game with the new music:
TGXZTZPK

These are the only ones left to do now:
3. Ending Theme
6. Airship
13. Floating Castle
14. Future Chaos' Temple

11
Personal Projects / Re: Kung Fu 50x: Fight Sylvia!
« on: April 14, 2018, 12:52:02 pm »
I think it is done now!  Please try it and let me know any bugs or recommendations.

https://sites.google.com/site/benboldt2/files/kung-fu-50x.zip

Remember, Game Genie code PAVELZPL if you do not want to play 50 times.



Edit:

Updated the colors of the sprite when you defeat Sylvia (as boss) when she falls off the screen.  Updated file at same download link.

 

12
Personal Projects / Re: Kung Fu 50x: Fight Sylvia!
« on: April 03, 2018, 02:26:04 am »
Well, you have to be creative with the ending if you fight Sylvia.  You can't defeat her and then fall in love again, that doesn't make sense.

I think this is unique, something that has not been done before.  I am definitely not the only one who is a little tired of every game being about saving the girl.  This time the girl is strong and fights back.  And you can even defeat her and go a whole different direction.

Guy saving girl isn't for everyone, guy saving guy isn't for everyone.  Think about it from a different perspective.  It might not be meant for you, but I think there is a place for it, and it can still be enjoyable.



Edit:

I figured out how to edit palettes!



Thomas is a background image and Mr.X is a sprite-based image.  I think it may be possible to turn his head into a different sprite and use a different palette so I can make his hair and eye the right colors.



Edit:

Update:

Luckily, Mr.X's head is comprised separate sprites in all cases, so it is already quite possible to change the palette selection of only the head, to accomplish the hair and eye colors.

I have been able to do the following things to the ending scene:

  • Put Mr.X's standing up CHR data into the game
  • Moved Mr.X 3 pixels to the left (resolved to a 1-byte change)
  • Changed the pink Sylvia palette to the body color of Thomas
  • Changed the palette selection of only Mr.X's head to sprite palette 0.
  • Changed the colors of sprite palette 0
  • Changed text to read "Thank you Thomas!", "I love you..."  Simpler is better.
  • Done.

I detect when to change the palette selection and to overwrite palette 0 colors by looking at the OAM/sprite DMA RAM area starting at CPU RAM location $200.  If the sprite tile index at location $219 == #$CC or $229 == #$CC, the game is displaying Mr.X's head in the bound-to-chair image, either in the cutscene and at the very beginning of the ending sequence.  If I do not see this tile selected, I don't touch any palette stuff.  The palette changes remain for the rest of the ending sequence after this happens.

The game has a nice existing function for writing to PPU memory that occurs at the beginning of each V-blank interrupt.  I found that it accepts a value via RAM location $52, which is in index into a lookup table that stores 16-bit addresses, which point to data packets stored in ROM.  The data packet works like this:

byte 0 = PPU write address, MSB
byte 1 = PPU write address, LSB
byte 2 = # of bytes to be written
byte n = the bytes to be written.

So I stored in ROM this data:
3f 01 03 27 30 18

What this does is writes the 3 colors of Mr.X's head to sprite palette 0 at PPU RAM location $3F01.  I inserted code after the $52 business that checks:
  • Is $52 non-zero?  if so, bail, the game is using it.
  • Otherwise, does $219 or $229 contain #$CC?  If so, run the function, pointing to Mr.X's head palette data packet

And that all worked.  Definitely in all cases, palette 0 is correct, and I consider that part finished.  The entire ending sequence is completely done, it looks identical to the picture I photoshopped now, with different text.

However, I still have a glitch with palette selection for Mr.X's 2 head sprites during the cutscenes when he is bound to a chair.  My method is to let the game write the palette it wants in the DMA RAM, then I overwrite it immediately afterwards with my palette selection.  Well, the game must be updating the palette a lot because it flashes back and forth between palette 0 (me) and palette 3 (original to the game)...  I have a bit of work to do to figure out how to prevent the wrong palette index being momentarily written.

Also, I have not yet begun to look at turning the last boss into Sylvia.  It does appear that it shares a lot of tiles with Thomas, so it may be more of a palette and hairstyle change.



Edit:

I was able to fix the palette selection flashing thing when Mr.X is bound in a chair.  Mr.X has correct graphics and colors everywhere now.  All that is left is to edit the palettes of last-boss-Sylvia, change her head sprite, and anything else I can do to make her look tough and girly.

I have learned a lot from this hack!  I have never before done anything with the PPU before this, and now I have a mild understanding of how it works.  I may reattempt a 2-digit decade onscreen beat-game counter.



Edit:

I got the decade beaten game counter working tonight!  It is left-aligned, so games 0-9 look the same as normal, then 10 starts using the next tile to the right.





Edit:

I updated to 3-digit decade counters for lives and defeat count today.  This calculation shares common code in PRG page 03.  The new function takes in X as the number to display, Y as the offset into the RAM data packet to be fed to the PPU.  Basically, where it was doing a STA $xxxx,Y, I changed this to JSR #xxxx, and wherever it loaded A, I loaded X instead.  This allowed me to leave the code relatively untouched and using the same exact number of executable bytes.

I used the indexed INC instruction for my decade/BCD calculation.  Since indexed INC only works with X and not Y, I had to swap X and Y at the beginning and end of this function.  I pushed and pulled from the stack to do these swaps.

The extra digits for defeat count were okay, but for lives, it had the incorrect palette selected.  The extra digits came out light green.  So I changed it in the PPU attribute table.  That was a new one for me.

For game 49, I have made the walking and "smack" sound effects higher pitch and changed the pitch of the laughing in the cutscenes.  Also, Thomas still had the original Sylvia palette when he was bound to a chair in the ending, I fixed this.

This hack is pretty close to finished now.  I have saved the Sylvia battle for last.

13
Personal Projects / Re: Kung Fu 50x: Fight Sylvia!
« on: April 02, 2018, 12:23:23 am »
Thanks for the feedback.  Yes, I agree that 50 times is quite extreme, and I am sure the storyteller didn't want to be disproved. But I held true to it nonetheless.  You can have it kick in at game 2 and 3 with this Game Genie code:

PAVELZPL

Or you can use the RAM locations I mentioned earlier so you can set it to whatever version you want right from square 1.

Also, you can use these codes to make the game faster/easier as well:

ETVGZKSL+
VAVGLGEZ+
XTVGGGGE   Invincible unless time runs out

EYNKIAEI   Knife throwers throw the wrong way

VVVEGSSE   Enemy starts with minimum health

VXUKPYSZ+
VXKKZYSZ   Player has auto-recovering health instead of enemy



Edit:
I think I got Mr.X figured out for the ending:


The goal would be to look like this:


This is with Thomas untouched.  Thomas is standing a bit awkwardly and I am not sure what his arm is doing anymore... But it seems reasonable.  Mr.X has to stand straight up in this situation; neither of them are, in any way, a girl.  From our experience with Mr.X over the years, I think we can say that he appreciates a level of control. It wouldn't make sense for him to bend around like Sylvia was.

I will have to learn about the PPU and how to change color tables, or if it is even possible in this case to set the colors of this image, but I will try.  The top 8x8 would need a different color table than the other ones.  Also, Mr.X needs to move 3 pixels left versus where Sylvia was standing.  Not sure how the game is positioning them now, but they are not currently on the same 8-pixel boundary, so it seems like there should reasonably be a way to bump one of them in 1-pixel increments.

Also, another issue: The exclamation point is strange; it is not part of the text string, so I do not know how to remove it.  I may be able to write a blue tile on top of it; I have not tried that yet.

14
Personal Projects / Kung Fu 50x: Fight Sylvia!
« on: April 01, 2018, 09:49:06 pm »
Legend has is that you get to fight Sylvia when you beat the game 50 times.  Not true, until now!

Basically, the game is completely normal for the first 49 plays.  The 50th play (when counter reads '49') is different, it is based on "Sylvia Saves Thomas" hack by Megafield64.  I made some slight alterations to indicate some marital problems, and an improved hairstyle for our protagonist. ;)

Then the 51st play (when counter reads '50'), you are Thomas again.  The plan is to graphics-hack swapping Mr.X with Sylvia (I would love some help with that), and you save Mr. X from Sylvia, revealing Mr.X was his true love all along, etc.  It is completely functional now, and just needs graphics for fighting Sylvia instead of Mr.X, and saving Mr. X instead of Sylvia.  This is maybe somewhat comical in a way, but it is not meant to be homophobic.  Not sure how this board is what that; let's treat it as light-hearted please.


Here is how I did the hack:

I took the original Kung Fu (Mapper 0) and made it into Mapper 66 like Super Mario Bros./Duck Hunt.  This allowed me to quadruple the PRG and CHR space.  I placed copies of Kung Fu PRG into slots 0, 1, and 2, and copies of CHR into slots 0, 1, and 2.  Since Kung Fu is absolutely packed full, I moved some initialization code to PRG page 3 to free up some space in each of the other slots.  Then in that free space in each game, I detect the number of plays and do PRG/CHR swap based on <49, =49, and >49.  After switching, it just carries right along at the same spot in the new page.  It is functioning like a multicart in a way.  Also, I paid special attention to the unknown initial state of the 74_161 if this is to be put onto a real cartridge.  The reset vector should function properly on each page and ultimately get redirected to page 0.

Because of this shotgun approach (having 3 whole copies of the game), each version can be hacked freely, independently.  So I am able to edit directly for separate graphics and messages in each one for example.

Here is the ROM file layout:

$00000:0000F iNES header

$00010:0800F PRG 0 - Vanilla Kung Fu
$08010:1000F PRG 1 - Marital Problems (based on Megafield64)
$10010:1800F PRG 2 - Fight Sylvia, save Mr.X
$18010:2000F PRG 3 - Offload some initialization code

$20010:2200F CHR 0 - Vanilla Kung Fu
$22010:2400F CHR 1 - Marital Problems (based on Megafield64)
$24010:2600F CHR 2 - Fight Sylvia (needs more work)
$26010:2800F CHR 3 - Not used.

Please try it and let me know if you find any issues.

Player 1 & 2 defeat counters are located at $56 & $57, which get loaded into $5E for whoever is playing at the time.  Setting to $31(49) causes the game to go into marital problems mode, $32(50) or higher is fight Sylvia mode.  This is checked at the beginning of each level.  I imagine beating the game 256 times likely rolls back to 0.  ::)

If anyone would like to lend a hand with graphics, especially Megafield64 if you're out there, that would be greatly appreciated.  Also, upgrading the beat game counter to 2-digit decade would be amazing if anyone is up for a challenge.  I looked into this but am not very familiar with the PPU, so I was not able to make any progress on it yet.  There are still 80 bytes free PRG space available in each game at ROM file address $2DB:2DA (+ $8000 * x), which can be expanded more as needed.

BPS file:
https://sites.google.com/site/benboldt2/files/Kung%20Fu%2050x.zip

Play 49:




Play 50 (Sylvia and Mr.X graphics still not changed):





15
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: March 31, 2018, 04:28:54 pm »
Yes I am getting close but I have saved all the hardest stuff for last!  Floating castle will probably be the hardest I think.  Also, I really do need to improve or redo gurgu volcano.  That may be the very last thing I do since there is already something there for now.

16
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: March 26, 2018, 12:48:04 am »
Thanks edale.  I have still not done the save music...  That should be pretty quick and easy.  Do you have a preference which full song I should do next?  It is down to these 4 now!

3. Ending Theme
6. Airship
13. Floating Castle
14. Future Chaos' Temple

17
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: March 18, 2018, 12:58:05 pm »
Thanks edale.  There is an extra part in this song in Final Fantasy Origins that I did not do, it is mostly kind of an extra drum solo right where it loops.  I really like that and I may still try to add it.  Also, something just sounds a little off in the snare drum near the end, I just can't put my finger on it.  It seems like the last part is a little bit late and not lining up or something.  So it is possible there will be a newer version of this song at some point.

Edit


Improvement!

Video:
https://youtu.be/fJgGvajrtaM

Files:
https://sites.google.com/site/benboldt2/files/ff_namcot_dungeon_v2.zip

18
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: February 11, 2018, 02:52:07 pm »
I think I have dungeon done now:

Video:
https://youtu.be/ZIDmL-Y3vtk

Files:
https://sites.google.com/site/benboldt2/files/ff_namcot_dungeon.zip

I used the triangle channel in an interesting way in this song.

19
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: January 27, 2018, 06:13:52 pm »

20
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: December 11, 2017, 07:36:16 pm »
I added a few notes, let me know what you think of this and any other recommendations, or even if you like it better to be more true to the original without this extra part.

https://sites.google.com/site/benboldt2/files/ff_namcot_menu_v3.mp3

Edit:
Honestly, I do think I will stick with the original without any of this extra stuff.  It has not turned out at all the way that I expected.

I'm not sure what I felt when I did the modification to the menu music; I think mostly I was just plugging in notes, and that's pretty much what it ended up sounding like.

If you or anyone have any ideas or example remixes of this song that make more sense, please let me know!

Pages: [1] 2 3 4