Page 1 of 2
Grond's Final Fantasy on real hardware
Posted: Tue Apr 08, 2014 6:42 am
by flagoss
Did someone tried Grond's Final Fantasy on real hardware ? I did it using the same methode as FF3. Game boot, music play fine, I can enter battles etc. but it's all garbage graphics and no readable text. At first I tought that was a problem with CHR-RAM. After checking the wiring for hours, everything seem to be fine. I then desoslder the Grond's FF PRG and Replace it with a FF3 PRG. Everything was FINE and playable. Do I need to do somenthing special to get Grond's FF working ?
Re: Grond's Final Fantasy on real hardware
Posted: Tue Apr 08, 2014 4:35 pm
by flagoss
Well, while testing my roms on various emulator, it happens that HIGAN from byuu is giving the exactly same graphic glitch !! If someone could test it in HIGAN and try to figure what's wrong with the hack. I don't think it's something big since the game is actually playing.
EDIT:
It's like the wrong tileset gets selected ! Sometime, small parts of the screen display correctly but thats rare !!!
EDIT #2:
After more testing using a debugger and looking at the active tileset while the game run, It looks likes the tiles are shiffted exactly by 8 lines Up or Down. On some rare occasion, on some screen, you will have a group of four lines on the tileset that will display perfectly but the rest will still be shifted. Its king of like the game is picking the tiles 8 lines to high or 8lines to low or the picking a tile 128 position to far.
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 2:35 am
by Bregalad
I'd bet the hack "assumes" memory is initialized to '0' to work, or something in the like.
There is so many hacks not working on real HW, especially those who makes a lot of changes to the game engine itself.
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 6:03 am
by flagoss
Well since all the garbage that is display on screen is actualy present on the current tileset with no exeption, it's only that game don't pick the good tile in the tileset or that the tileset don't get in memory in the at the right place. The garbage is always the same, at the same place so I assumed it was not a initialisation problem. But it may still be that ? So the CHR RAM would not be initialised to "0",
Is there emulator with debugger where we can see the content of the CHR RAM in real time ?
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 7:35 am
by tokumaru
flagoss wrote:Well since all the garbage that is display on screen is actualy present on the current tileset with no exeption, it's only that game don't pick the good tile in the tileset or that the tileset don't get in memory in the at the right place. The garbage is always the same, at the same place so I assumed it was not a initialisation problem.
I would bet the problem is timing, not a simple source/destination issue. The NES imposes some limitations on how VRAM can be accessed, but old/inaccurate emulators are quite forgiving and will allow access during times when the real hardware won't. Attempts to access VRAM during these times will most likely cause graphical corruption.
But it may still be that ? So the CHR RAM would not be initialised to "0"
Could be an initialization thing, but I'd bet on timing, which will be harder to fix.
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 7:46 am
by flagoss
A guy on that forum has a EVERDRIVE and is saying that Grond' Final Fantasy is working on the real hardware.
http://krikzz.com/forum/index.php?topic=910.0
I just PM the guy and ask him to confirm that the hack worked pefectly for him on the real hardware.
Is the everdrive doing something special to the CHR RAM like initialising it differently the standard RAM on an original cart ?
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 10:25 am
by lidnariq
flagoss wrote:Is the everdrive doing something special to the CHR RAM like initialising it differently the standard RAM on an original cart ?
There's a whole slew of random things that the Power Pak (and presumably Everdrive also) does subtly different that can't help but hide power-on bugs.
What immediately comes to mind includes having already waiting for the PPU to warm up.
The ROM hack here only waits for the VBL flag to be set two times, which is sufficient if it were a cold boot.
Warm boots on the NES, however, might have the VBL flag be set when first turning on, so it must be cleared before the wait (or wait for three VBLs). This is probably minor: it should work sometimes and not work other times.
The ROM hack does not obviously clear internal RAM... and I can use that to tickle a bug using Nintendulator: During the text fade in from the introduction, use a soft reset (F4): the screen turns green, goes to the main menu, and then I start getting subtle CHRRAM corruption. For some reason I can't tickle the same bug with Nestopia, though.
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 10:38 am
by flagoss
If you want to have the exact same bug that I have, Just try it under Higan. You will get the exact same behavior. But like I said, it's nothing random. I mean that when I look at the pattern table in Nintendulator, the game seem to use a tile that is exactly 128 positions further in the grid than it should. It's true for every line in the table exept some lines that are used correctly.
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 12:15 pm
by Bregalad
I wasn't talking about CHR-RAM initialisation (I'm pretty sure the game writes fresh data to it), but about RAM initialisation (that is CPU $000-$7ff).
Final Fantasy is very well known for NOT initializing RAM to zero, if the routine that loads tiles into CHR-RAM somehow repends on a state that was initialized obscurely by some other routine, I can see perfectly well the hackers changing it to save precious bytes, assuming RAM was initialized to $00 which is the case with 99.9% of emulators, including the most accurate ones like Nestopia, but in fact it's wrong on real hardware : The RAM is initialized mostly with $ff, with some bits randomly clear here and there.
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 12:29 pm
by flagoss
I have seen the same problem before with the Mario Adventure hack that also was not initializing the RAM to "0"s. People were using some Sony Sram chip that were initializing theme self at "0"s on power-up before someone make a patch that added RAM init routine. How hard would it be for someone the add that to this hack also ?.
Re: Grond's Final Fantasy on real hardware
Posted: Wed Apr 09, 2014 3:08 pm
by lidnariq
Running the both the hack and the original in Nintendulator DX, the original reads the following addresses before writing anything to them: $53 $6A $F9 $3C4 $3C5 $3C8 $3C9
The ROM hack adds the following to that: $20 $21$48 $BC $C4 $CB $CC $CE $CF $D4 $DB $F0 (and removes $3C5).
So it seems likely it's garbage in one of those 12 locations that's causing the problems.
Anyway, this is really at the point where you should poke Grond et al.
Re: Grond's Final Fantasy on real hardware
Posted: Thu Apr 10, 2014 3:35 am
by thefox
My new version of NintendulatorDX (not yet released) has an option to randomize memory on power-on, but I couldn't get this hack to fail in the described way (garbage graphics). There are certainly problems with memory initialization though. For example, on some power-ons a garbage note will start playing on the other pulse channel.
Also note that the current release version of NintendulatorDX doesn't log uninitialized accesses to the 6000-7FFF memory area.
EDIT: This hack changes mapper from MMC1 to MMC3. My guess is that mapper initialization is not done correctly. Higan probably uses different default initialization values than other emulators. I've not added mapper initialization state randomization to NintendulatorDX, but I plan to do it at some point.
Re: Grond's Final Fantasy on real hardware
Posted: Thu Apr 10, 2014 4:11 am
by Bregalad
Also note that the current release version of NintendulatorDX doesn't log uninitialized accesses to the 6000-7FFF memory area.
In Final Fantasy's case, it *is* always initialized, from the save file. Although if the hack is badly done, garbage in the save file could trigger bugs as well.
EDIT: This hack changes mapper from MMC1 to MMC3. My guess is that mapper initialization is not done correctly.
Yeah, MMC3+8kb CHR-RAM still have banked RAM, the game should use CHR banks 0-2-4-5-6-7 to work. Most emus will initiate to this state, but Banshaku proved that the real hardware comes up with a different initial configuration, which have the effect to "mirror" tiles across the pattern tables instead of having a fresh 8k to work with.
Re: Grond's Final Fantasy on real hardware
Posted: Thu Apr 10, 2014 10:42 am
by lidnariq
thefox wrote:My new version of NintendulatorDX (not yet released) has an option to randomize memory on power-on, but I couldn't get this hack to fail in the described way (garbage graphics).
The byte at $F9 is a warm boot signature, so pinning that to 0x4D makes fuzzing easier.
This tiny lua script will help with that:
Code: Select all
for i=0,2047 do
RAM[i] = math.random(0,255)
end
RAM[0xF9] = 0x4D
Is there a way to write to MMC registers from the lua bindings? NDX.writeRAM didn't work and nothing else in the source looked obvious.
Re: Grond's Final Fantasy on real hardware
Posted: Thu Apr 10, 2014 12:52 pm
by thefox
lidnariq wrote:The byte at $F9 is a warm boot signature, so pinning that to 0x4D makes fuzzing easier.
I saw fuzzing, but the corruption in higan was much more severe.
Is there a way to write to MMC registers from the lua bindings? NDX.writeRAM didn't work and nothing else in the source looked obvious.
Not currently.