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 ?
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.
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.
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 ?
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.
Quote:
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.
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.0I 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 ?
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.
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.
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.
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 ?.
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.
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.
Quote:
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.
Quote:
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.
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:
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.
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.
Quote:
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.
Bregald was correct about the initial state of the CHR-RAM vs the MMC3s CHR banking.
After a bit of code cave exploring, I managed to fit a routine into two spots that will set the correct initial values upon startup.
I have made a pair of patches available here, one to patch a PRG-ROM, and one to patch a NES file.Newer patch
available lower in this page.
[ed: New link]
[ed2: Patch has been fixed, and there is a new link
available lower in this page]
Tested on a real cart on the real hardware and I confirm that it's working !! No more graphics glitchs.
I converted a SMB2 pcb to TNROM, burned the rom and it's wonderfull.
The only little bug that remain is the title screen. It's the same glith that appear when you do a RESET in Nintendulator.
The game is playable and saving work great.
Thanks AWal for the great work!!
Hey AWal, would you mind posting (or if I reposted) the patch to the attachment interface on the forum here?
Nice fix, AWal! Unfortunately it triggers my crude "authorship protection" (for lack a better term) which should make the game crash when entering a battle (odd how no one seems to have noticed yet). If you hadn't overwritten the "Grond1911" right before the vectors it would have worked fine.
If anyone wants to repair the patch themselves before a fixed version is posted, just open it in a hex editor and change 0x3E-46 from "FF FF FF FF FF FF FF FF FF" to "47 72 6F 6E 64 31 39 31 31" or alternatively (if you haven't already applied the patch) delete those nine FFs and change 0x2D from 19 to 10.
Sorry for any inconvenience to anyone who may have already made a cart with this (not to admit fault).
Oh nice, wasn't expecting a response from Grond himself...
I actually
just figured out that you had a signature check in place (debug caught reads to the spot)...And I fully understand why one would want to have something of that sort in the file.
As expected, I have uploaded a fixed version of the patch that can be obtained
here.
Well sorry for having only taken 5min to test the patch on real hardware. Will desolder the eprom tonight and test the new version !
Just to let everyone know, the patch is working well. There is some graphical glitch remaining at the title screen but nothing major. I finished the game and it is 100% playable.
Thanks to AWal for the patch !