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 ... 14
The answer to the question is "yes". Any game genie code is a fully documented hack. Perhaps you want to know the biggest hack (as in number of changed bytes) that is fully documented?

I think what he means is something like a diary or livestream where someone documents their process. Like a Let's Play for hacking. :) I'd do that if I could, could be quite informative.

I don't know why the tiles all look messed up (unless you did that on purpose, in which case I STILL don't understand why :) ) but if there's a space, it's because there are no sprites there. The only way you'll get sprites there is to add them, which could be a problem because I'm not sure you have the space to do so. The game is weird in how it cycles each sprite through each sprite slot for some reason, and in the ROM you might be limited for space. Of course you might be able to fill that space with background tiles instead: I'm not sure why they even use sprites for the title. I'll have a quick look later.

EDIT: Now I understand why they used sprites: colour limitations. Backgrounds and sprites can only use three distinct colours in any 8x8 tile (or 16x16 area in backgrounds), plus a universal background/invisible colour. By using them together, you can use more colours in the same space. In your case, you may be able to move some sprites over and add new background tiles or something. Since I don't know exactly what you've done here, I can't say much more.

Newcomer's Board / Re: Trouble with Japanese Games
« on: Today at 03:15:35 am »
I agree, Shift-JIS has a Roman alphabet plus Arabic numerals, but this is also assuming there is no other data in there that you might have to mess with. Being a Windows game, I have no idea.

I don't really understand the first issue, but I can help with the second.

The attribute table lies after the name table in the PPU's RAM. So if you know where your graphics are in VRAM, the attribute table is just after it. It's changed the same way anything in VRAM is changed: the CPU picks a value, picks the PPU address and writes to it, both using registers. So the debugger is how you find out how the game writes to the attribute table.

Every game does it a different way, depending on the programmers preference. Sometimes, the background uses the same palette for most of the screen, so the code could just say "start at the top, here's the value, now write it to everything". Sometimes a title screen is more complicated, so it says "start at the top, get the values in sequence from this place, and write them one after the other". Castlevania is probably the latter, but the way to find out is to (in FCEUX) make a write breakpoint for the part of the attribute table you're interested in, and see what happens.

First you should mess with the attribute table in the hex editor to see where you need to change it. Just type other values like 00 or FF, and find the part of the screen you need. Set the breakpoint on that, reset and see what happens. Often it's first written with something blank, then changed to the value that's needed. This is where a little assembly knowledge is needed, but it's actually not that complicated.

When it breaks at the point of storing the key value to that address, you can look in the debugger before it and see where that value came from. If you're lucky, it'll say something like LDA $XXXX, with X being somewhere above $8000 (the ROM). Then you can go there in RAM, click "go here in ROM file" and hey presto, you've probably got the list of values for the attribute table. You can try changing these in the ROM and see what happens.

If you need more info about how the attribute table actually works, better to go to nesdev, as I can't explain everything here. :) If anything doesn't make sense, just ask. Actually, I'll take a five minute look at Castlevania now, just to check...

EDIT: Hold on... you just said the SPRITE "nudged its way into another part of the attribute table and fudged with the colors". What? Sprites don't use the attribute table. It doesn't matter where they are on screen, they each have their own palette. Well, I hope what I wrote was informative, but now I don't understand what you mean. :D

EDIT2: Okay, so I changed the background attribute table in five minutes, and figuring out the sprite part didn't take much longer. $1B107 in the ROM is the byte that affects the top left of the C, changing to 0F ensures that moving it left keeps the correct palette. Meanwhile, $1AB9 is the start of the sprites for the title screen, in the same format as it appears in the sprite RAM (though the X and Y positions are modified by the game, as is standard). I don't know what exactly went wrong for you, but I hope this helps a tad.

Hmm, that's weird. The patch just changes the menu, because the game is actually already in both English and Japanese: the patch just makes it easier to change. If the character name page is still Japanese, I can see why that would be a problem, though of course it'd require more work.

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 04:53:18 pm »
I knew what you meant regarding soft reset, I meant that FCEUX doesn't return to the BIOS when you do a soft reset, but I've no idea what a real FDS would do as I don't have one.

Interesting notes about those other things. I always assumed 00 (BRK) would just stop the game entirely. Still not sure I follow NMI or IRQ though, I'll need to read more about it, but in my hacking it's not something that's really been necessary to know. I did wonder how games would go into infinite loops (such as JMP to themselves, over and over) but still eventually continue the program counter. I guess it has something to do with the PPU saying "okay, next frame, get on with it". :)

Interesting mention of the SMS pause button too, didn't know it would actually freeze the game.

EDIT: since I first wrote this post, I've translated Breeder on the FDS. :D Literally all that there was was the "set side B" and "please wait" messages: everything else is in English. Credits, menus, everything. It's interesting to look on the disk, though. I mentioned that Knight Lore had files for each level which it loaded in to the 32KB RAM as required, but this game looks more like a ROM: side A has 32KB PRG and 8KB CHR files, side B the same, plus save data. Unsurprisingly, the side A file doesn't use anywhere near enough of that 32KB, so it's mostly empty. I added together all the files - without the empty space - and it came to 58KB. Why it's even double sided I'll never know. :D

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 03:01:28 pm »
The last six bytes of RAM are supposed be reserved for a game's vector table, I think.
Though I don't know if the FDS supports IRQs, so I imagine only NMI could go used, as I don't think Reset could be used since I don't think the FDS supports soft-resets.
But I have no experience in that area, it's just what I think I've read.

I don't have a real FDS so no idea about soft resets, but I think FCEUX can do it, for what it's worth. As for IRQ, NMI... I haven't got there in my NES knowledge, don't really understand it at all. :)

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 07:19:27 am »
There's a program called Table Dumper Pro that was done by my friend DvD. Among other features, he wanted something to aid him in Fds hacking. So, there's a file splitter and merger that also produces a file list with all the disk offsets, ram offsets, free space etc. It makes FDS hacking much more convenient.

I used FDS Explorer, does pretty much the same thing. :)

Newcomer's Board / Re: Best hex editor for ROM hacking
« on: September 23, 2017, 05:16:32 am »
Hacking graphics seems simple enough, and if I use my skills and take my time, I could come up with something amazing. I was thinking more along the lines of learning how to use a debugger by means of YouTube tutorials.

I floated the idea of doing them myself: I really would like to do ROM hacking tutorials, but sadly (or not) I have too much going on in real life to devote any time to it. :) One day maybe, one day...

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 03:15:21 am »
My guess is Knight Lore had allocated a certain amount of RAM for holding level data and allows file expansion up to the maximum size.
You could expand a file but you have to be careful that expanding the file doesn't overwrite other data loaded (or written at runtime, the PRG-RAM is still writable).
Of course, if you are manually inserting extra space with a hex editor, you would have to insert it at the right space in the file within the "ROM", then remove extra space so the disk side size total is still the 65,000 byte size, as well as updating the file's header with the right size. Or else I imagine you'll effectively corrupt the game.

What it does is first load a file called DATA on side A which fills the space from $CB00 to $DFFF (the end of usable RAM). Then when you start the game, you have to insert side B, which loads a level file (D1 to D8, with D9 on side A), each time at $CB00. Thing is, each level file is a different size, overwriting a different amount each time. I figured that the eight extra bytes I needed in each level file wasn't overwriting anything useful, as a result, but just to be sure, I played with breakpoints after that position. There ARE some things right at the end of RAM that are read ($DFFF and thereabouts) but since I'm only adding eight bytes, that's no big deal. The smallest level file overwrites up to $D8D4, while the largest overwrites up to $DDC8. Clearly everything in between gets written and rewritten so much that it doesn't matter at all. And yes, I remembered to remove enough zeroes from the end of the file to keep the file size correct.

Awesome! Any chance this might work with Miho Nakayama's Tokimeki High School? FCandChill said they wanted to edit the script themselves, then kind of disappeared. :P

Um, maybe? I looked on the disk and while there is space, you have to know what's happening inside the game while it's running, like I just explained with Knight Lore. In the case of that game, I was able to add a (small) amount of extra data, but like with many things in ROM hacking, it's a case-by-case basis.

Personal Projects / Re: Translations of early Famicom games
« on: September 23, 2017, 01:04:03 am »
Just an update to say Knight Lore is done. :) I'll be uploading all these FDS game patches eventually, but I wanted to talk briefly about my experience with hacking this one.

I needed a few extra bytes to do the translation I wanted, just the "set side A/B" message, but I couldn't find any empty space in which to put it. Eventually it struck me: of course there's no empty space, it's not a ROM. A ROM has to be a specific size, so there's usually empty space, but FDS uses disks with files, and the files can be any size, as long as the disk is the right size. So there's empty space on the disk, but not in RAM during playing. So what to do?

Well, there's a very simple header format for all the files on the disk, which says the size of the file as well as where it's loaded into RAM. I noticed that for each level, Knight Lore used a different file, each a different size. I thought "so it's overwriting the same position in RAM, but it's always different amounts. What if I just add a few more bytes and change the header? It won't be overwriting anything important". So I did, and it worked. :)

Moral of the story is: FDS seems weird when you've done a lot of NES hacking, but there are advantages, such as being able to expand the files on the disk. No messing around with mappers here. :D

I think I'll do a few more FDS games. Adian no Tsue looks curious...

Hmm, all for the same game... Seems really odd that people would hack a game in a way that requires a deprecated emulator. Seems baffling to me. I don't even understand how that can be. :huh:

Newcomer's Board / Re: Best hex editor for ROM hacking
« on: September 22, 2017, 11:20:52 am »
There is no magic hex editor that will make your life easier, you just need one that works, plus a good debugging emulator, like nesrocks said. If you look at the tools I use for my translations, you'll notice they're all very general. The more important thing is learning how your chosen platform works and using that knowledge.

Newcomer's Board / Re: Dragon Warrior 1 in Spanish
« on: September 20, 2017, 03:09:43 pm »
I was under the impression that the DTE would scrunch two letters together to make stuff fit better. I imagine diphthongs like "ia", "as", "ll", and "ie" would be pretty common in my script, so wouldn't "lluvia" and "piedras" be scrunched down at least a bit and be able to fit into the inventory screen? Perhaps I'll better understand how my script will work with the DTE once I see it in action?

No, you're misunderstanding what Dual Tile Encoding is. As I explained before, when you look in the table file, each letter has a byte value assigned. It might be helpful to understand what exactly is happening inside the NES.

Basically, the CPU just reads a long continuous stream of "on and off" pulses, what we know as 1 and 0. These are bits, and to make our lives easier, they are organised into sets of eight, and called bytes. These bytes could refer to anything. They could be an actual number (so "05" could literally be the number 5 that is added to some other value) or it could represent something. In the ROM, you put a big chunk of bytes which are loaded into the PPU's RAM (picture processing unit) and the PPU interprets those bytes as pictures. Some of those pictures are letters, but that's arbitrary, they can be anything. They could be two letters in one block, if you can fit it (like "ll" for example).

The PPU has a separate part of RAM for what is displayed on the screen, called the name table. The collection of 16 bytes that create an 8x8 tile are referenced by another byte value, depending on where it is in RAM. So if one tile is stored in RAM between $0340 $034F, that will have the value $34. The CPU will receive a command from the game saying "put $34 in that position in the name table", it puts it there, the PPU sees it, and draws it on the screen.

What a Dual Tile Encoding routine does is take advantage of all the byte values that WON'T be used by a text routine, and instead taking them to mean two different tiles. These are still stored on screen in the same way, and stored in the VRAM in the same way. It doesn't save screen space. Instead, it saves space inside the ROM itself by needing fewer bytes to write dialogue. For example, the word "cat" would be normally three letters: in ASCII standard it would be 63 61 74 (note: very few games use ASCII standard for the bytes, at least in 8-bit consoles). But if the combination "at" is very common in our script, we could write is as 63 12, for example, using a byte that isn't normally used.

Of course, this varies from game to game, and you need some ROM space to not only store your newly-programmed routine, but also the table of two-character combinations. So, in my example, "at" would be combo number $12. For text-heavy RPGs like DW, the space you save through this is well worth it - but it doesn't save you screen space, as I said. You'd have to manually draw new tiles that have more than one letter in them. For example, in my Conan translation, I had tiles which had an apostrophe stuck in the corner, so that I didn't waste a tile on an apostrophe. That saves both screen and ROM space, obviously.

Sorry if that was a bit much, I just felt like explaining the whole idea in great detail. :) Hopefully it will help you understand what I mean by DTE. A note, however: you may be confusing it with Variable Width Font, or VWF, which DOES save screen space (not ROM space) by crunching the letters together. But this is almost impossible to use on the NES, and is only really seen on 16-bit consoles and up. The reason is the way graphics are produced: the tiles have to go into memory, then they have to go through a process where they're crunched together, then THIS has to go to the VRAM to go on screen. The NES simply doesn't have the memory or the layering to do this practically. It's not impossible, just impractical.

Personal Projects / Re: Translations of early Famicom games
« on: September 20, 2017, 01:22:44 am »
I'd meant to say congrats on the 0.1 of Time Stranger! I hope my comments in the script forum are helpful. It seems like activity has dropped off sharply here. Did everyone go back to school or something? :P

Yes, your comments on Time Stranger were helpful, thanks. :) I just haven't been back there since then.

Seems funny to me that people hacking old NES games could have school to go to. :) I'm certainly very busy in real life, but it's got nothing to do with school.

Actually, I was browsing the FDS list last night and noticed Knight Lore (a Rare game originally on ZX Spectrum) only seems to have Japanese menus, so I think I'll have that done soon.

Newcomer's Board / Re: Is Searching Through a ROM This Hard?
« on: September 19, 2017, 05:08:06 pm »
I don't really follow you. Emulators have debugging tools that mean you don't have to go through a ROM changing bytes randomly forever. Maybe people had to do that in the old days, but not any more.

Then again, I don't know what system you're working on. :) If it's the NES, for example, FCEUX has a wonderful set of tools. Once you learn a thing or two about assembly and using the debugger, it will tell you the bytes you need very easily. But as I said, you should give more information before you can get help. ;)

Newcomer's Board / Re: Dragon Warrior 1 in Spanish
« on: September 19, 2017, 02:49:46 pm »
I'm sure people translating into languages other than Japanese and English often encounter problems such as these. :) Japanese doesn't really inflect at all, and English only minimally (his/her for example), so a language like Spanish will have these gender problems. Trust me, it's nothing like the problems in Slavic languages like Russian (no articles, but three genders, gendered/numbered past tense, six noun cases...). :o I'm not sure how people manage when translating to Russian. Japanese and to a large extent English are very flexible in that you can just drop a word in somewhere and it'll be fine, but imagine your example with the staff: in Russian you'd need to change the item completely to be grammatical.

For example, let's say the item is "red book". In Russian, krasnaya kniga. But if you say "[ME] held the red book" it would be "[ME] derzhal krasnuyu knigu". Not only that, but "held" is in masculine, but if the player is female, it should be "derzhala".

Anyway, I'm rambling. :D What can you do? The easy option is simply to forget the article, even if it doesn't look so good. After all, "el Palo" just about fits in the inventory, but "las Piedras" doesn't. Option 2 is to widen the inventory to fit the articles, which would be nicer but would also require a good bit of hacking. I know this from doing it on Aighina's Prophecy. It was a lot of work, but it was worth it for me, because it widened the text window, allowing me to have more dialogue on screen.

So, if you think "[ME] agarró Palo de Lluvia firmamente" sounds bad, the only good option is to hack the item menu. Not impossible, but not easy. I noticed also that the text includes several cases of "thy [INV]", so unless you just ignored that in your translation, you couldn't use articles there anyway. I wonder what people usually do when translating English games to Spanish? Have you played any? (I haven't, of course)

Oh, and regarding using the DTE to fit the item names: that's not the problem. There are two space problems you worry about when translating ROMs: SCREEN SPACE and ROM SPACE. The problem with the dialogue is ROM SPACE, which is fixed by compressing the text with DTE. The problem with the menu is SCREEN SPACE, so any amount of compression won't help you, because it just won't fit on the screen (without hacking). :)

Personal Projects / Re: Translations of early Famicom games
« on: September 19, 2017, 06:40:53 am »
Seriously, not one post commenting on v0.1 of Time Stranger? Hmm. :-\

Anyway, I had a spare hour or so today, so I decided to change the title screen of All Night Nippon Super Mario Bros.

Quite a simple job, really. And of course there's no other Japanese text that I know of (the ending is the same as SMB2j I believe, so in English). My only concern is that each time you complete World 8-4, it adds a flashing star on the title screen, which is then saved on the disk. Now, because of me using two lines, the star appears on the next line, and doesn't flash. This could be seen as a problem, but unless you complete the game twenty times or something, I don't think it's that big of a deal. :)

Haven't added it to my site or the database yet, might do soon, if it's worth it.

EDIT: just read online that you need to complete the game eight times to access Worlds A to D. I changed the save file to 8 and it does exactly that. The eight stars still fit on the title, they just don't flash, and I don't think I can change that, because that palette needs to be shared with the letters of the title, meaning that would flash too.

Gaming Discussion / Re: Moonwalker prototype with Thriller track ...
« on: September 18, 2017, 06:33:33 am »
Looks real to me. It's exactly the same style as the other tracks in the game. Someone would have to go to some lengths to fake that. Also the stage select seems to be automatic, unless they had another pad with them.

Newcomer's Board / Re: Dragon Warrior 1 in Spanish
« on: September 17, 2017, 03:03:59 pm »
If I need anything else, I think there are three spaces after the punctuation. Could I use two of those?

If you check the table file, those byte values are already used for other things, so you should avoid them. In fact, just look at the table file and my explanation of it. You'll see that there aren't many things you can use (because 81 to ED are used by my DTE routine, and everything else is taken).

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