Hack/Repro Question: Sunsoft's Hebereke

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

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.
teoma
Posts: 22
Joined: Sat Jun 16, 2007 6:46 am

Post by teoma »

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 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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
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.
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.
teoma
Posts: 22
Joined: Sat Jun 16, 2007 6:46 am

Post by teoma »

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?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit »

You can see which PAL games will work in NTSC by messing around with the "Pal Emulation" option in FCEU or other emulators.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
teoma
Posts: 22
Joined: Sat Jun 16, 2007 6:46 am

Post by teoma »

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.
mog123
Posts: 27
Joined: Mon Jan 22, 2007 11:12 am
Location: Poland

Post by mog123 »

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.
teoma
Posts: 22
Joined: Sat Jun 16, 2007 6:46 am

Post by teoma »

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:
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...
mog123
Posts: 27
Joined: Mon Jan 22, 2007 11:12 am
Location: Poland

Post by mog123 »

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.
Post Reply