News: 11 March 2016 - Forum Rules

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

Pages: 1 [2] 3 4
Programming / x6502 Ricoh 2A03 Disassembler
« on: September 04, 2015, 04:15:34 pm »
x6502 is a simple commandline utility used to disassemble PRG ROM data from a NES video game.

I developed this application in order to help myself understand how 6502 processing works for the NES so that I may move on from PSone hacking. I'm not sure what the point is, but I've already laid the groundwork for 6502->R3000A conversion, as well. Furthermore, I may add a GUI in the future if I get bored enough.

Disassembled output can be used in a variety of assemblers, though it was particularly developed with Disch's "Schasm" assembler in-mind.

I'm fairly new to 6502 hacking, so don't hesitate to point out any errors.


EDIT: (Sept 05, 2015)

Version 1.1 is now available with two new optional commands.

The first optional command, label, will implement labels for each JMP, branch type and sub-routine. With this option, these address pointers are no longer hardcoded.

The second optional command, comment, will automatically add two semi-colons on each line for future commenting.

EDIT: (Sept 06, 2015)

Version 1.2 is now available with three new optional commands and a few minor bug fixes.

DATA will disassemble to #byte.

APPEND will open an existing file and append disassembly to the end of the file. Useful for Text+Data disassembly output.

ADDRESS adds commented file addresses and counters to each line.

Example output from Mega Man 3
Code: [Select]
#org $C4F8, $0003C508 ;;
LDX #$00 ;; C4F8 0003C508 ;;
STX $0019 ;; C4FA 0003C50A ;;
BRANCHC4FC: LDA $0780,X ;; C4FC 0003C50C ;;
BMI BRANCHC51C ;; C4FF 0003C50F ;;
STA $2006 ;; C501 0003C511 ;;
LDA $0781,X ;; C504 0003C514 ;;
STA $2006 ;; C507 0003C517 ;;
LDY $0782,X ;; C50A 0003C51A ;;
BRANCHC50D: LDA $0783,X ;; C50D 0003C51D ;;
STA $2007 ;; C510 0003C520 ;;
INX ;; C513 0003C523 ;;
DEY ;; C514 0003C524 ;;
BPL BRANCHC50D ;; C515 0003C525 ;;
INX ;; C517 0003C527 ;;
INX ;; C518 0003C528 ;;
INX ;; C519 0003C529 ;;
BNE BRANCHC4FC ;; C51A 0003C52A ;;
BRANCHC51C: RTS ;; C51C 0003C52C ;;

#org $C6D8, $0003C6E8, $74 ;;
#byte $58 ;; C6D8 0003C6E8 ;;
#byte $F1 ;; C6D9 0003C6E9 ;;
#byte $02 ;; C6DA 0003C6EA ;;
#byte $28 ;; C6DB 0003C6EB ;;
#byte $E0 ;; C6DC 0003C6EC ;;
#byte $F1 ;; C6DD 0003C6ED ;;
#byte $02 ;; C6DE 0003C6EE ;;
#byte $28 ;; C6DF 0003C6EF ;;
#byte $B8 ;; C6E0 0003C6F0 ;;
#byte $F1 ;; C6E1 0003C6F1 ;;
#byte $02 ;; C6E2 0003C6F2 ;;
#byte $70 ;; C6E3 0003C6F3 ;;
#byte $20 ;; C6E4 0003C6F4 ;;
#byte $F1 ;; C6E5 0003C6F5 ;;
#byte $02 ;; C6E6 0003C6F6 ;;
#byte $A0 ;; C6E7 0003C6F7 ;;
#byte $68 ;; C6E8 0003C6F8 ;;
#byte $F1 ;; C6E9 0003C6F9 ;;
#byte $02 ;; C6EA 0003C6FA ;;
#byte $D0 ;; C6EB 0003C6FB ;;
#byte $D8 ;; C6EC 0003C6FC ;;
#byte $F1 ;; C6ED 0003C6FD ;;
#byte $02 ;; C6EE 0003C6FE ;;
#byte $D0 ;; C6EF 0003C6FF ;;
#byte $90 ;; C6F0 0003C700 ;;
#byte $F2 ;; C6F1 0003C701 ;;
#byte $02 ;; C6F2 0003C702 ;;
#byte $10 ;; C6F3 0003C703 ;;
#byte $40 ;; C6F4 0003C704 ;;
#byte $F2 ;; C6F5 0003C705 ;;
#byte $02 ;; C6F6 0003C706 ;;
#byte $58 ;; C6F7 0003C707 ;;
#byte $D0 ;; C6F8 0003C708 ;;
#byte $F2 ;; C6F9 0003C709 ;;
#byte $02 ;; C6FA 0003C70A ;;
#byte $58 ;; C6FB 0003C70B ;;
#byte $78 ;; C6FC 0003C70C ;;
#byte $F2 ;; C6FD 0003C70D ;;
#byte $02 ;; C6FE 0003C70E ;;
#byte $80 ;; C6FF 0003C70F ;;
#byte $28 ;; C700 0003C710 ;;
#byte $F2 ;; C701 0003C711 ;;
#byte $02 ;; C702 0003C712 ;;
#byte $D8 ;; C703 0003C713 ;;
#byte $A8 ;; C704 0003C714 ;;
#byte $F2 ;; C705 0003C715 ;;
#byte $02 ;; C706 0003C716 ;;
#byte $D8 ;; C707 0003C717 ;;
#byte $90 ;; C708 0003C718 ;;
#byte $E4 ;; C709 0003C719 ;;
#byte $03 ;; C70A 0003C71A ;;
#byte $18 ;; C70B 0003C71B ;;
#byte $28 ;; C70C 0003C71C ;;
#byte $E4 ;; C70D 0003C71D ;;
#byte $03 ;; C70E 0003C71E ;;
#byte $20 ;; C70F 0003C71F ;;
#byte $68 ;; C710 0003C720 ;;
#byte $E4 ;; C711 0003C721 ;;
#byte $03 ;; C712 0003C722 ;;
#byte $30 ;; C713 0003C723 ;;
#byte $58 ;; C714 0003C724 ;;
#byte $E4 ;; C715 0003C725 ;;
#byte $03 ;; C716 0003C726 ;;
#byte $60 ;; C717 0003C727 ;;
#byte $80 ;; C718 0003C728 ;;
#byte $E4 ;; C719 0003C729 ;;
#byte $03 ;; C71A 0003C72A ;;
#byte $70 ;; C71B 0003C72B ;;
#byte $10 ;; C71C 0003C72C ;;
#byte $E4 ;; C71D 0003C72D ;;
#byte $03 ;; C71E 0003C72E ;;
#byte $98 ;; C71F 0003C72F ;;
#byte $58 ;; C720 0003C730 ;;
#byte $E4 ;; C721 0003C731 ;;
#byte $03 ;; C722 0003C732 ;;
#byte $C0 ;; C723 0003C733 ;;
#byte $80 ;; C724 0003C734 ;;
#byte $E4 ;; C725 0003C735 ;;
#byte $03 ;; C726 0003C736 ;;
#byte $D0 ;; C727 0003C737 ;;
#byte $18 ;; C728 0003C738 ;;
#byte $E4 ;; C729 0003C739 ;;
#byte $03 ;; C72A 0003C73A ;;
#byte $10 ;; C72B 0003C73B ;;
#byte $A0 ;; C72C 0003C73C ;;
#byte $E4 ;; C72D 0003C73D ;;
#byte $03 ;; C72E 0003C73E ;;
#byte $48 ;; C72F 0003C73F ;;
#byte $28 ;; C730 0003C740 ;;
#byte $E4 ;; C731 0003C741 ;;
#byte $03 ;; C732 0003C742 ;;
#byte $58 ;; C733 0003C743 ;;
#byte $40 ;; C734 0003C744 ;;
#byte $E4 ;; C735 0003C745 ;;
#byte $03 ;; C736 0003C746 ;;
#byte $90 ;; C737 0003C747 ;;
#byte $98 ;; C738 0003C748 ;;
#byte $E4 ;; C739 0003C749 ;;
#byte $03 ;; C73A 0003C74A ;;
#byte $A0 ;; C73B 0003C74B ;;
#byte $78 ;; C73C 0003C74C ;;
#byte $E4 ;; C73D 0003C74D ;;
#byte $03 ;; C73E 0003C74E ;;
#byte $D8 ;; C73F 0003C74F ;;
#byte $30 ;; C740 0003C750 ;;
#byte $E4 ;; C741 0003C751 ;;
#byte $03 ;; C742 0003C752 ;;
#byte $E0 ;; C743 0003C753 ;;
#byte $A0 ;; C744 0003C754 ;;
#byte $E4 ;; C745 0003C755 ;;
#byte $03 ;; C746 0003C756 ;;
#byte $E8 ;; C747 0003C757 ;;
#byte $00 ;; C748 0003C758 ;;
#byte $00 ;; C749 0003C759 ;;
#byte $00 ;; C74A 0003C75A ;;
#byte $00 ;; C74B 0003C75B ;; 

Gaming Discussion / Re: The Implications of Super Mario Maker
« on: September 03, 2015, 12:10:58 pm »
I can guess that Nintendo figures that it's time to cash in. After all, they most certainly hold that right... and in all honesty, they've created one of the most desirable level creators I've ever seen in my life. Still, it's bound by a set of standardized rules and cannot allow for any true modification - textures, programming, music and so on.

It's extremely unlikely that Nintendo will change it's stance with any of that.

Super Mario Maker will likely be seen by the casual gamer as being nothing more than a fun and creative spin on a few bundled classics. Even those who are otherwise aware are often deterred by unwillingness to learn, the amount of time it takes to completion, etc.

I'm not expecting much to change around here or anywhere else, but it's nice to think that a new wave of knowledgeable people will come. Sadly, that's almost never the case when something goes mainstream. The amount of "What's hexdecimal?" posts alone make me cringe at the thought.

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: August 30, 2015, 11:03:48 am »
Apologies for the bump, but is there any chance of a 32-bit version of this app?

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: August 22, 2015, 07:02:11 pm »
Structs:  I thought about structs and sort of dismissed them as "ehh, maybe I'll do that later."  Currently they are not supported.

Absolutely no pressure, but this would be an great feature to have.

Otherwise, keep up the excellent work!

Search for like a byte that says MessageSeen = True.

What do you guys think?


I think you've seen to many pros at work and have somehow tricked yourself into thinking stuff like this is easy. Granted, something like this wouldn't be extraordinarily difficult and can be accomplished by either GameShark or patch (no, I'm not even remotely interested in doing it), but you make it sound as if it can be accomplished in a snap with absolutely minimal to no effort.

You've got spirit kid, I'll give you that... but it wouldn't hurt to learn when you're being made fun of and mocked in these kinds situations.

Personal Projects / Re: [PS1] Resident Evil All-Stars
« on: July 03, 2015, 05:19:56 pm »
That's great that the game is going to be uncensored in your hack.

Does that mean with the engine that your using you can add the new cutscenes and the zombified Forest Spever enemy from the Director's Cut version along with the Tick enemy, the second Tyrant boss fight prior to the final battle and the Battle Game mode from the Sega Saturn version as well?

Including in the Sega Saturn version, after decapitating a crawling zombie with a kick, the head remains on the floor and the Plant 42 boss can cut the player before the game over screen.

Another neat thing you should do to your hack is restore the missing Licker Head Drop Scene they took out of Resident Evil 2:

I can very easily add, modify and/or create new cutscenes, yeah.

The Tick utilizes the Hunter AI, merely only using a different 3D model. I have a blank template to create new AI, for either enemies or players, but I unfortunately have no skills in 3D modelling and such. :/

Given that I can script the game as I please, yes, the Battle Mode is a very real possibility. In fact, I had already planned to add this (where Bio2 will retain Exbattle, The Mercs for Bio3, and an unknown mode for 1.5).

When I read "Resident Evil All-Stars", I was picturing black silhouettes of the games cast chattering with zombies casually, then lights are on and they stay there standing, not moving and staring nervously at the screen while this track (Director Cut's Mansion Basement) plays.

 :laugh: That gave me a good chuckle. Don't be surprised if something like this makes way into a later build as an easter egg xD

LMFAO I thought the same thing.  That would make for a title screen that's both form fitting and funny.

My mind's jjust been blown at the fact that I'm not only looking at a thread for a Resident Evil project, but one that contains all five (counting both discs of RE2) original games in one. 

How playable is the current build? When I'm around some decent internets I'll give it a go and see how it copes being played off a PSP. Because the only thing better than an all-in-one PS1 Resident Evil game... is an all-in-one Resident Evil game that's portable.  >:D

I had to sacrifice XA audio (spoken dialogue) and STR video (fmv cutscene) to make this possible. Specifically, I needed room on disc for the runtime data and the executable so that I could implement my code.

Resident Evil 2 is completely playable, from start to finish. However, this being a "demo" build, I only included the city area and RPD. The reason for this was specifically to cut down on ISO size, only. The other games have to be scripted, which doesn't pose much of a problem, just a matter of getting around to it.

I have ran many hardware tests, in both a regular PlayStation and PS2 fat model, both with success - I see no reason why it wouldn't work in a PSP.

Personal Projects / Re: [PS1] Resident Evil All-Stars
« on: July 02, 2015, 11:22:59 am »
I have three questions.

What version of Resident Evil 1.5 will be in the collection? I've been waiting for the IGAS Team's finished mod for this but they've been dark since December. So im curious which one this will have.

Will Jill's dodge system from 3  or auto aim be included in any of the games?

Have you thought of adding a 5th game, Like a custom version of all four games combined kinda like a  NES Remix or the Bomb collection from the N64 version of Resident evil 2? (Just a thought)

Also side note I feel like we need more ps1 Resident Evil mods.

(Just checked out the vids and the demo and I have to say I'm VERY IMPRESSED, i can't wait for this!)

The vanilla build of 1.5 that was released about a year or so ago - I don't have an unreleased version of that game, if that's what you're getting at.

Also, IGAS and Gemini are now working together to complete their version. Believe me when I say that their project is not dead, and numerous updates have surfaced since your reported blackout date - check out the main thread on this at The Horror is Alive.

Of course, though, I could script and add anything to the 1.5 section that I please, and was given permission to use very few rooms from a leaked version of IGAS work.

I have no plans to add the dodge feature from Bio3, at the moment. Quick-turn was easy to implement because the default animations could be easily tweaked to give the appearance... the dodge mechanic requires an entirely new runtime animation data, which is possible for me to accomplish, but rather tedious. Things change, though, so I'm not ruling it out completely.

Auto-aim will be included at some point, yeah. The controller layout scheme can be customized, too, I just simply didn't include the option in the demo and left it at with what I was testing (Japanese settings).

As for a fifth game, unlikely. As it is, the ISO bloats to near limit when all data from the original games are included. However, I have toyed around with the idea of joining Bio2 and Bio3 in a pseudo-like fashion, which was fun... and of course, I can always create data from scratch and just make my own game using the engine as a base (though, that'd require gathering the talent to render areas and such). Sky's the limit, and I'm just leaving the ground, so again, nothing is ruled out.

Thank you for the kind words! :)

Which version of Resident Evil 1 are you going to add to your hack, the original version or the original Director's Cut version? Will Resident Evil 1 be uncensored in your hack?

For now, just the original version.

...and of course, everything will be uncensored. Mind you, the engine and all runtime assets are pretty much putty in my hands, so I can add, remove, script, etc anything that I wish.

I may be putting out a call for some talent to join, if interested - I'd really like to see and use some custom data in this project. Specifically, scenario writers and people to create some new background prerenders and such.

Personal Projects / [PS1] Resident Evil All-Stars
« on: July 01, 2015, 08:00:09 pm »
I began working on this project roughly a year ago (codenamed "Bio Remix"), just playing around in dis/assembly, but a recent "all-in-one" Mega Man project here at RHDN inspired me to combine all PSone Resident Evil games onto one disc. There is a major difference from most "all-in-one" projects, however - all games are ran using one executable.

I did not make a executable boot loader or anything of the sort for these games, rather, converted all runtime data to be compatible with the BH2/RE2 engine.

Until about a month ago, my work was done solely on the beta version of Bio Hazard 2 / Resident Evil 2. Since that short period of time, I have ported all of my assembly work over to the USA Dual Shock version of Resident Evil 2.

Each game has it's own set of music, rooms, weapons, etc. Transition from beta to Retail Dual Shock was a bumpy ride, so very few things haven't made its way, yet. I also built many, many things from scratch, including "Quick-Turn" (used in Bio3) and a lot of runtime data for Bio 1.5.

The games included are:

Resident Evil
Resident Evil 1.5
Resident Evil 2
Resident Evil 3

My YouTube channel with gameplay videos can be found here, and a demo build can be found here.

 Resident Evil 2 Dual Shock [SLUS-00748] Complete Disassembly

Many, many thanks to KC for armips, as none of this would have been possible otherwise. Also, a huge thanks to Gemini, for teaching me much ado with PSone programming and hacking.

Programming / Re: Is MarkGrass still here ? / Fear Effect WAD files
« on: June 23, 2015, 10:04:39 am »
Here ya go:

It's commandline and doesn't support repacking, extraction only. Sorry, the source is really old and it's all that I could find.

Programming / Re: armips assembler (v0.7c released!)
« on: May 17, 2015, 10:05:34 am »
Those last too requests sound more like what a C or Cish compiler would do, not an assembler.

I like the concept of this assembler, a "patching assembler" is what I'd call it, maybe other have similar features but it seems very useful for modifying existing files. I think adding enums and structs is going too far though, that's really a compiler's work.

I absolutely agree.

...but just imagine having a 167Kb header file, full of every single structure, enumeration and variable that a certain PSone game uses, only to be be restricted to using it in a c/c++ compiler.

Granted, I could load a structure into a register and access various variables via indexing, but that would still require non-stop commenting just to know what the hell I'm working with.

It's a dumb question/request of KC, but most certainly worth asking for in my scenario.

Programming / Re: armips assembler (v0.7c released!)
« on: May 14, 2015, 12:14:38 pm »
Good idea, x0_000.

@KC - May I ask if you plan to add support for generic c/c++ struct types?

Currently, I have to convert my structs/variables to something that armips can use, but I still have 4,493 lines of structures/variables to convert. Suffice to say that it would truly be a godsend!

ROM Hacking Discussion / Re: GameCube MegaMan Anniversary Collection
« on: February 24, 2015, 09:57:02 am »
I read in the GameCube ISO-ripping scene there was a big thing about whether to leave dummy files on the disc (presumably there for loading time purposes) or to cut them/replace with more compressible dummy data)

It's still debated in minor.

In personal tests, I've completely removed all dummy padding and aligned everything into 2048 byte sectors with perfect results on real hardware (both GameCube & Wii) and of course, Dolphin.

It also worked perfectly for games with especial audio/streaming, GameBoy Player hardware & other system disc data, Action Replay (must rename 4byte ID for Wii - something like "GAME", etc), promotional & prototype disc data, and everything else I threw at it.

In few cases, I noticed that some game titles ran slightly more seamless in demanding load times, as compared to retail disc/factory pressed counterparts.

Early on during testing, however, I noticed the key is aligning everything into 2048 byte sectors, so keep that in-mind before you quote me on anything :P

News Submissions / Re: Utilities: Rainbow: texture format converter
« on: July 15, 2014, 10:54:20 pm »
Excellent utility! I'm especially looking forward to mipmap support.

...any planned support for DreamCast PV textures?

Programming / Re: IDA : naming fields
« on: July 11, 2014, 02:35:49 pm »
As I said, you can mark it as an array. This requires you to know the length of the array. In my experience IDA has been crap at guessing array lengths.

Yup, I'll second this.

Also, be on the lookout for allocation size - IDA can be crap with that, as well. Often, you may have to add padding/unused data for structs and such. Trust me when I say that this may save a lot of time.

ROM Hacking Discussion / Re: Gamecube (Wind Waker) hacking help?
« on: June 21, 2014, 11:58:33 am »
You wrote that you repacked the ARC and Yaz0 encoded it afterwards. This sounds strange. It makes not much sense to me to pack an archive with compressed files in it.


They do a bunch of hideous crap with their files. I've seen RARC archive files packed inside other RARC archive files all inside a Yaz0 compressed files. Needless to say, the files contained within the RARC archive files were Yaz0 compressed, as well.

... not sure what's going on, here, but I'll have to agree with both Dashman and henke37.

Newcomer's Board / Re: Going from gameshark code to patch?
« on: May 03, 2014, 12:48:48 pm »
This is very easy to accomplish with the help of KC's armips application.

Random example:

Code: [Select]
.open "PSX.EXE",0x8000F800

.org 0x8002C900
li $v0, 0x80 ; HP Max
sb $v0, 0x8015E283 ; RAM Location


Please note that you'll want to stick something like this into a function that is reused very often. If I need to test something like this, I'll inject it into a Controller routine, for example. Otherwise, your efforts will have been for nothing, as the value would likely get updated/erased by another function.

The syntax is incorrect. Try this:

li $t8, 0x8003E414
lw $t8, 0($t8)

Ninja'd by Revenant.

...and yes, it will work with armips.

Newcomer's Board / Re: reinserting files
« on: April 27, 2014, 03:26:21 pm »
For extracting and replacing files, I highly suggest using CDmage B5.

If you're going for a huge hack, where many files are altered, then I would suggest simply rebuilding the ISO. This can very easily be done with 'cd-tool' or Sony's 'buildcd' - I don't think buildcd works on Win7+, however.

You'll want to be on the lookout for the following issues:

1 - Games that use check sum integrity (many CAPCOM games use this). In such case, you'll need to write your own check sum calculator and insert the table into the executable before every modification, no matter how big or small. If you replace a file that undergoes check sum integrity without updating the sum value, the game will simply black-out (crash). An alternative to this is to disable the check sum integrity via r3000a dis/assembly. When/if such functionality is located, you can use KC's armips for making the necessary changes.

2 - As mentioned, games that use hard-coded LBA tables (Squaresoft, CAPCOM, etc. use this). It is generally safer, faster and easier for the original developers to use this method, compared to generic PSY-Q SDK functionality. Again, a special tool will be required for such matters. To determine if a game uses an internal LBA table, insert a file via CDmage B5 and play the game to the point where you know when the file is going to be used. If the game doesn't crash, you probably don't need to worry about this. If the game won't even boot, or if the game crashes where the file is used, chances are extremely likely that the executable utilizes an internal LBA table in addition to performing file integrity check sum.

3 - Compression isn't a linear process for PSone games - just about every game developer for every game in existence use their own compression schematics. Yet again, this will require a special tool, only you'll have to reverse-engineer the specifications via r3000a dis/assembly. In any case where you get lucky (if the game/series is popular enough), chances are likely that someone else has already written tools for the cause.

4 - Most, but not all games for the PSone use Mode2/XA formatted disc types. In any other case, modification becomes a true painstaking process where rebuilding the ISO is almost always necessary.

All said, I would suggest starting small - replace a texture or two, see how it goes and eventually work your way up from there.

ROM Hacking Discussion / Re: MegaMan 8 - Debug Menu
« on: March 29, 2014, 10:00:39 pm »

Pages: 1 [2] 3 4