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 - MottZilla

Pages: [1] 2
1
Personal Projects / Re: Ultimate Mortal Kombat 3 hack [smd]
« on: May 27, 2012, 02:05:57 pm »
I remember renting UMK3 back in the day and was hugely disappointed by everything the designers took out.  How do you make a conversion of Ultimate Mortal Kombat that's less ultimate than Mortal Kombat 3?  Midway found a way.

To be fair it was not their fault. Understand that ROM memory cost alot of money. The game was already using up a 32 megabit ROM with Mortal Kombat 3. Then they needed to add new stages and new characters. They just didn't have the room so they had to cut out what they could. If they had bumped up the amount of ROM used they could have avoided the cuts but it would also have made the game more expensive to produce and either less profitable or more expensive to the consumer and perhaps if more expensive it would sell less and again be less profitable. This is the same case with the SNES version.

Atleast it's here now though right?

2
Personal Projects / Re: Ultimate Mortal Kombat 3 hack [smd]
« on: May 01, 2012, 01:21:11 pm »
Awesome. Nice to see this done.

3
Newcomer's Board / Re: Mega Man X Debug Menu
« on: April 21, 2012, 01:27:04 pm »
Press L+X+A (all 3 buttons at held at once) during gameplay. Not while the game is paused, not in the main menu, not in the stage select. Be sure you applied the IPS patch correctly.

The CRC32 after applying the patch should be 6F040068. ZSNES and SNES9X will display the CRC32 value when loading games along with other information.

If your CRC32 value matches and you still can't bring up the menu, check that your controller and all buttons are working properly. And yes it is a *real* hack.

4
Programming / Re: Mega Man X3 menu hacking
« on: April 14, 2012, 04:51:42 pm »
I sent you a message. Hopefully you received it as I was in a hurry.

5
Programming / Re: Mega Man X3 menu hacking
« on: April 14, 2012, 02:27:42 pm »
You didn't say but you could try inserting the loop I told you before writing various things to the screen.

- LDA $4210
BPL -

If you do, it *should* wait until you are in the safe time to write to the PPU. Maybe you really are just running out of time. Actually thinking right now, how are you throttling your loop? Do you have a loop similar to what I posted? Or does it run without any throttling? If it runs without any throttling it is no wonder you have it so "sometimes" it works but most of the time it doesn't. If it is that way, the time at which you write to the screen is totally random. You must only write during vblank or force blank. If you write at any other time writes are either ignored or will corrupt VRAM.

Try adding this right here:
$00/F085 C2 20       REP #$20   

Add before this:
- LDA $4210
BPL -
- LDA $4210
BPL -

This will wait for the VLANK flag to be set, twice, just incase it catches VBLANK late. This will give the best case scenario on time to write to the PPU through this code segment you posted. This could fix all your issues.

If this doesn't fix your issues, you can add this loop before other writes to the PPU to again make sure you write at the safe time, but I don't think you'll need it anywhere but the beginning of your writing/update.

6
Programming / Re: Mega Man X3 menu hacking
« on: April 01, 2012, 05:42:43 pm »
You definitely shouldn't write to the screen more than required. And you need to be sure that you are writing to the PPU at the correct time. If you do not use NMI, you need to loop reading the appropriate register, $4210 I believe.

Basically do a loop like
- lda $4210
bpl -

And it will loop until the NMI/VBlank flag is set. However you might want to consider that you could be catching the VBlank peroid late. In this case, do two loops of the same thing to be sure you have the maximum amount of time to write to the PPU.

When you first start the password screen turn off the display with $2100. Write all the constant background tiles first and then worry about what needs to be updated. You can't have that much to update so it shouldn't be a problem fitting that into the VBlank period. But you may have problems if you are both calculating changes and writing to the PPU at the same time, but don't worry about that unless you have problems.

7
Programming / Re: Mega Man X3 menu hacking
« on: April 13, 2012, 02:39:19 pm »
I'm not sure if you left anything out, but by looking through the code and hearing that Zero and X disappear different things, it sounds to me like you are writing out of VBlank. Did you try writing #$80 to $2100 to put the PPU in force blanking mode before writing to $2116 and $2118 etc?

Just force blank before any writing to the PPU and then write #$0F to $2100 when you are done. This isn't what you'll want to do in the finished code, but it should prevent some things from not being drawn and such.

8
Programming / Re: Mega Man X3 menu hacking
« on: April 13, 2012, 02:26:13 am »
Ok, so how are you transferring data then? If you're using DMA, particularly the same channel, are you making sure you are initializing everything for sprite ram transfers and then VRAM transfers?

It's unfortunately difficult to guess what could be wrong without seeing the actual code. But you can always try to comment out pieces and try to narrow down where the problem is occurring.

9
Programming / Re: Mega Man X3 menu hacking
« on: April 12, 2012, 02:24:03 pm »
What exactly is sprites and what is the background layers?

Are the disappearing text bits BG or sprites? I'm sure you can figure this out. When developing my BS-Zelda patch there were times where something just didn't work right and I didn't see why. Usually it was just some silly mistake from being so tired.

10
Programming / Re: Mega Man X3 menu hacking
« on: April 11, 2012, 08:38:28 pm »
How are you drawing to the screen anyway? Try this, before drawing, turn off the screen. When all drawing is done, turn the screen on again. Just write #$80 to $2100 to force blank and #$00 when you are done. See if that doesn't atleast get the background updating properly.

If you are using sprites be sure nothing could be trashing or messing up OAM/Sprite RAM.

11
Programming / Re: Mega Man X3 menu hacking
« on: April 11, 2012, 12:45:10 am »
NMI enable is bit7 of $4200. If you need auto-joypad reading just write #$01 to $4200 or write #$00 if you don't. IRQ enable is also in this register but I doubt you are using IRQs for anything. I hope it is something as simple as not disabling NMI that is your problem.

12
Programming / Re: Mega Man X3 menu hacking
« on: April 10, 2012, 09:12:49 pm »
How exactly, is your new menu running? Are you utilizing the NMI program/update system the game has in place already or are you doing it entirely yourself? On the SNES you actually could just avoid NMI, just turn it off, and just use looped waits for running your menu. If NMI is enabled and you aren't actually interacting with it maybe it keeps updating things in NMI and messing up what you are trying to do.


13
Programming / Re: Mega Man X3 menu hacking
« on: April 10, 2012, 03:07:40 pm »
Did you check the order in which you are drawing tiles? By the way BSNES probably doesn't work because it won't map SRAM to Cx4 games most likely.

You could "test" with BSNES if you can use some upper WorkRAM instead of SRAM. If the game never touches the end of WRAM (7FFFFF) then see if you can fit your save data there to test with BSNES maybe.

Your idea looks very nice. I hope you can manage to implement it. But you might want to have two versions, one password and one SRAM. Incase of compatibility issues.

14
Keep working on it. It's a good project. And an iconic game.

15
Personal Projects / Re: Megaman 1 for PC-Engine upgrade/hack
« on: March 09, 2012, 03:38:09 pm »
He did not ever say the PCEFX. Just the regular old PC-Engine.

16
Apparently the SD2SNES progress update says it fixed the problem so perhaps the emulator is at fault and not you. http://sd2snes.de/blog/

17
Personal Projects / Re: Mega Man X3 - Fully Playable Zero [ Complete! ]
« on: February 26, 2012, 12:24:07 pm »
It's possible but I'm not doing any major modifications until later on.  Right now I just want it to be a stable game that has as few as bugs as possible while staying close to X3 as possible.

Do you plan to try to fix the bugs that break compatibility with BSNES and real hardware?

18
Personal Projects / Re: Mega Man X3 - Fully Playable Zero [ Complete! ]
« on: February 14, 2012, 06:06:03 pm »
Curious, what exactly did you do that breaks the hack on real hardware/accurate emulators or do you not know exactly?

19
Newcomer's Board / Re: How to find code for no clipping/walk thru walls?
« on: January 18, 2012, 03:57:55 pm »
If you are using an emulator you can modify RAM values that contain your position on the map to move into areas you cannot reach normally. The problem with your walk through walls codes is that you need to know exactly why the code allows that, which means you must understand the ASM code that is changed.

20
Newcomer's Board / Re: SNES SRM Checksums
« on: January 13, 2012, 01:25:51 pm »
Unfortunately I couldn't find the source code for my Final Fantasy 4 Wonderswan SRAM editor. CRC probably is not used. It is likely a 16bit checksum which may be byte or word related. The easiest way to determine is to just save two files in a row if it keeps track of the # of saves. This way all the data should be the same except that one field. You can compare the resulting data and use various checksum generators on them to quickly see if its just an 8bit checksum or 16bit. It might be slightly different just depending on their exact code so you might have to write something yourself. Too bad I don't have the source around since they may use the same method.

Edit:
I checked for you. It's a 16-bit checksum with carry. It's a function at $C2/F588. Holds the checksums in the upper part of SRAM too. Shouldn't be too hard to figure out generating your own checksums to modify data freely. Just change the data, $600 bytes, generate the 16bit LSB Adding Checksum with Carry, write it in the Checksum Storage at 1FF0,X.


January 19, 2012, 06:06:39 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I compiled my notes into a document. Hopefully it will help you with whatever you are doing. http://www.romhacking.net/documents/627/

Pages: [1] 2