I'm trying to make an English localized version of Sunsoft's Hebereke. The famicom version uses mapper #69 so (as I am told) it is unable to be reproduced on a cart that can run on a ntsc system. Sunsoft made a PAL version of the game with altered (crappified) graphics, sound and script and renamed it Ufouria. I am currently doing a hack on the PAL version to restore the japanese title screen/sprites/music/script (it will be in english, but more accurate to the japanese version).
My question is, can a hacked PAL rom (more specifically, this hacked pal rom) work on ntsc system? I'm assuming it somehow uses a different mapper then the japan-only #69. I know very little (nothing in fact) about mappers, what they do and why they only work with specific systems. If it's not ntsc compatible, is there any way to hack the rom to replace the mapper? (if you can't tell yet, I really want a hard copy of this game
) Thanks for the help, and sorry about the n00bish questions.
Mapper #69 is not Famicom-only. Some US released games also used this mapper -- or at least a totally compatible mapper (Batman: Return of the Joker comes to mind).
However -- mapper 4 is definately much more common. So if you're looking to put this on a cart you might want to switch anyway. Mapper switching is definately very possible (I've done it several times with some hacks I've made in the past).
As far as NTSC/PAL compatibility go -- from a software standpoint.. the only things you have to worry about are:
- NTSC runs at ~60 FPS instead of ~50
- NTSC only has 20 scanlines of VBlank instead of 70
- NTSC's CPU runs at a slightly higher clock speed, so LUTs used for the music engine will need to be adjusted if you're converting. A tone played on NTSC will sound higher pitched than the same tone played on PAL.
Since Hebereke was designed for NTSC first, then moved to PAL, you don't really have much to worry about. You -could- just do a straight translation of Hebereke. That would probably be much easier than modifying Ufouria to work on NTSC.
The Japanese version uses mapper 69 (Sunsoft5 / FME-7), as you know, but it does not appear to use the mapper's extra sound channels, so the game is playable on an NTSC NES. There is one game (Batman: Return of the Joker, if I remember right) that uses mapper 69 in the US release, so US cartridges do exist with this mapper.
The PAL version uses mapper 4 (MMC3). A large number of games use this mapper, so finding a donor cart will almost certainly be easier. However, a PAL NES has different timing from the NTSC NES, so you will likely need to work on the code to adjust for the different timing (particularly the IRQ engine, which can cause graphical glitches if not adjusted to the correct timing).
Thanks for the help. From what you guys said it seems easier to translate the japanese rom then japanify the european rom. It should be easy to translate since to some degree I can use the pal version for reference, but a few parts are both different from the pal version and difficult (for me) to translate.
"fupiyootsutsutsu
hapiyooootsutsutsu"
That sounds like he's crying to me (yotsutsutsu=boohoohoo?) but I can't figure out what he's saying before then. Is there any kind japanese soul that can help me with the more difficult parts? I'm just starting on this - so far I've only been working on graphics changes on the pal version - I still need to do a text dump of the famicom version.
Lastly - am I the only one that likes this game? For such a good game it seems odd that no one has translated it yet - its like a cross between SMB2 and metroid.
You may want to check the forums at romhacking.net for script help. They have a messageboard dedicated to script questions and have lots of old translating pros to help out.
Also: I've played, beaten, and absolutely love Ufouria. ^^
I Did some attempts on extracting Hebereke's japanese script, But I could not have it due to difficulties, Including making a Japanese Font table
Suggestion: Ask Kingmike for some help, And at least try ''Djinn Tile Mapper'' and download at Romhacking.net.
Good luck with the translation!
P.S. I posted a help thing on Romhacking.net about a year ago.
No, You are not the only one who loves Hebereke, I am a Hebereke fan
too. I know no Sunsoft music skills, but I know where it starts in the ram
and the music format is simular to Journey to Silius(RAF World in japan).
-Hamtaro126
I have finished ripping the text. You can download it here:
http://www.savefile.com/files/826391
I included both the Ufouria text and the Japanese Hebereke text so it should be pretty easy (if you know japanese at least). I put this on the romhacking.net forum too.
http://cah4e3.shedevr.org.ru/misc/u4ia-res.rar
Text scripts here both for eng and jpn versions, script inserter (tscript) haven't support for multibyte chars, so you need to translate it to english first.
This res files I'm was used to translate ufouria to russian language, but I'm too lazy to do dejap work.
CaH4e3 wrote:
http://cah4e3.shedevr.org.ru/misc/u4ia-res.rar
Text scripts here both for eng and jpn versions, script inserter (tscript) haven't support for multibyte chars, so you need to translate it to english first.
This res files I'm was used to translate ufouria to russian language, but I'm too lazy to do dejap work.
404. Документ не найден.
Bad link
Oooops, sorry... My fault... Forgot to upload. Anyway there is rom inside.
I'll fix it as soon as possible.
A few more questions:
Translation:
Is it bad form to dump the text as a gif file? (see my text dump link). I don't know what standard format is for japanese text so I just made a program that dumps all the text as it is displayed in game. I hope that doesn't make it more difficult to translate somehow.
Hacks:
1) B Button Run
Someone made a final fantasy hack like this. The problem is most of the characters in Hebereke move very slow. It would probably be easier just to edit their speeds but I think that would change the gameplay too much. A B Button Run would be nicer but I don't know how to insert code, I only know how to change the code that's already there. I found a cpu address that stores their x address but it's per 16pixel tile - the game seems to 'tween' its location as it moves between tiles. Just wanted to know how difficult this would be.
2) Mapper Swap
Hebereke(J) uses mapper 69 and Ufouria(E) uses mapper 4 which is much more common (i only know this because you people told me). I would like to switch the famicom rom's mapper to mapper 4 to make it easier to reproduce - but how do I do that? I don't know how to tell what type of mapper a rom uses or even what a mapper looks like in code (as opposed to graphics, level data, ect..) One would assume that Ufouria and Hebereke keep their mappers in the same place so swapping them would be easy - but as I said before I know very little about mappers.
In code, a mapper looks like writes to non-RAM locations, usually as writes to $4020-$5FFF or as writes to $8000-$FFFF. To tell which mapper a game uses, check bytes 6 and 7 of the ROM per the
iNES spec.
Luckily, MMC3 is a lot like FME-7, though it has fewer switchable banks. For a game that uses a lot of DPCM, such as any Sunsoft game, this could be difficult.
tepples wrote:
Luckily, MMC3 is a lot like FME-7, though it has fewer switchable banks. For a game that uses a lot of DPCM, such as any Sunsoft game, this could be difficult.
Thanks - but since I have a pal rom with mmc3 code wouldn't it be easy to use that to change the famicom rom mapper? One would think that both roms have exactly the same code and that only the content (graphics, string tables, ect) would be different. The only code difference I can think of is the frame rate - pal is 50fps and famicom is 60fps.
ps - I found the xspeed byte - $0504 in ram. It's a single byte signed integer - 7f is a high positive number, 80 is a high negative number. All I need to do is find the 'max speed' byte - and add in code that increases this value if the b button is pressed.
I guess there is a LOT of differences between PAL and NTSC versions, including :
- Music code pitch table
- Music tempo
- Speed for each objects
- Mapper writes
- ROM and RAM banks layout
- ROM and RAM atributions : Some piece of code can be smilar, but mapped differently in memory (as well with variables).
I suppose you're right - I just hate ripping apart a good return of the joker cart.
That, or a european Gimmick card (even rarer).
If you want to push the thing on the real hardware, I'd definitely go for MMC3.
Bregalad wrote:
If you want to push the thing on the real hardware, I'd definitely go for MMC3.
Alrighty, if I did want to put this on real hardware (which I do), what specific steps would I take to make the rom compatible with a MMC3 mapper? I understand the changes would be extensive, but where would I start? Between the runtime 6502 disassembler in fcued and a hex editor I can change any pointer or value, but I really don't know where to start with changing a mapper. Do I just change the mapper number in the header, run it, and try to fix everything that doesn't work?
Somebody said they changed mappers before - is there a tutorial on this somewhere?
(I really want a hard copy of this game - pc emulation just isn't the same as the real thing)
teoma wrote:
what specific steps would I take to make the rom compatible with a MMC3 mapper?
1) Get
MMC3 documentation2) Get
mapper 69 documentation3) Isolate ALL the routines in the ROM that perform mapper register writes (set breakpoints on writes to anywhere >= $8000). This includes IRQ counter settings, PRG/CHR swapping, etc. There shouldn't be all that many -- usually the game will JSR to only a handful of routines.
4) Decipher and document those routines and make sure you understand exactly what they are dictating the mapper do
5) Rewrite those routines so that they do the exact same thing, but using MMC3 instead of mapper 69.
6) Change the mapper number in the header.
that's it!
If you know your 6502 and can understand the mapper documentation, it really isn't all that hard. Provided the mappers are compatible (which in this case... they
mostly are, but not fully. You might run into some problems because mapper 69 can swap each 1k page of CHR, but MMC3 can only swap 2 2k+4 1k pages.
Quote:
I understand the changes would be extensive
Not really. More than likely, all the routines are in the last "hardwired" page of PRG. There's really only 2 things you have to look for:
1) mapper prep (done shortly into the reset vector)
2) swap/IRQ routines (which are JSR'd to by various points in the game)
Also -- be sure you set up everything MMC3 needs.
Including enabling WRAM. Most emus will probably let you slip by skipping that step, but the cart won't.
EDIT
In fact... I'm kind of board right now. I'll take a look-see to see if I can do it real quick. I guarantee nothing, though... I get bored of romhacking very quickly.
Wow, thanks. My 6502 isn't all that great - I'm kind of learning assembly as I go. I usually make pc games from scratch - 3d ones at that - so hacking someone else's 2d game is somewhat easier by comparison, though it is still new to me (i've hacked pc games before, but not nes games). Thanks for the help.
Also, if you encounter problems with 1 KB CHR page swapping, see wich solution the europan MMC3 version did, and/or make 2 KB CHR banks from two 1 KB banks arranged differently, even if they sometimes repeats (you'll also have to found useless banks if you make too much of them). I did this with Contra (J), and this was possible without increasing the CHR size.
Bregalad wrote:
Also, if you encounter problems with 1 KB CHR page swapping, see wich solution the europan MMC3 version did
The European version used MMC4
I changed the font, inserted the european script into the japanese rom, and retyped it using lower case letters. It looks better, but as you can see the european translation is severely lacking in personality. You can see in the japanese one the cat character is laughing (o-hahaha), though I still don't know what "kopyootsutsu" means. I'm not trying to do a perfect literal translation, I just want something that captures the feel of the japanesse dialog while still being understandable and entertaining in english.
On a side note, a few of the japanese pointers are in a different order then the european ones. Most notably, the intro and ending sequence. If you let the intro run it will eventually crash, so I won't be putting up a patch until I fix that. I suppose the next item of business is getting this thing translated - I'll work on the mapper swap and gameplay hacks later.
Quote:
The European version used MMC4
You mean mapper 4 I assume ? If it used the MMC4 (mapper 10) that would be a great discovery.
okay, mapper 4 (I'm still learning this stuff). Is mapper 4 the same as MMC3? Now I'm really confused @_@
I've dumped my copy of Ufouria (PAL SCN version) to Bootgod's cart database. Take a look
here and you can see that it uses MMC3 which is iNes mapper 4. The iNes mapper numbers are pretty confusing.
teoma wrote:
okay, mapper 4 (I'm still learning this stuff). Is mapper 4 the same as MMC3? Now I'm really confused @_@
I find it less confusing to associate iNES cartridge type numbers with the
names of cartridge circuit boards. For instance:
- 0 is NROM, along with the functionally identical RROM and STROM
- 1 is S*ROM
- 2 is U*ROM
- 3 is CNROM
- 4 is T*ROM, along with HKROM aka "the StarTropics board"
- 5 is E*ROM aka "the CV3/Koei board"
- 7 is A*ROM aka "the Rare board"
- 9 is P*ROM aka "the Punch-Out board"
- 10 is F*ROM aka "the Fire Emblem board"
- 13 is CPROM aka "the Videomation board"
- 15 is "the 100-in-1 Contra board"
- 69 is "the Batman board"
Quick question:
I'm working on the translation, and the intro sequence (the one that appears if you let the title screen run) is in a weird order.
This is a list of the real addresses of the text in the order it appears while the game is running, along with it's respective nes pointer in (). There are 20 screens altogether:
00: 38fe (eeb8)
01: 3910 (00b9)
02: 3926 (16b9)
03: 3c68 (58bc)
04: 3910 (00b9)
05: 3932 (22b9)
06: 393e (2eb9)
07: 3957 (47b9)
08: 3975 (65b9)
09: 3993 (83b9)
10: 39b8 (a8b9)
11: 39d3 (c3b9)
12: 3c3b (2bbc)
13: 39e7 (d7b9)
14: 3910 (00b9)
15: 39fc (ecb9)
16: 3a1b (0bba)
17: 3a44 (34ba)
18: 3a67 (57ba)
19: 3a79 (69ba)
The text at $3910 is "..........", it is repeated 3 times in the intro. Notice that the order the text is shown when the game is running is different from the order it appears in the rom.
Now here's how the pointers look in the rom (addresss $2f4f):
EE B8
00 B9
16 B9
22 B9
2E B9
47 B9
65 B9
83 B9
A8 B9
C3 B9
D7 B9
EC B9
0B BA
34 BA
57 BA
69 BA
All of these are in order by address. I can't find anything in the rom's code that indicates any different order. I tried searching for pointers to the pointers but to no avail.
I'm going for a more or less accurate translation so I may not need to change the pointer order, but it would be nice to have that option. Has anybody run into something like this before?
What you describe is just a list that points where every text starts : There is no meaning the game will use them in that order.
The intro could (and probably have) been coded to something like this :
Show text #5
Show image #24
Show text #3
Show image #30
etc...
I just put that randomly, but the programmer just assign number to their textes and that numers are not necessary in the good order.
Thanks, sorry about all the n00bish questions. If I use FCEUD and set a breakpoint to the address of the pointers could I find it that way?
Yes (you should use the NES adress, not the adress in the ROM image). The only annoyance would be if the game would bankswitch something else, and read them periodically from the same adress range than where the text is stored, but from another ROM bank. So just try and see the results.
I really love Ufouria as well, but I cannot understand how anyone would prefer the graphics in Hebereke. Both Bop-Louie and Freeon-Leon look ugly enough to put you off from playing it. :)
A 60Hz version of Ufouria would be nice for the NTSC audience I suppose, but I would suggest using the Ufouria graphics for that one.
Taking a break from translating to work on the actual hack.
A few stupid questions:
1) What's an IRQ counter?
2) How do I change the game's PAL/NTSC framerate?
More specifically, how does the game keep track of the time that passes
between drawing cycles?
3) What is the program doing between drawing cycles? I understand it has
to calculate where everything will go before it can draw, but I have a hard
time believing that these calculations will take exactly the amount of time
needed for it to draw 50/60 times a second. Does it loop until there's a vblank?
I know I don't have to change the timing on hebereke to make it work on us systems -
Quote:
A 60Hz version of Ufouria would be nice for the NTSC audience
-but I try to make everyone happy. That and it's a good thing to know for future projects.
teoma wrote:
1) What's an IRQ counter?
MMC3 has a counter that keeps track of how many scanlines have elapsed, allowing a game to split the screen without spin-waiting on sprite 0 overlap. It counts how often the PPU switches between fetching sprite cel data from $1000-$1FFF and fetching non-sprite data (background tile data from $0000-$0FFF or map data from $2000-$2FFF). There is always one burst of sprite cel fetches per scanline. A program will generally set this counter to a Y value before turning on the screen and do other things. When the counter runs out, the MMC3 will assert a signal, called "IRQ" for interrupt request, that causes the CPU to call a subroutine called the IRQ handler. This subroutine changes the scroll position of the screen while it is still being displayed, causing the screen to appear split.
Quote:
2) How do I change the game's PAL/NTSC framerate?
More specifically, how does the game keep track of the time that passes
between drawing cycles?
You'd usually change the speed of all moving objects and the tempo of each music track.
Quote:
3) What is the program doing between drawing cycles? I understand it has
to calculate where everything will go before it can draw, but I have a hard
time believing that these calculations will take exactly the amount of time
needed for it to draw 50/60 times a second. Does it loop until there's a vblank?
Yes. NES programs can tell the PPU to generate a signal at scanline 241 of each frame. This signal, called "NMI" or non-maskable interrupt, causes the CPU to call a subroutine called the NMI handler, which either performs actions that should happen once per frame or just notifies the main loop that it should perform those actions.
So aside from a lockout chip there is nothing in the games code to indicate that it is either pal or ntsc? In other words, lockout chips aside, I can take a pal game and run it on a ntsc system and it will work fine, except everything will run 120% faster?
teoma wrote:
I can take a pal game and run it on a ntsc system and it will work fine, except everything will run 120% faster?
This is not always the case, because PAL VBlank's are much longer than NTSC ones (NTSC is 20 scanlines while PAL is 70 or so scanlines!). So, if a PAL game makes use of the extended Vblank time, converting it to NTSC will be a bit harder, and it will need to sacrifice some of the otherwise rendered frame (top or bottom of the screen) to virtually extend VBlank. Also, there are less CPU cycles per scanline in PAL, and if a game makes heavy use of timed code there will probably be a lot of visible glitches.
You can see which PAL games will work in NTSC by messing around with the "Pal Emulation" option in FCEU or other emulators.
First version of the patch! You can download it here:
http://www.savefile.com/files/892044
Apply this to the Hebereke(J) rom. All this does is add a B Button run feature. It seems a little fast to me, but this is the same speed mario from SMB3 runs at. I think I'll slow it down a bit, but I'm open for suggestions.
And now for a question:
To change the mapper, I must systematically replace all routines that write to >$8000. Is there a better way of doing this then setting up breakpoints in the debugger? There may be areas of the game's code that I'm not getting to by playing it.
Hi, sorry to dig this up, but I'm trying to do the reverse thing!
I want to get the japanese text and graphic into the european version.
I got the graphics, but they screw up the intro screen.
Now I would like to ask you to insert the japanese script in to the european file, cause i cant seem to do it:<
Please help.
Quote:
Now I would like to ask you to insert the japanese script in to the european file, cause i cant seem to do it:<
I wrote a program that lets you edit the text by hand (in both the e and j versions), or cut and paste if you like. I've been busy so I haven't had a chance to work on this for a while. The hack is mostly done, but I'm still working on the translation.
What would be the point of putting j script in the e version? If you like the e graphics it would be easier to just put them in the j version. The only reason I can think of would be to play it with japanese text on a pal system....
Anyway, I set my program up so it would be easy to insert any language text (portugues, arabic, ect...) It's been a long time since I looked at it, if I have time I'll try to upload it.
Lastly:
Quote:
Hi, sorry to dig this up, but I'm trying to do the reverse thing! I want to get the japanese text and graphic into the european version.
For the record, I'm hacking the J rom, keeping the J graphics, translating the Japanese text to English, and swapping the mapper with a few other minor asm changes. So it seems what we are doing is very similar and not quite the 'reverse', if only I knew why you need the japanese text in the european rom...
We're not doing the same thing, you're editing teh J rom to have English text, I'm editing the E rom to have Japanese text(and japanese graphics).
What I'm doing this for? The E version runs on a standard MMC, while the J uses sunsofts custom mapper which is harder to obtain. Simply I want to get the game on a cartridge, without having to buy an extra donour cart.
I've swapped the graphics (the title screen gets all garbled, but the heck with it)). And that's as far as I can do.