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

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

Pages: [1] 2 3 4 5 6 ... 32
Newcomer's Board / Re: A little help
« on: May 25, 2018, 05:25:52 am »
I hadn't read Inverse's statement on the "Essence of ROM Hacking". Good stuff.

Wow, that actually hits the nail on the head. It definitely applies to me, too. Like how I hacked an Atari Lynx game, not necessarily because I really wanted the change that I made, but because the idea of hacking a system nobody else had hacked, WITHOUT a debugger (but with a RAM viewer), really got me going. Hackers hack because they love to hack, not because they want new levels in some platform game.

The guys in the Hack Ideas thread should read that post... :D

Newcomer's Board / Re: Tile Molester GUI Problem?
« on: May 25, 2018, 01:49:45 am »
Just to add to the topic: I'm using Windows 10 and just click TM.JAR and it works perfectly. I'm using the same copy I had on Windows 7 and Windows XP, never changed it.

No idea what could be causing this problem for the OP, though. :(

But it sounds kind of like "let's hack the original with stuff from Turbo... so we change it into Turbo". :P


Hey now, Primal, if you want to put all this stuff from Turbo into WW, you're welcome. Just not sure anyone else will do it. ;)

(now I'm wondering what's easier: adding Turbo to WW or gimping Turbo so that it's just like WW... :) )

Newcomer's Board / Re: A little help
« on: May 24, 2018, 01:57:32 am »
I'll echo the good advice already given here. The phrase "lurk more" springs to mind. I lurked plenty before my first post, where I explained how I'd already made plenty of good progress on my translation hack.

I agree that an ambiguous title helps neither you nor other forum members, and you need a specific goal in mind. For me it was simple: I want this Japanese game in English. The more specific your goal, the easier it is to help.

And yeah, making a total transformation is probably not the best first step. :)

Hexposure via a dos emulator


Just get HxD, unless you want extra hipster points for doing hex editing in DOS.

And although I'm sure Kega Fusion will do, I used Bizhawk as it has pretty good debug options, but I've yet to find the perfect debugging Genesis emulator (Mednafen and one of the mods of Gens are good too).

Regarding the addresses, those are ROM addresses. If you open the ROM in a hex editor, you can go to those addresses and find what I mentioned. I use $ to show it's hexadecimal, not decimal (some people use 0x instead).

Also, what does "converted into bin format for editing" mean? A ROM is a ROM. I just used the standard GoodGEN rip.

So I've given you the three locations I know of with Axel's name, you can mess around with that and see the results. With a bit more work, I could do it for you. :)

The countries names being called out when a plane goes there. The extra stage sound effects in the stages (I know Turbo added some of them to the end of the stage, like Dhalsim's elephants). "You WIN!" "Perfect!" Then of course, uncensoring the blood on the VS signs.

I have to admit that my memory was clearly getting muddled, as you're correct that those things are not in World Warrior. However... every one of those things was added to SF2 Turbo. Therefore, why even bother adding them to World Warrior? Turbo is clearly the improved version (you can play Champ Edition if you don't want the extra speed and moves, after all). Or better yet, play the World Warrior arcade on emulation, if you really must play World Warrior at all.

Personal Projects / Re: Dragon Warrior 1 Spanish Translation
« on: May 23, 2018, 05:38:25 pm »
what's the difference between different MMC chips

The pages on nesdev give you way more info on this than I ever could:

Suffice to say that the more advanced the chip, the more options available to the developer. MMC1 (in Dragon Warrior), for example, allows for PRG-RAM accessible between $6000 and $7FFF (what many refer to as "SRAM", though that's something of a misnomer), and two 16KB PRG-ROM banks which are either fixed or switchable. It allows the PRG-ROM to be up to 512KB, which when compared to the original 32KB is pretty substantial (incidentally, I was wrong about Donkey Kong: that used 16KB PRG, but it doesn't matter, plenty of other games used the full 32KB). It also allows for 128KB of CHR for graphics, switchable of course.

Compare to MMC5, the last official Nintendo chip, and it's even more useful. It has lots of different bank modes, with increasing granularity. The 32KB PRG bank can be swapped in and out in 8KB chunks (and can even use on-cartridge RAM instead of ROM if need be), and the 8KB CHR bank can be swapped in 1KB chunks. Both PRG and CHR have a 1MB capacity, and it even includes two pulse channels and a PCM channel to complement the existing ones in the NES, giving richer sound. The MMC5 really shows what could be done on such limited hardware when given a bit of help. Of course, as that link above shows, there are MANY other chips out there.

Hope that gives you some insight! I must say that once you get the hang of assembly, these chips are a godsend, because expansion can sometimes be as simple as I suggested earlier.

Okay, I've made a start, but there's work to be done if you want to do it how you want. :)

After reading documentation about how the Genesis's VDP works, I found that BG A and B start at $C000 and $E000 respectively in VRAM. I then looked in VRAM in Bizhawk and found Axel's name, and searched the ROM for the same bytes I saw (they were 16-bit values - two bytes - so I cut off the high byte as I assumed they wouldn't be in the ROM). This led me to find Axel's name on the selection screen at $72032 in the ROM. Beware that if you want to use a five-letter name (like Blaze) we'll have to find the instruction that tells the game to look there and change it to look elsewhere, then put the new name in that new place.

I used the same method, and discovered the name in the opening crawl at $3FCED - the table file is easy as 00 is a space and 01 upwards is the alphabet.

The name in the bio wasn't so easy to locate, but I just assumed the ROM would use the same table mentioned above for it, and it certainly did. :) You can find it at $3FA03.

I assume that's the only three locations of Axel's name in the game (unless he's mentioned in the ending, but that'll be easy enough to find). If you want to replace his name with one of the same length, now you can! :D (just remember to use Fix CheckSum if you're going to go hacking Genesis ROMs) But if you want his name to be longer, we'll need a bit more work.

Fix CheckSum:

Many loved the SNES Street Fighter games, but they were missing sound effects (Round 1 Fight!)

-Street Fighter II SNES - Add in the sound effects missing from the arcade that are present in Turbo.
-Super Street Fighter II SNES - Port in the missing sound effects from the arcade.


So which sound effects are missing? I'm pretty familiar with SF2 on both SNES and arcade, and I don't recall any missing sound effects at all.


That's the Master System. I know the OP didn't mention which system, but I would assume he meant the Genesis, no?

You know, this really doesn't sound that difficult. You're only changing a single name. You'll just need to look at the VRAM when his name comes up and use the debugger to figure out where it comes from. Granted, if you're not familiar with 68k assembly it'll be a challenge. If I get time today, I'll look at it myself.

The only question mark is how easy it'll be to replace a four-letter name with a five-letter one. Then editing the title screen is an unknown at this point. I'll have a look.

Personal Projects / Re: Dragon Warrior 1 Spanish Translation
« on: May 18, 2018, 04:32:29 am »
I'll leave you in Psyklax's capable hands for a while ;)

Muhahaha... :D

If there are two banks of 16k, and 64k of PRG ROM, where's the other 32k?

I'll add to what abw said here. The 6502 CPU has a 16-bit address space, meaning to load and store addresses, it can't go beyond 16-bits, ie 64kb, or $FFFF. In my "early Famicom games" project, I played every game from the first few years and translated a bunch, and they all have either a 16kb or 32kb PRG ROM. Open up Donkey Kong for example, and you'll see the game is 40kb: 32kb PRG, 8kb CHR.

The first game I found that changed that was City Connection (the Japanese one, not the US one), which had a 16kb CHR ROM. I've also translated (or helped to translate) some other MMC1 games, and it's quite simple.

There's usually a routine in the game that loads the number of the bank, then stores it, usually to $C000 or thereabouts, because as abw says, that part is ROM so it can't be written to, but it's a signal to the MMC to switch banks. This happens instantly, and changes the bank between $8000 and $BFFF. The $C000 bank is fixed to the last 16kb of the ROM. In other games I worked on, I was able to double the size of the game simply by inserting 128kb of zeroes before the last bank, then changing the iNES header to reflect the new size.

So bank switching happens instantly, as it's handled by the MMC, and the CPU does nothing but store a number at an address. Therefore, many later games use this to extremes, changing banks multiple times a FRAME in order to maximise their available memory, and even to make cool effects like parallax scrolling.

Hope it's clearer now. ;)

Personal Projects / Re: Dragon Warrior 1 Spanish Translation
« on: May 17, 2018, 03:57:07 am »
Is there a mathematical formula for this? (Seriously, is it math?) Or does this also require knowledge of ASM?

I'll put you out of your misery on this one. :)

It's actually very simple. In the CPU's address space (people say RAM but technically it's not RAM) the ROM is accessed between $8000 and $BFFF, and $C000 and $FFFF (two banks). Any part of the ROM has to be swapped in and out of that address space. So as far as the game code is concerned, anything in that range is ROM. In the actual ROM file, on the other hand, it goes from address zero to wherever the ROM finishes. So if the first $4000 bytes of the ROM get put in the first bank, $0000 would be $8000. If it goes in the second bank, it'd be $C000.

But wait! What about that $10 difference? Well, that's the iNES header in the ROM file. Check NESdev to find out more about that. All you need to know for now is that the header takes up $10 in the file, but this never existed on a real cartridge, so it's ignored when putting it in the address space.

Thus, in your example, we take ROM address $7B3D, add $4000 (cause it's the first bank) and remove $10 because of the header - $BB2D. If it went in the second bank, it'd be $FB2D. To go from address space to ROM, just go in reverse.

Got it? ;)

ROM Hacking Discussion / Re: FCEUX question about finding bytes.
« on: May 17, 2018, 01:37:07 am »
I would've thought SMB3 had a level editor already, but okay, I'll tell you how I'd find the tile you want. :)

I'd open up the nametable viewer and find the block I want, hover over it and look at its position in VRAM. I'd go to that position in the hex editor and set a write breakpoint for when that tile gets written to. Then I'd go off the screen until the tile disappeared from the nametable, then go back on with the breakpoint active. When that tile is accessed, the debugger will open at the instruction that stores my tile.

The next step is to figure out where the CPU got that tile from. The easiest way is probably to go back to the moment before the breakpoint hit (so go off the screen again) and activate the trace logger, saving to a file. You wanna make sure it's JUST before hitting the breakpoint because that log file can get BIG.

So in the log file, you can go backwards from where the breakpoint hit, to see where the tile came from. So if the tile was E6, I'd see E6 at the end of the log, and search backwards (upwards?) to the next mention of E6. Eventually the ROM location (between $8000 and $FFFF) should show up. When I see it, I'd go there in the hex editor (making sure to right-click "go here in ROM file") and change it to see if I got it right.

Of course, if you're not familiar with assembly, you might find it confusing to read. What you need to know is that on this CPU, everything goes through the Accumulator (or A). So LDA means "load A with something" and STA means "store what's in A to somewhere". We'll be looking for a moment that there's a LDA instruction from the ROM area, most likely.

Give it a try, I can't look right now, but hopefully you'll get the idea eventually. :)

ROM Hacking Discussion / Re: FCEUX question about finding bytes.
« on: May 16, 2018, 06:31:37 am »
check out what bytes are used in the game

Bytes? Sorry, I don't understand. What exactly are you looking for? I understand that you're using the logger to see which memory addresses are being accessed, and you want to search for a particular value solely in those addresses. In that case, I'm not sure how you might do that, but I'm just not sure why you'd want to. Learning a bit of assembly and using the debugger would be a far quicker and more effective way to find what you want.

If you tell us a little more about what exactly you want, maybe I can help find it for you? :)

Can't believe I'm actually coming to this thread with a legit idea... :D

This is less of a hack idea than a game project idea, but I just remembered the classic DOS game Sopwith, which I used to love back in my younger days. I've been hacking NES games for a little bit, and the idea of making a game myself from scratch seems interesting to me.

Here's the game for those whose are unfamiliar:

It's a relatively simple game, and what's more, the source code has apparently been released by the original author. The game has already had source ports for modern systems, but I can't help getting interested in the idea of making a NES port which is as accurate as possible to the DOS original, while still adding some graphical and audio enhancements.

Now I just need to figure out how to start. Is it just nesdev and a 6502 compiler? :)

Your thread title asked about sprites, but it's clear you want to do much, much more. If you're totally new to ROM hacking, nothing's gonna be easy. :)

Start with the section that NERV Agent posted and see how you do. There's not much more we can suggest at this stage.

Gaming Discussion / Re: RIP Virtual Console.
« on: May 13, 2018, 04:56:55 pm »
To be fair, Capcom is doing a limited re-release of Mega Man 2 and Mega Man X.

But in that case I think it's more about advertising and getting people's attention than it is about turning a significant profit.

I anticipated this response. :) They also authorised the re-release of Street Fighter II on the SNES. Thing is, that article suggests it's Capcom doing the work, whereas if you look in the picture, you'll see iam8bit, which is the company handling it. Clearly they went to Capcom and said "hey, can we release a 30 year old game of yours if we pay you?" and Capcom said "sure, fill yer boots". It's a no-brainer for Capcom, so it's completely different from creating a new game from scratch and fronting the cost of producing cartridges. Iam8bit has clearly found a niche (note limited edition of 8500).

EDIT: following the link, it says "Manufacturing by Retrotainment Games + Infinite NES Lives". So clearly Capcom has absolutely nothing to do with this, besides selling the licence to do it.

ROM Hacking Discussion / Re: Treasure of the Rudras font bug
« on: May 13, 2018, 01:59:44 pm »
Hold on, you said you were playing in Bizhawk, yet I tested it, as I mentioned, and it was fine. Is there some strange setting you're using? Are you using the bsnes core? I just can't see how we can be playing the same hack in the same emulator and getting different results.

Personal Projects / Re: Dragon Warrior 1 Spanish Translation
« on: May 13, 2018, 03:28:58 am »
And there you have it!

Yeah, what he said. :D That's more or less what I would do, I was just too lazy to go in detail, so thank you abw for doing so. :)

One point I'd make, though:

13) Back in the game, unpause the emulator and activate the ITEM command. You'll want to be quick about this

I'd recommend getting to the point where you press your button, and use the frame advance hotkey instead of just unpausing and pausing again: just hold the correct button while paused (turn on input display to make sure you're pressing it) and frame advance until the breakpoint is hit. This way your log won't be too big (most of it is usually full of a vblank waiting loop anyway). I don't always jump straight to trace logging, since often when you set a breakpoint for text, the address will be directly before it in the disassembly, but DW is a good example of when to use a trace log. Why does the game keep loading and reloading within the cartridge RAM?! Very odd.

Anyway, keep trying this out with different games and you'll soon see there's nothing mysterious about it, you just need practice. ;)

Pages: [1] 2 3 4 5 6 ... 32