It is currently Tue Jul 16, 2019 5:44 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 206 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14  Next
Author Message
PostPosted: Sat Jul 06, 2019 12:56 pm 
Offline

Joined: Mon Jul 01, 2019 9:00 pm
Posts: 20
Found what's wrong about Dekitate H.S. It does H-DMA[5] at line 0 to PPU 212c which turns on bg2 mainscreen.

But it's doing this in the middle of a DMA from 240 to 41. Mesen-S can't simulate this yet?


Top
 Profile  
 
PostPosted: Sat Jul 06, 2019 2:34 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1498
Ken Griffey Jr. also needs SRAM initialized to 0xFF or you get gibberish in the menus.

The only exception is the Power Slide FX demo that must be initialized to 0x00 or it crashes.

I just let Power Slide FX crash currently and use 0xFF.

The more proper solution that people will hate is, games should be distributed with pre-initialized and blank SRAM files. Would also handle the Codemasters device with code stored in the SRAM. But for now, just do 0xFF yeah.

Quote:
But it's doing this in the middle of a DMA from 240 to 41. Mesen-S can't simulate this yet?


Mesen-S can't run HDMA inside a DMA? That ... would break everything. Do you just mean it's not syncing the PPU up during this combination of DMA+HDMA?

Side note: both DMA and HDMA do CPU<>DMA sync. But HDMA inside DMA doesn't need to sync again, and won't. The CPU revision 1 crash starts to make sense why it might be a problem with that in mind.


Top
 Profile  
 
PostPosted: Sat Jul 06, 2019 3:02 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 189
Location: Germany
byuu wrote:
games should be distributed with pre-initialized and blank SRAM files. Would also handle the Codemasters device with code stored in the SRAM

This could also be handled by the manifest which would specify the default content.

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Sat Jul 06, 2019 3:10 pm 
Offline

Joined: Mon Jul 01, 2019 9:00 pm
Posts: 20
[quote="byuu"]Mesen-S can't run HDMA inside a DMA? That ... would break everything. Do you just mean it's not syncing the PPU up during this combination of DMA+HDMA?[/code]

I'll describe what I'm seeing happen in bsnes.

lda #$02
sta $420b
V:240 -> 016

At V:240, bg2 main screen is off. And right after the dma is finished, bsnes says bg2 main screen is on. There's some h-dma 5 active that supposedly keeps writing to 212c.

With Mesen-S, it shows some big black bar on top of the screen (missing bg2 layer). But snes9x and bsnes does not have this problem.

I don't really get it all. :laughing:


Top
 Profile  
 
PostPosted: Sat Jul 06, 2019 3:19 pm 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 706
klurey wrote:
Found what's wrong about Dekitate H.S. It does H-DMA[5] at line 0 to PPU 212c which turns on bg2 mainscreen.
Yep, took me a little bit to figure this one out, too. Thanks for taking the time to investigate!

byuu wrote:
Mesen-S can't run HDMA inside a DMA? That ... would break everything.
It wasn't working properly - it would only interrupt DMA to run HDMA if it was on the same channel as DMA. But in this case, HDMA is on another channel, and it ended up running after DMA completed. I guess very few games depend on this? (surprisingly?)
It's fixed now. I also spent some time triple-checking the logic and timing compared to higan and I think it should be pretty close now (including the lack of sync when HDMA interrupts DMA, etc.)

I also implemented the read being 4 master clocks earlier than the writes, and this fixed Rendering Ranger R2. It could be a coincidence, though, but I'll take it!

RE: Super Famista, I added a "power on ram state" option (same as Mesen), which applies to all ram (vram, cgram, oam, work ram, save ram). It defaults to $00, though. Eventually I'd like to default it to random, maybe with some overrides for SRAM for the games that require it? Didn't set it to random just yet because random will require a bit more thought when it comes to recording/playing movies (though movies aren't implemented yet, so I guess I should have gone for random...)

With this, the games that still freeze are down to Battle Grand Prix & Kishin Douji Zenki - Tenchi Meidou. It's likely that there is more, but those are the only 2 I'm aware of.
And then graphic glitches in ASP, Warlock and NHL 94 + mosaic is still broken.

Edit: Also, the emulator now outputs 256x239 frames when there is no high resolution content on that frame, which allows the graphic filters to work a lot better than before.


Top
 Profile  
 
PostPosted: Sun Jul 07, 2019 1:46 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 189
Location: Germany
Sour wrote:
I added a "power on ram state" option (same as Mesen), which applies to all ram (vram, cgram, oam, work ram, save ram). It defaults to $00, though. Eventually I'd like to default it to random, maybe with some overrides for SRAM for the games that require it? Didn't set it to random just yet because random will require a bit more thought when it comes to recording/playing movies (though movies aren't implemented yet, so I guess I should have gone for random...)

They could store the RNG seed.

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Sun Jul 07, 2019 4:21 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1498
creaothceann wrote:
This could also be handled by the manifest which would specify the default content.


A) I don't include unlicensed games in my own database, so it wouldn't help with the one game that needs 0x00.
B) this won't handle any hypothetical cases that need more than a single fixed value (eg the Codemasters example, though that's not an SNES game.)
C) Sour doesn't support manifests (and shouldn't ... at least not yet, that format is obscenely unstable.)

Sour wrote:
Edit: Also, the emulator now outputs 256x239 frames when there is no high resolution content on that frame, which allows the graphic filters to work a lot better than before.


A gimmick I used to do many years ago was sub-divide the screen into lores and hires regions, and pass an array of line widths into my video filters. This would let HQ2x continue to render the game content the same way when hires textboxes showed up in various JRPGs.

Without this, if the user is using bilinear interpolation on video scaling to the screen (eg GL_LINEAR), games will suddenly appear sharper when textboxes appear, and become blurrier when they go away.

But oh boy was that a whole mess of annoying code to maintain. It gets out of hand very fast when you have 15+ video filters, HD mode 7, pixel shaders, etc.


Top
 Profile  
 
PostPosted: Sun Jul 07, 2019 7:50 am 
Offline

Joined: Mon Jul 01, 2019 9:00 pm
Posts: 20
Super 4WD - The Baja (Japan)
- error: in-game Mode 7 flickers mad crazy


Code:
$80/EB86 AE 11 42    LDX $4211  [$80:4211]   A:0000 X:0008 Y:00EF D:0000 DB:80 S:0B72 P:envmXdIzC HC:0964 VC:030 FC:01 I:01
$80/EB89 CB          WAI                     A:0000 X:00C2 Y:00EF D:0000 DB:80 S:0B72 P:eNvmXdIzC HC:0994 VC:030 FC:01 I:01
$80/EB8A E2 30       SEP #$30                A:0000 X:00C2 Y:00EF D:0000 DB:80 S:0B72 P:eNvmXdIzC HC:1018 VC:030 FC:01 I:01


I think the wai is a hv-irq trigger. But Mesen-S blows right by it for a whole frame or two.


Top
 Profile  
 
PostPosted: Sun Jul 07, 2019 11:55 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 189
Location: Germany
byuu wrote:
creaothceann wrote:
This could also be handled by the manifest which would specify the default content.


A) I don't include unlicensed games in my own database, so it wouldn't help with the one game that needs 0x00.
B) this won't handle any hypothetical cases that need more than a single fixed value (eg the Codemasters example, though that's not an SNES game.)
C) Sour doesn't support manifests (and shouldn't ... at least not yet, that format is obscenely unstable.)

I meant manifests in general. Text files can store anything; it's just a matter of finding a good syntax. (Even the whole ROM library could (theoretically!) be stored like that.)

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Sun Jul 07, 2019 4:32 pm 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 706
klurey wrote:
Super 4WD - The Baja (Japan)
- error: in-game Mode 7 flickers mad crazy
Turns out this was the same problem as issues I found during the day today. I implemented a cycle-by-cycle version of the mul/div operations a couple of days ago, and forgot a "break;" somewhere, which broke a few games that used the division registers + H-IRQs. Should be fixed now (also affected Jurassic Park & ASP)

I just finished implementing what should be a fairly cycle-accurate fetch/render sequence for the PPU (for mode 0-6 backgrounds). This fixes the "Good Luck" text in A.S.P. and the glitch at the top right in Warlock.
I haven't implemented this for mode 7 (yet) and sprites - those are the next things I'm hoping to get done. Implementing it for mode 7 should hopefully fix the minor glitches in NHL 94's intro.

I might have broken the rendering logic for some things with all this - I tried testing most of the games I knew that used graphic modes that aren't too common and fixed everything I could find.

byuu wrote:
A gimmick I used to do many years ago was sub-divide the screen into lores and hires regions, and pass an array of line widths into my video filters. This would let HQ2x continue to render the game content the same way when hires textboxes showed up in various JRPGs.
Yea, that sounds like a fair amount of work for the handful of titles that would really benefit from it, heh. Might try doing this someday, but I think this is good enough for now. Though, I might setup xBRZ to run in a few different threads, since it can't even pull off 60fps at the moment in 512x478.


Top
 Profile  
 
PostPosted: Sun Jul 07, 2019 9:43 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1498
Oh hey if you want to hate me ... :P

https://archive.org/details/Bsnes-emula ... omparisons

These were some older, stubborn bugs I had with bsnes way back in the day.

Quote:
I just finished implementing what should be a fairly cycle-accurate fetch/render sequence for the PPU (for mode 0-6 backgrounds).


That sounds promising! I mostly went off observed cases of real-world games, and made it easy to adjust the timings as we learn more.

We really, really, really need someone with a logic analyzer to work out these timings for us. A person who shall remain nameless promised to do that in return for me helping them with their emulator, but then never released their notes :c

Quote:
Though, I might setup xBRZ to run in a few different threads, since it can't even pull off 60fps at the moment in 512x478.


You could always try the good old-fashioned "#pragma omp parallel for" line above the for(y=0;y<height;y++) line trick ^-^;

I had good results with snes_ntsc and HQ2x, but it ended up hurting speed with all the other filters.


Top
 Profile  
 
PostPosted: Sun Jul 07, 2019 10:56 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8476
Location: Seattle
byuu wrote:
We really, really, really need someone with a logic analyzer to work out these timings for us.
What precisely do you want recorded?


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 1:51 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1498
This is the key problem: I don't really know ... I'm not good at the hardware side at all.

I'm hoping to get something like a cycle-by-cycle guide of when VRAM/OAM/CGRAM fetches occur and where, that we can then reverse into something meaningful. More than likely, one carefully designed test won't cut it, and the fetch patterns will change based on different PPU register settings.

I don't think we're going to be able to see things like PPU register latches, but at least once we have the fetch timing down, we can start devising tests to suss out when the register latching occurs.


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 3:56 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21501
Location: NE Indiana, USA (NTSC)
Sour managed to dig up the following links on the SNESdev Discord server. What else is needed?

AWJ's trace on A14-A12
lidnariq's additional traces

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 5:24 am 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 706
byuu wrote:
These were some older, stubborn bugs I had with bsnes way back in the day.
Thanks! Looks like I'm ok on those, except NHL 94. I think NHL 94 is probably due to either the matrix calculation being refreshed mid-frame or the tiles not being fetched ahead of time like I just did for modes 0-6.

RE: Fetch timing, I spoke about this w/ lidnariq in PMs, too, and so far the best theory I have is that prefetch for the tiles start at H=0: (this is assuming anomie's information about the pixels being rendered from H=22 to H=277 is correct)

H=0-263 = tilemap/tile fetch
H=264-271 = 8 idle cycles (like the threads tepples linked mention)
H=272-339 = sprite chr fetches
H=340 = idle

If the rendering starts a H=22, the tilemap fetching MUST start at least at H=6 at the latest, or it won't finish in time for the first pixel (so H=0 to 6 are the possibilities), and then the only values that don't require the sprite fetching to be split across 2 different scanlines are if tile prefetch starts at either H=0 or H=1.

This also makes sense compared to anomie's info:
anomie wrote:
The PPU seems to access memory 2-3 tiles ahead of the pixel output. At least, when we disable Force Blank mid-scanline, there is garbage for about 16-24 pixels.

With H=0, the graphical glitch in that appears at the top right of the screen in Warlock disappears completely (at H=6, it still shows up on some frames). Both H=0 and H=6 work fine for the "good luck" text in A.S.P. Still need to implement the fetching for sprites and see how that works out with Mega Lo Mania (and that test rom posted earlier in this thread).

My implementation is here atm: https://github.com/SourMesen/Mesen-S/bl ... u.cpp#L266
The fetch patterns should match the info AWJ and lidnariq provided in the threads linked.

I'd assume that CGRAM fetches are done at the time of the pixel's rendering (which may start a few dots before H=22 if this is similar to the NES which had a 2-3 dot delay between pixel rendering & pixel output? pure speculation, though.). OAM evaluation is a tough one (I'm assuming it's all internal to the PPU?), I'm assuming the process ends up using latches (or a "secondary OAM"?) to hold the tile indexes that need to be fetched after the background data is done?
I think I recall a thread somewhere that had some info about the oam logic, will need to see if I can find it again.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 206 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group