Homebrew blargSnes -- SNES emulator for the 3DS (WIP)

[DiscostewSM]

DiscostewSM I suspect this is the result of a misconfigured HDMA feeding crap into that register.

Do I need a particular save to reach that point?

No need to, because I found out the cause. You are correct that it has something to do with HDMA. In DMA_DoHDMA(), case 0 which involves writing to the PPU, you have a "memaddr++;" line which shouldn't be there. All other cases in that function, such as those that do multiple writes, do not have that line following the sequence of commands at the end of them. I commented it out, and now not only does it fix that issue in the image I posted, but the title screen now displays correctly (for the most part, as the blue haze that should be underneath is missing. It shows up in software mode though) as does the scanline effect when jumping into a battle. It may fix graphical glitches in other games.

 

[Arisotura]

Oh, you're right. Thanks!

 

[DiscostewSM]

Oh, you're right. Thanks!

You're welcome. I do want to note that when I said it looks correct, it's including the implementations I've discussed, like Mode7 flipping and whatnot, so it still may not look correct on your side without them.

 

[DiscostewSM]

I made a small change to PPU.c regarding what happens when a write to 0x2130 and 0x2131 is made (ColorMath1 and ColorMath2). In the spots where it assigns ModeDirty as checked, I also included setting WindowDirty too. This fixes the burning ground in level 1 of Contra 3, as there's a mid-frame change to what color math can affect (in this case, BG2 I believe, which it didn't when beginning the frame).

That's one thing tackled with the 1st level of Contra 3. This other one I'm stumped. In software renderer, at the spot where there is the burning ground, there are buildings in the background. Not just small ones, but bigger ones too. Ever since the hardware renderer was implemented, the big buildings are not appearing. The small ones are. The thing is, after numerous testing, it seems they are both on the same BG layer (BG2), same priority (lesser priority), same mode (Mode1). Another odd thing is that after the burning ground clears on hardware renderer, the big buildings in the background pop back up. I want to say that something is being changed mid-frame, but I can't pinpoint what's causing it.

 

[Memfis]

Do you think, that there is FX-support possible?
Cant wait for the next version.

 

[Arisotura]

Maybe but not for right now.


Also uh, something is off with SPC700 timing, really. I quickly tried making it sync before the CPU reads from the SPC IO ports (instead of just when it writes). DKC2 ran... but SMW didn't. And music in the FF6 intro became garbled crap again.

You know something is wrong when SMW is broken.

 

[VinsCool]

Maybe but not for right now.


Also uh, something is off with SPC700 timing, really. I quickly tried making it sync before the CPU reads from the SPC IO ports (instead of just when it writes). DKC2 ran... but SMW didn't. And music in the FF6 intro became garbled crap again.

You know something is wrong when SMW is broken.

Oh man, let's hope that wouldn't be hard to fix

 

[the_randomizer]

Keep up the good work, man!

 

[Arisotura]

So I found out what's happening with DKC2. Gonna be tricky to fix.

Basically the game uploads its SPC700 program, which is received by the SPC bootrom. Everything is okay so far.

At the end, the bootrom writes to 0xF4 to signal the CPU that it has received the data. Then it jumps to the uploaded code.

Said code immediately initializes the stack pointer and then writes zero to 0xF4. This is where shit gets tricky. If the zero is written before the CPU has read the previous value, the CPU will deadlock, because zero isn't what it expects.

 

[Onion_Knight]

So I found out what's happening with DKC2. Gonna be tricky to fix.

Basically the game uploads its SPC700 program, which is received by the SPC bootrom. Everything is okay so far.

At the end, the bootrom writes to 0xF4 to signal the CPU that it has received the data. Then it jumps to the uploaded code.

Said code immediately initializes the stack pointer and then writes zero to 0xF4. This is where shit gets tricky. If the zero is written before the CPU has read the previous value, the CPU will deadlock, because zero isn't what it expects.

Sounds a little like the sleeping barber problem, execpt another customer comes in and seats in the chair while the first is still getting a cut.

http://en.wikipedia.org/wiki/Sleeping_barber_problem

 

[DiscostewSM]

I've been looking up on what's causing the jitter problem with Secret of Mana in the Mode 7 sections, and it appears that SNES9x 1.52 had this problem too. Prior to 1.53, people were told to launch the emulator with the parameter "-hdmatiming 84" to get by this issue. Looking through the old code of SNES9x, it's an HDMA timing hack, set at 100 by default

Timings.HDMAStart = SNES_HDMA_START_HC + Settings.HDMATimingHack - 100;
Timings.HBlankStart = SNES_HBLANK_START_HC + Timings.HDMAStart - SNES_HDMA_START_HC;

(where.....
SNES_HDMA_START_HC = 1106
SNES_HBLANK_START_HC = 1096
Settings.HDMATimingHack = 100 (default)
)

Normally, Timings.HDMAStart would equal 1106, and Timings.HBlankStart would equal 1096. But, when Settings.HDMATimingHack is equal to 84, Timings.HDMAStart would equal 1090, and Timings.HBlankStart would equal 1080. What this all means? to be honest, I don't really know. Maybe the point when HDMA is triggered? StapleButter may know what this all means, and how to apply a fix (perhaps in the form of a hack when the emulator reads that Secret of Mana was loaded).

 

[Arisotura]

Bleh, I'd avoid adding game-specific hacks as much as possible.

Will have to look into it though.

 

[DiscostewSM]

It's understandable to want to stay away from hacks, but on a system like the 3DS, hacks may be the only way to get these sort of things working. It doesn't have the power that a PC provides to allow such accuracy. Heck, when looking up this information, I also came across info that some games actually alter PPU settings mid-scanline. Yes, you read that right. Not mid-frame, but mid-scanline, while the system is rendering the line, and not at some point within the HBlank.

 

[Arisotura]

Air Strike Patrol does that for its shadow thing. Hah. Maybe this'd work with some kind of hybrid renderer, but bleh.

 

[DiscostewSM]

Uniracers does it too for changing OAM.

 

[MushGuy]

First of all, I finally got to use your emulator, and I must say I like it so far. Second, some error to report while paying Super Mario World. It's in the zip file included. Keep up the good work.

And sorry I wasn't able to take a picture of the error screen. My cell phone sucks.

 

[Arisotura]

You should have taken a screenshot (L+R). Or hell, I could make the crash reporter do that automatically.

The two dump files alone aren't very useful :/

 

[gbazone]

You should have taken a screenshot (L+R). Or hell, I could make the crash reporter do that automatically.

The two dump files alone aren't very useful :/

I know this is far from a formal report, but in Mario All Stars in Mario 3 when you get the first mushroom Mario's sprite disappears completely until you either become small again or manage to get the feather. That's in the official 1.2 build on Smealum's hack.

 

[Arisotura]

I never observed that; a possibility would be frameskip messing with the flickering effect.

 

[DiscostewSM]

StapleButter

You mind if I attempt to improve the ROM menu? I've got the list alphabetized, but I'm thinking of including directory support. My idea was to keep the ROM titles white, but make folders yellow (including "/.."), and order folders first. Perhaps even save the current directory whenever you launch a game or exit out of the emulator. Not looking to design the interface any differently.

I can't think of anything else to help improve the emulator atm, nor anything I want to try and tackle.