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

Pages: 1 2 3 [4] 5 6 7 8 9 ... 35
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. ;)

ROM Hacking Discussion / Re: Treasure of the Rudras font bug
« on: May 13, 2018, 03:16:20 am »
Yeah, doesn't happen with bsnes in BizHawk either, obviously. You must be using an inaccurate emulator which struggles with the SNES's hi-res mode.

Castlevania 3: Dracula's Curse. Every character is playable at the same time like in Bloodstained: Curse of the Moon.

The easy way to get this is play in an emulator like FCEUX and freeze address $54E with the number you want.
00 - Trevor
01 - Sypha
02 - Grant
03 - Alucard told me this. :)

If you want the four characters to be selectable in the game easily, I'd have to find out where in RAM the currently-available characters are kept, which would mean playing through the game. No thanks. :D

Alternatively, use Game Genie code KVAVPY to enable a debug menu: the first digit chooses the level, the last digit chooses who Trevor partner's with. Again, thanks to for that. :)

Personal Projects / Re: Dragon Warrior 1 Spanish Translation
« on: May 12, 2018, 01:18:13 pm »
Good to know. Iirc, Psyklax spoke against using game-specific editors, too, and that a hex editor was better and/or all you needed. Perhaps he meant more than he said, but his guidance left me under the impression that anything and everything could be/should be done in a hex editor :P

But you can use a non-game-specific tool without typing your whole script in a hex editor. :) That's what abw meant. Like using something like Pointer Tables to do your script, rather than directly typing into Windhex 32 EX.

And yes, anything CAN be done in a hex editor, but not necessarily SHOULD be done. ;)

Okay, cool! Gonna try this. Now, question: how do you know where the pointer table for each section of text is? I assume there are certain hex values that tell you that, but how do you figure out what's what? Also, are there pointer tables for things other than text (e.g. calculations for damage points in an RPG)?

It ain't the hex values, it's learning how to use the debugger in an emulator, and understanding assembly. Basically, a pointer is just a value that tells the game where to find something. So when there's a pointer table, it's a list of locations in the ROM, and the game will look there when it needs something, such as a line of dialogue. The alternative is to do what's called 'hardcoded pointers', meaning you have to write the location into the code ("load from this place, write it to RAM"). That's fine for simple things like a Game Over message or something, but dozens of lines of dialogue would be very impractical. With a table, there's a command that loads from a location, plus whatever is in a register. So if the game needs dialogue number 5, it will load 5 into a register and say "load from this address, plus 5".

So to find these pointers, you just work backwards with a debugger: you set a breakpoint for the line of dialogue, see where it got that address from. If you're lucky, you'll immediately find the pointer; otherwise you just keep following the trail.

If you need any help finding stuff in DW, let me know. :)

Gaming Discussion / Re: RIP Virtual Console.
« on: May 11, 2018, 07:50:27 am »
Woah, dude, chill. What FAST6191 said is right: it's all about the bottom line.

Imagine you're a video games company for a second. You want to release a retro game, and you have two choices. You release it to be compatible with original NES and SNES hardware, or you release it for Steam, PlayStation, Xbox, Switch, 3DS.

For the first option, you have to pay a hefty amount on producing cartridges, since chips do cost money, but even to do that, you might need to get a factory to produce the chips especially, unless you can get a third party manufacturer or off-the-shelf parts. Either way, your company is not set up for this, so the initial costs will be substantial.

You also need programmers familiar with the assembly for that particular machine. Sure, there are hobbyists out there who could do it, but usually they do it as a hobby, not a full-time job, and your existing personnel would probably baulk at the idea they need to learn a new way of programming just for this game.

Finally, the end user. There are plenty of systems in the wild, but they are not actively supported, so the majority of users are the kind of people who populate forums like this - people like you and me, basically. It may feel like there are plenty of people like you out there, but trust me: the numbers ain't on our side. Just check out the numbers of viewers on Twitch for modern vs retro games.

Also, most of the core audience would look at your cartridge and think "how much?! I'll just get a ROM instead". I could be wrong about this, but still... ;)

Now, the second route. You make it look just like a SNES or NES game, but get your existing devs to make it in a language they're experts in. You aren't restricted by the limitations of old hardware. You have an install base of anyone with either a PC or modern console - that is, literally everyone. You don't need to get into manufacturing cartridges, especially since your company probably doesn't manufacture anything anyway. The cost to the user is about four to five times less, simply because there's no cartridge. You can sell all over the world via a download, without worrying about postage problems.

Faced with these two options, there really isn't a choice at all. I know you would love to see brand new games made for old consoles on cartridge - I'm sure a lot of us here would like the novelty factor of it. But business is business.

Now Kickstarter, on the other hand... ;)

Personal Projects / Re: Dragon Warrior 1 Spanish Translation
« on: May 09, 2018, 06:23:40 pm »
Going through the enemy name list, there are several names that are going to require more space in Spanish than they would in English. I haven't looked at the item list yet, but the case for that may be the same. Is there a way to dump the item and enemy lists, translate them, and reinsert them into the ROM like we did with the dialogue/script?

Hmm, it depends which is longest: the English or your Spanish. If the former, great. If the latter, you might need to get creative, finding some empty space somewhere (I'm not looking at the ROM now so I can't see what's there).

Solstice NES - SRAM Saving!

Wouldn't it be easier to use save states? At least if it used passwords then saving could be easier, but adding SRAM may require a mapper change. I guess if someone wants it enough...

But wait, you've added SRAM saving to, what, six other games. Surely people should be asking YOU to do it? ;D

Yeah, the way that Undub patch works sounds like the best way: no copyrighted material included in the patch. Same problem happens when you use IPS patches to do complicated things like add bytes to disk images: the dumb patcher just includes most of the original disk. The whole point of patches is to AVOID distributing copyrighted works.

Granted, I did a patch for Iron Tank which restored the graphics from the Japanese version into the US version, but I didn't know there was such a way of combining two patches. In fact... now that's got me thinking. Is there a patcher that takes two input files rather than one? So the patch file, instead of saying "put these bytes at these locations", it says "take the bytes from location A in file A and put them in location B in file B". There may not be much call for it, I admit, but still. :)

Pages: 1 2 3 [4] 5 6 7 8 9 ... 35