Romhacking.net

Romhacking => Programming => Topic started by: justin3009 on March 26, 2012, 10:28:05 pm

Title: Mega Man X3 menu hacking
Post by: justin3009 on March 26, 2012, 10:28:05 pm
I've been looking at Mega Man X3 still, of course, but I'm beginning to wonder now as it'd save a lot more time and be essentially much easier to be flexible in the future?

How difficult would it be to convert a password system to saving in SRAM and such?  Is that even feasible?
Title: Re: Question on Game Saving
Post by: Ryusui on March 26, 2012, 10:33:47 pm
Well, for a start, you'd need to reconfigure the header or whatever to indicate it uses SRAM in the first place.

The easy way I can think of would be to simply skip over the password screens and replace them with a routine that saves the relevant data to SRAM. The password entry screen would similarly simply load the saved data. There'd be only one save slot, of course, but it should be doable without having to code any new interfaces or whatnot.
Title: Re: Question on Game Saving
Post by: justin3009 on March 26, 2012, 10:52:02 pm
Quote
Well, for a start, you'd need to reconfigure the header or whatever to indicate it uses SRAM in the first place.
- I'll have to figure that out.  I think it has at least something because it seems to save the latest password whenever you reset the game, or at least from what I've seen.

Quote
The easy way I can think of would be to simply skip over the password screens and replace them with a routine that saves the relevant data to SRAM. The password entry screen would similarly simply load the saved data. There'd be only one save slot, of course, but it should be doable without having to code any new interfaces or whatnot.

The password screen essentially only loads up data, that's really about it.  Even one save slot would be 100% perfect.  I think the only difficult spot would be trying to figure out how to store things to SRAM.  I think once I can figure that out, the rest should somewhat fall into place since it'll just be heavy memory loading which can probably be used with MVN's and such.. or at least I think so.
Title: Re: Question on Game Saving
Post by: Ryusui on March 26, 2012, 11:53:09 pm
- I'll have to figure that out.  I think it has at least something because it seems to save the latest password whenever you reset the game, or at least from what I've seen.

Soft reset doesn't blank the memory. X-Men 2 for Sega Genesis has a part where you need to reset a computer, and resetting the console is how you proceed.
Title: Re: Question on Game Saving
Post by: justin3009 on March 27, 2012, 11:30:51 am
Ah okay, that makes sense there at least.

Is there any documents that could essentially help start studying storage to SRAM?  I've looked at a couple of things that helped explain it (The basics of it all which I already knew of) and that's about it.  Unless I'm missing something.

If not, would I just have to study another game to see how it stores it?
Title: Re: Question on Game Saving
Post by: henke37 on March 27, 2012, 04:51:54 pm
SRAM is pretty simple in theory. You simply have a pile of bytes that are retained between runs. You may need to lock and unlock the area, but other than that, it is just another pile of bytes.
Title: Re: Question on Game Saving
Post by: justin3009 on March 27, 2012, 05:46:11 pm
That I can understand, it's just how does one go about storing and loading data from SRAM?  What exactly dictates to do that?
Title: Re: Question on Game Saving
Post by: KingMike on March 27, 2012, 07:02:41 pm
Well, what I have done is... when the game displays a password, read the password data and store to SRAM.
When the password entry screen appears, instead of loading default data, load the saved data into the password data (essentially auto-entering the saved data as the currently-input password). (such that one needs to simply press Start on the password screen to continue with the saved data.)
Actually, I took the idea from the GBA port of NES Metroid, which allows you to have the game "remember" one password in the game's save memory.
Might be a bit trickier if you want the game to actually display the saved password, if the initial display (with the default password) is hard-coded.
Title: Re: Question on Game Saving
Post by: justin3009 on March 27, 2012, 08:06:18 pm
I had that in mind, or at least having just one giant save being presented that dictates what weapons you have, how many heart pieces, what armor pieces, what chip pieces, the basic general stuff.  There's not much information to display for a Mega Man game.

What actually dictates the game to store and load from SRAM though?  What would it even look like for ASM wise?

Edit: So I went through and did a log for Tales of Phantasia.

Code: [Select]
$C2/53DA 08          PHP                     A:0000 X:2000 Y:0006 P:envMxdiZc
$C2/53DB DA          PHX                     A:0000 X:2000 Y:0006 P:envMxdiZc
$C2/53DC E2 20       SEP #$20                A:0000 X:2000 Y:0006 P:envMxdiZc
$C2/53DE BD 35 00    LDA $0035,x[$7E:2035]   A:0000 X:2000 Y:0006 P:envMxdiZc - What save you're on.
$C2/53E1 8F 0D 7F B0 STA $B07F0D[$B0:7F0D]   A:0000 X:2000 Y:0006 P:envMxdiZc - Stores in SRAM what save slot is latest.
$C2/53E5 22 3B E5 C0 JSL $C0E53B[$C0:E53B]   A:0000 X:2000 Y:0006 P:envMxdiZc

Code: [Select]
$C0/E53B 08          PHP                     A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E53C 8B          PHB                     A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E53D DA          PHX                     A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E53E 5A          PHY                     A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E53F E2 20       SEP #$20                A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E541 85 0E       STA $0E    [$00:000E]   A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E543 A9 7E       LDA #$7E                A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E545 48          PHA                     A:007E X:2000 Y:0006 P:envMxdizc
$C0/E546 AB          PLB                     A:007E X:2000 Y:0006 P:envMxdizc
$C0/E547 64 0C       STZ $0C    [$00:000C]   A:007E X:2000 Y:0006 P:envMxdizc
$C0/E549 C2 20       REP #$20                A:007E X:2000 Y:0006 P:envMxdizc
$C0/E54B A9 00 0A    LDA #$0A00              A:007E X:2000 Y:0006 P:envmxdizc
$C0/E54E E2 20       SEP #$20                A:0A00 X:2000 Y:0006 P:envmxdizc
$C0/E550 8F 1B 21 00 STA $00211B[$00:211B]   A:0A00 X:2000 Y:0006 P:envMxdizc
$C0/E554 EB          XBA                     A:0A00 X:2000 Y:0006 P:envMxdizc
$C0/E555 8F 1B 21 00 STA $00211B[$00:211B]   A:000A X:2000 Y:0006 P:envMxdizc
$C0/E559 A5 0E       LDA $0E    [$00:000E]   A:000A X:2000 Y:0006 P:envMxdizc
$C0/E55B 8F 1C 21 00 STA $00211C[$00:211C]   A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E55F 8F 1C 21 00 STA $00211C[$00:211C]   A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E563 C2 20       REP #$20                A:0000 X:2000 Y:0006 P:envMxdiZc
$C0/E565 AF 34 21 00 LDA $002134[$00:2134]   A:0000 X:2000 Y:0006 P:envmxdiZc
$C0/E569 18          CLC                     A:0000 X:2000 Y:0006 P:envmxdiZc
$C0/E56A 69 00 61    ADC #$6100              A:0000 X:2000 Y:0006 P:envmxdiZc
$C0/E56D AA          TAX                     A:6100 X:2000 Y:0006 P:envmxdizc
$C0/E56E 86 1C       STX $1C    [$00:001C]   A:6100 X:6100 Y:0006 P:envmxdizc
$C0/E570 AF F1 E8 C0 LDA $C0E8F1[$C0:E8F1]   A:6100 X:6100 Y:0006 P:envmxdizc
$C0/E574 9F 00 00 B0 STA $B00000,x[$B0:6100] A:6154 X:6100 Y:0006 P:envmxdizc
$C0/E578 AF F3 E8 C0 LDA $C0E8F3[$C0:E8F3]   A:6154 X:6100 Y:0006 P:envmxdizc
$C0/E57C 9F 02 00 B0 STA $B00002,x[$B0:6102] A:656C X:6100 Y:0006 P:envmxdizc
$C0/E580 E2 20       SEP #$20                A:656C X:6100 Y:0006 P:envmxdizc
- I haven't really checked much but B06100 or rather just "100" is the offset location in SRAM where it starts storing names and what not.  So I assume I can do something similar like this in Mega Man but I may need a little more help.  Essentially though, Mega Man is a whole ton easier since it doesn't have to record storyline points exactly, levels, characters, etc..  Just weapons, heart tanks, the very very basic stuff which takes little to absolutely no room.

I may need some help to get started on this though.

Edit: Definitely for starters, I'm trying to figure out how the game dictates if it uses an SRAM or not.  I'm assuming that code loads right away as the game starts but I'm not even sure ._.  Any pointers on this?

Edit 2: Got it.  FFD8 was 00 originally.  Changed it to 01 and the game now creates an SRAM file 2KB in size which should be more than enough room.  Had a little help to figure it out but he gave me the SNES Dev docs so that helped more.

Edit 3: GOT IT!  I figured out how to store and load from SRAM as well.  70:0100 is offset 100 in SRAM.  I stored 40 there for a weapon test value and it works absolutely flawlessly ;3
Title: Mega Man X3 menu hacking
Post by: justin3009 on April 02, 2012, 12:02:50 pm
So I'm testing out some things with seeing if I can make other sprites appear on the screen for purposes that I need and this is what happens.

(http://i44.tinypic.com/abh5ih.png) - Nothing appears.. at all on SNES9X.

Yet when you go to ZSNES.

(http://i40.tinypic.com/34diw5s.png) - It appears ~_~...

I'm going to assume this is another one of those screwed up emulator issues that's between SNES9X and ZSNES but I want to be sure on it.

Edit: This same thing happens with any other sprite on the screen.
Edit 2: It seems to even happen with things that are on BG Layer 1 and 2.  I'm not sure why it'd work on ZSNES but not SNES9X..
Title: Re: Is this another emulator issue...
Post by: Ryusui on April 02, 2012, 12:48:42 pm
Try BSNES if you can. That's the acid test if something's screwing up.

It's not only the only emulator I know of that can render the Cathedral of Shadows in SMT1 without glitching, it's also accurate enough that it triggers the anti-repro message in the Breath of Fire 2 retrans.

EDIT: Thinking about it, are you updating the OAM during VBlank? If that sentence was Greek to you, I suggest you do a bit more research before you continue.
Title: Re: Is this another emulator issue...
Post by: justin3009 on April 02, 2012, 12:53:07 pm
BSNES doesn't work at all now since the SRAM thing was implemented.  So I'm rather.. stuck with what I have right now.

And most likely not.  I've tried doing research on such things but all it does is cause more confusion.

Edit: Yikes, those numbers are actually Layer 2.  Any Layer 1-2 and sprites don't appear on SNES9X when adding them in manually.  Guessing that still means I should V-Blank?

Edit 2: Figured it out!  Stored 80 to 8D 00 21 (6:2100) and then it shows up in SNES9X :3
Title: Mega Man X3 menu hacking
Post by: justin3009 on April 03, 2012, 02:30:27 pm
I've been futzing around with this for awhile, even before saving was working and I am just completely baffled.  This same thing occurs in Tales of Phantasia and I can't really seem to figure out what causes it or why it does it.  Changing really anything around the tile data itself causes the menu to blow up with scrambled data, so I'm left clueless on any idea why it happens.

(http://i39.tinypic.com/evdroz.png) - This is how I have it right now without really anything.
(http://i43.tinypic.com/2ikwrpj.png) - Alter one tile map byte and it does it in four places.

I've gone through the code and watched it loop and I really don't see anything to indicate why it loops :/  I'm really confused.

http://pastebin.com/Jk86dex1 - This is basically the code that sets everything up.  The first bytes load up normally but then it hits special tiles that are used everywhere and it repeats them throughout the screen.  I have no clue HOW to break that sequence or what even causes it.  I assume it's one of the bytes that destroys the game screen when altered but I'm unsure.

Example: Go to 23F807.  You should see 38 E9 84.  Alter E9 to E8.  It'll change the 4 tiles you see in the screenshots.  84 is the direction.  Upside down, horizontal, etc..  I'm guessing 38 is what has something to do with it.  If not, then maybe 80 11.  Either way, I can't alter any of it without the game going crazy.
Title: Re: Horribly Confused About Tile Placement
Post by: Ryusui on April 03, 2012, 03:34:32 pm
My recommendation? Take a hatchet to as much of the code as possible and create your own. Instead of leaving the precise drawing details to a routine that was designed to construct something completely different, create a routine designed specifically to draw your custom save screen.

By the way, I'm already impressed with how much you've gotten done. :3
Title: Re: Horribly Confused About Tile Placement
Post by: justin3009 on April 03, 2012, 07:01:35 pm
-_-... I didn't even think of that until you mentioned it.  The most simple solutions always avoid me xD;

I'm using a really ugly cheap method for right now, but I'm actually thinking about a new system for certain screens that could essentially be more dynamic, heck, maybe a whole new routine!   But for now, I'm doing the cheap method of storing individual tile errors into the right area.  Except when it comes to repeated tiles, then I just loop them.

I might see if I can put in a new routine to have a table that reads the tile, then the value after is how many times it goes through the loop to write it.  I'll test that out later after I have the menu look ready.
Title: Re: Horribly Confused About Tile Placement
Post by: Mauron on April 04, 2012, 03:25:55 am
In the current situation, $00:00FE is used for the looping - 8 is loaded in there at first, and it's decremented twice per loop.
Title: Refreshing BG Layers? (Rather, the screen?)
Post by: justin3009 on April 04, 2012, 11:04:21 am
I've been posting a horde of questions lately but it's mainly due to the save screen I'm working on >.< So sorry about all the spam.

Okay so, I'm lost on what to do to refresh the actual screen to remove data that isn't there.  I've actually tried having a separate routine to blank out the data with other junk but.. it doesn't work that way.

(http://i41.tinypic.com/107ly77.png) - Here's what it shows.  The darkened data means you do not have the item.
(http://i43.tinypic.com/6sqhqh.png) - Slot 3 is literally empty.  There is no data at all present and it even ignores the entire routine so it doesn't write to the screen.  I'm not sure what to do to refresh or anything so it doesn't show the data.

What I plan to do is for the entire screen to blank out of data and just say 'NO DATA AVAILABLE' as text but I can't even remove anything off the screen >.<
Title: Re: Refreshing BG Layers? (Rather, the screen?)
Post by: Ryusui on April 04, 2012, 12:05:11 pm
Okay, what do you mean by "blank out the data with other junk"? One way or another, you're going to have to blank out that data in order to clear the screen.

Just overwrite it all with blank tiles. Redraw the entire menu if you have to. (And by the way, looking good! Is there any way to simply make the uncollected weapons not show, though? That's what the later games do.)
Title: Re: Refreshing BG Layers? (Rather, the screen?)
Post by: justin3009 on April 04, 2012, 01:10:04 pm
I feared as much >.<  It's getting tedious as hell to write a horde of similar routines just to blank out data on certain circumstances. 

Drawing the menu again would be the best way to go about it but the game instantly crashes if that data is even attempted to be loaded again.  I probably have to set something for it to work again.  That'd actually fix everything if I could load that data again instead of having like 300 different things trying to blank it out.

Essentially I could have the icons just not appear but I'd have to blank out the data either way.

Edit: Well, found a way to... semi re-draw the whole menu but it lags like crazy for a second then flickers xD;  I'm guessing that's unavoidable.  I may have to go the routine way.

Edit 2: -_-.. derp.  I'm an idiot.  Just have the routine for blanking the tiles show up everytime you move the cursor.. Voila.
Title: Re: Refreshing BG Layers? (Rather, the screen?)
Post by: Nightcrawler on April 04, 2012, 01:30:11 pm
'Erasing' is simply a tilemap issue. All you need to do is a write a single value (pointing to a blank green menu tile) to the tilemap area that you want to erase. A single loop can do it. It can't possibly be slow. If you write a simple routine to blank the tilemap, you'd reuse this every time you switch save spots. I think you're over-complicating the situation.
Title: Re: Mega Man X3 menu hacking
Post by: KingMike on April 04, 2012, 02:46:17 pm
Since these topics seem to be about the same thing, I merged them.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 04, 2012, 03:10:02 pm
Edit: ...I just found a better way -_-  I was looking this morning and I found a way to redraw every single tile.

Edit 2: I've ran into another problem.

(http://i40.tinypic.com/25zot94.png) - This is how it appears in Slot 1 thus far.  Works nicely.
(http://i41.tinypic.com/33nviar.png) - This is what happens when you scroll over to Slot 2 or more.

I'm very confused by this as the text and ride chips are CONSISTENTLY being written to screen much like everything else yet they just disappear when the tiles are rewritten.  Why would they not appear again even though the screens being constantly written to?  Also, this works on ZSNES just fine but not SNES9X.  These emulator discrepancies are getting on my nerves.

Also to clarify a bit more, the tile rewriting only occurs when you increase the save slot.  Otherwise it's not always happening.  So this is rather strange.  I would mimic the way the weapon icons and sub-tanks are written but there's no more room in VRAM for that.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 10, 2012, 05:54:32 pm
I've been able to fix that issue for the most part.  The issue now is that I'm having horrible issues keeping the X/Zero sprite on screen.  It overwrites text and even the lives get cut off, sometimes ride chips and such.  I'm just completely lost on how to fix half of this >.<
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.

Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 10, 2012, 10:20:50 pm
As far as I know the NMI is disabled, but I can take a look and check to see if it is.  If so, as you said, that's probably what's screwing me over.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 11, 2012, 04:33:19 pm
That doesn't seem to do anything to help, sadly.  Nothing changes at all.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 11, 2012, 09:19:07 pm
I believe the game essentially already does that in order to redraw the tiles when moving to a new save slot.

And it's possibly something with that but each sprite is stored into a new area so I'm unsure what's going on.  I'd check a savestate with ZSNES but it works flawlessly there and BSNES insta crashes because of SRAM being there >.<
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 12, 2012, 07:19:53 pm
The only sprites on screen are X and/or Zero along with the 4 password numbers.  Everything else is purely background layer.  It just screws up when X/Zero appear on screen and it erases everything on the background practically.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 13, 2012, 07:54:13 am
I've gone through most of the code and it seems to come from a specific area.  I'll have to go through the code again sometime once I'm done copying data over to my new compy.  All i know is that Zero, for some reason, erases less data than X which is extremely odd.

Edit: If not.  I'll copy/paste each routine that it uses into pastebin or something and designate what each part does so there's a full idea of what's going on.
Title: Re: Mega Man X3 menu hacking
Post by: kuja killer on April 13, 2012, 11:14:17 am
sorry for being so late to even read this post for the first time, but i do believe you'll defintely be able to make a whole save-game system

I did it for my megaman 3 hack, odyssey...exactly what you described in the beginning...about replacing the whole entire password stuff, with a custom built save-game system from ground up scratch. I basically just completely tore down the whole password system in the rom, every possible trace of code related to it in any way, and did everything myself when making my save screen/system.

dont know if you've seen it before, anyway im sure you'll succeed with yours. :)
The box at the top is the main status box which will display about 20 different messages for whatever the case may be, hehe. :P "select file, data loaded, file deleted, please wait, etc. :P
(http://i41.tinypic.com/eg4tiv.png)(http://i39.tinypic.com/14aj6n8.png)
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 13, 2012, 11:51:49 am
Well.. this is.. interesting.  I copied everything over to my new computer that just came yesterday and tested it out again.  The only thing that's wrong now is some of the Ride Chips get removed and the lives.  Everything else works fine O_o.  This is incredibly odd.  But this gives me new hope in possibly fixing these bugs.  I'm going to track through the code.  If I'm still having issues, I'll post the entire loop of what everything does with it labeled.

Edit: http://pastebin.com/kN7LKjkM - Run through of the entire code.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 06, 2012, 11:24:16 pm
It semi worked.  X was missing massive chunks of his sprites though with a constant black line through the screen.  I must seriously be effing this code up.

Edit: I'm starting to think it's probably a better idea to NOT have the screen consistently being written to.  Maybe have it written to once on start-up then have it only done so once more when you move save slots.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 14, 2012, 12:07:55 pm
Alright, another issue has come up.  I've removed the entirety of the screen being written to constantly except for the sprites (That's a gimme).

Now it's doing what it did before.  You move over a slot, it literally erases everything off the screen except for the weapons/sub-tanks.  You CAN see them flash though just as you move over though.  I'm not sure why they'd randomly erase again since nothing else is being written to it.  Kind of confuses me.

Edit: An interesting note though.  If X's sprite decides to write correctly to the screen, nothing gets erased off screen except for Ride Chips/Lives.  Right now it has a chance to load correctly.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla 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.
Title: Re: Mega Man X3 menu hacking
Post by: justin3009 on April 14, 2012, 03:20:52 pm
Well, it semi works.  It fixes the lives/ride chips not fully appearing.  Either way, they still flash in and out without being written back onto the screen.  I'm unaware why it does this.
Title: Re: Mega Man X3 menu hacking
Post by: MottZilla on April 14, 2012, 04:51:42 pm
I sent you a message. Hopefully you received it as I was in a hurry.