Hack/Repro Question: Sunsoft's Hebereke
Moderator: Moderators
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.
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 -
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 -
-but I try to make everyone happy. That and it's a good thing to know for future projects.A 60Hz version of Ufouria would be nice for the NTSC audience
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.teoma wrote:1) What's an IRQ counter?
You'd usually change the speed of all moving objects and the tempo of each music track.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?
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.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?
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.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?
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.
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.
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.
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.Now I would like to ask you to insert the japanese script in to the european file, cause i cant seem to do it:<
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:
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...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.
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.
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.