It is currently Sun Nov 17, 2019 2:22 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 270 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14, 15, 16 ... 18  Next
Author Message
PostPosted: Mon Jul 08, 2019 5:27 am 
Offline

Joined: Sat Jun 18, 2011 10:50 am
Posts: 20
Code:
0: N4 -> N3 -> N2 -> N1 -> P4 -> P3 -> P2 -> P1
1: N3 -> N2 -> N1 -> P3 -> P2 -> P2 -> P1 -> P1
2: N2 -> N1 -> 03 -> 03 -> P2 -> P2 -> P1 -> P1
3: N2 -> N1 -> P2 -> P2 -> P1 -> P1 -> P1 -> P1
4: N2 -> N1 -> 03 -> P2 -> P1 -> P1 -> P1 -> P1
5: N2 -> N1 -> P2 -> P2 -> P1 -> P1 -> P1 -> P1
6: N2 -> N1 -> 03 -> 03 -> P1 -> P1 -> P1 -> P1

[  0,263] Background sequences? There are 33 of them per line.
[ 16,271] Renderer needs 2 sequences buffered because of how fineX works.
[ 16,271] If BG2 is empty or lower priority, ExtBG can be used instead.
[264,271] But that would mean there is nothing new on the bus for ExtBG to use?! (^_^)
[ 16,271] Mode7 BG1 aligns with ExtBG so Mode7 pattern fetches must align with ExtBG.
[272,339] Final 68 dots are reserved for sprite tile fetches. (x_x)


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 12:58 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 734
So a bit of tinkering later, I also changed the code to read the tile data for sprites from H=272 to 339.
I arbitrarily put "sprite evaluation" (e.g the part that decides which tiles need to be loaded) at cycle 270 (in reality I imagine this runs from early on in the scanline until close to H=272).

This makes Mega Lo Mania work properly, and the "HblankEmuTest" rom correctly displays the "this is correct behavior" message (this was broken until now).

I also partially fixed the mosaic effect - I *think* it should be working properly now for standard resolution modes. (It's completely broken in high res, still).


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 3:00 pm 
Offline

Joined: Fri Nov 18, 2016 7:57 am
Posts: 22
Sour wrote:
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.


What I observed during my testing was that Sprite evaluation starts at the beginning of the scanline for 256 cycles so there is a gap between evaluation & fetching.

Enabling force-blank during evaluation pauses it. Then if you write the OAM address and disable force-blank, evaluation will start from that OAM address.

Strange things happen when disabling force-blank during evaluation on certain OAM addresses and cycles: sometimes no sprites are in-range anymore after the ones which were in-range before enabling force-blank.

During evaluation it writes the in-range sprite indexes to memory. There is some kind of memory in the middle of PPU1 which is 32x8bits (Hi-OAM) & 32x7bits (in-range sprite indexes).

Sprite fetching reads OAM data of the in-range sprite indexes again. It continues with sprite fetching and decrementing the current sprite index if you enable force-blank. There is some garbage for a few pixels when enabling force-blank during fetching. Other sprites fetched during force-blank are invisible. Writing to the OAM address has no effect.

Writes to 2104 during evaluation and fetching go to OAM & Hi-OAM (Reading both at the same cycle maybe?)

Sour wrote:
This makes Mega Lo Mania work properly, and the "HblankEmuTest" rom correctly displays the "this is correct behavior" message (this was broken until now).


Are you aware HblankEmuTest displays half correct / half incorrect horizontally on an NTSC SNES?


Last edited by paulb_nl on Mon Jul 08, 2019 3:18 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 3:06 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1533
tepples wrote:
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


There's an SNESdev Discord? How many of these things are there? Heh.

Anyway that's really good info, thank you!

Quote:
Are you aware HblankEmuTest displays half correct / half incorrect horizontally on an NTSC SNES?


While we're at it, does Warlock have that glitch on hardware? Should probably verify ...


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 3:14 pm 
Online
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4213
Location: A world gone mad
byuu wrote:
There's an SNESdev Discord? How many of these things are there? Heh.

The SNR on these Discords tends to be extremely poor; be on the lookout for time vampires at all costs.


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 3:40 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 734
Thanks a lot for the sprite evaluation info!
Seems a bit similar to the NES, including the part where disabling rendering at any point messes everything up.
This might actually be enough info to change my implementation a bit and try to roughly match this.
I excepted the OAM to only be read once (during evaluation), but I guess there is actually enough time to read it again during fetching (2 dots per OAM entry, which is the same rate as the 2 dots per tile fetch it needs). This probably explains some of the 8 idle cycles between background fetches and sprite fetches? It would need to load at least 1 OAM entry ahead of time before the fetching starts.
paulb_nl wrote:
Are you aware HblankEmuTest displays half correct / half incorrect horizontally on an NTSC SNES?
Nope, thanks for pointing it out. Guess it goes back on the "doesn't quite work yet" pile :p


RE: Warlock, validating that the game has no glitches would probably be a pretty good indicator that tile fetching starts at H=0.


Top
 Profile  
 
PostPosted: Tue Jul 09, 2019 3:40 am 
Offline

Joined: Fri Nov 18, 2016 7:57 am
Posts: 22
I posted captures of HblankEmuTest on SNES consoles here: viewtopic.php?p=231279#p231279

Apparently it was YourEmuSuxx.sfc that has half correct/incorrect on NTSC & correct on PAL.
HblankEmuTest.sfc has half correct on both NTSC & PAL.


Top
 Profile  
 
PostPosted: Tue Jul 09, 2019 3:23 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1533
Yep, that's the danger of test ROMs.

Few of us have access to run them on real hardware, and just assume they're right, and in 'fixing' them, end up breaking other things.

Even the best of us with real hardware miss details. Most Game Boy test ROMs only pass on certain CPU revisions, or fail on only certain revisions. The Game Boy scene has begun tagging which systems a given test ROM passes or fails on. The SNES space should probably start doing the same.


Top
 Profile  
 
PostPosted: Tue Jul 09, 2019 4:16 pm 
Online
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4213
Location: A world gone mad
byuu wrote:
Even the best of us with real hardware miss details. Most Game Boy test ROMs only pass on certain CPU revisions, or fail on only certain revisions. The Game Boy scene has begun tagging which systems a given test ROM passes or fails on. The SNES space should probably start doing the same.

I have been told on nesdev Discord, re: SNES, that those versions reported via MMIO registers do not accurately reflect actual changes done to the ICs at the transistor level by Nintendo, i.e. there are several "sub-revisions" of, say, PPU1 rev 2, where they all behave slightly differently. True or false?

If true, I'm not sure how one would be able to reliably determine this through software, and requiring testers to disassemble their consoles (and I don't just mean take the shell off; to get at IC silkscreenings (if relevant at all!) you have to take EVERYTHING apart) seems ridiculously extreme...


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 1:12 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1533
Nintendo used the revision codes at first.
CPU revision 1 and 2 have differences, a few of which I emulate (DRAM refresh trigger point, HDMA init trigger point), a few of which I don't (DMA<>HDMA crash fix, probably more I don't know about.)
PPU1 is always revision 1.
PPU2 has revisions 1, 2, and 3. 2 is very rare, and I don't own one.
I have yet to find a difference between PPU2 revisions 1 and 3, but they likely exist.

After this, Nintendo stopped bumping the revision register values.
The big revision after this is the 1CHIP. I like to jest that it's more of a clone console than an SNES, ala the Genesis 3.
They completely break the display brightness register (takes multiple lines to stabilize!), and there are several compatibility issues.
The 1CHIP is actually two chips: one is the CPU+PPU1+PPU2, and the other is the SMP+DSP. Probably Sony wouldn't give them the schematics/Verilog/Asic/whatever-have-you for the SMP+DSP, I don't know. It makes a wonderful black box as you know, I wish more systems worked like that (cough Sega, cough.)
The SMP timer glitch disappears with this revision. The SMP never had a version register anyway, though.

The SNES Jr. potentially has more revisions, but I don't know of any differences between the big 1CHIP-(01,02,03) and the Jr boards.

If someone can run a test on real hardware, we could verify the newer revisions by the PPU brightness bug or the SMP timer fix.

It's pedantic, I know, but as you saw, Sour just fixed a test ROM that's supposed to fail. I did as well when this was first reported. So it is a valid concern ...


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 8:46 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 734
Alright, so after a couple of days trying to figure out sprite evaluation & fetching, I think I've got something that's starting to be relatively decent (but it doesn't quite 100% match the hardware, according to the tests)

I've based a lot of this on the info in these threads:
viewtopic.php?f=12&t=18447
http://forums.nesdev.com/viewtopic.php?p=231279

As well as this GitHub issue (and test rom): https://github.com/MiSTer-devel/SNES_MiSTer/issues/69
And also this VHDL implementation: https://github.com/MiSTer-devel/SNES_Mi ... rc/PPU.vhd

Huge thanks to paulb_nl for all the time you've obviously spent trying to figure out these details! :)

What I have at the moment looks like this (some of this are guesses - not actual hardware-verified behavior):
H=0-255: Sprite evaluation:
Even cycles: Read X+Y (word) + high oam value
Odd cycles: Write sprite index in the 32-entry 7-bit table (if the sprite is visible on the line)

H=0-263: BG tilemap+tile fetching
H=22-278: Rendering

H=270-337: OAM reading to determine which VRAM addresses need to be fetched (starting from the last sprite index stored during evaluation)
Even cycles: Read X+Y (word)
Odd cycles: Read 2nd word (priority, palette, etc), determine the VRAM address to load on the next cycle. If all tiles for this sprite have been processed (e.g based on its width), move on to the next sprite index in the sprite evaluation table.

H=272-339: VRAM fetches for the sprites
Even cycles: Read first word of sprite tile, based on the address calculated on the previous cycle
Odd cycles: Read the 2nd word of the sprite tile

I've tried to keep track of as many details as I could find (but I'm sure I'm missing a few things).
The HBlankTest & "YourEmuSuxx" tests both look half corrupted in both PAL/NTSC. It's far from perfect, but closer than before.
paulb_nl's sprite_oam_test_short_fblank test rom seems to be behaving pretty close to what is seen in his youtube video.

With these changes, Uniracers now runs properly without having to add a hack-ish solution to make it work.
Also, the "lamp" at the top of the screen in Aladdin is correctly missing the first row of pixels due to the game disabling rendering during hblank (as mentioned here: http://forums.nesdev.com/viewtopic.php?p=231483#p231483)

byuu wrote:
It's pedantic, I know, but as you saw, Sour just fixed a test ROM that's supposed to fail.
I'm hoping to eventually get around to gathering them up either on a wiki page or github repo and defining their expected results (on different consoles, when it matters). At least that way there would be a central place to get information on the tests that exist, rather than finding them on random websites, repos and forum threads. Might be a while before I can find the time, though.


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 11:53 pm 
Offline

Joined: Wed Jul 10, 2019 11:34 pm
Posts: 5
Sour wrote:
I'm hoping to eventually get around to gathering them up either on a wiki page or github repo and defining their expected results (on different consoles, when it matters). At least that way there would be a central place to get information on the tests that exist, rather than finding them on random websites, repos and forum threads. Might be a while before I can find the time, though.

I don't know that much about SNES emulation, but I am interested in archiving. I've got a test ROM repository with a bunch of the ROMs from this thread, plus some from the tukuyomi archive. SNES Central also has a bunch of test ROMs on the Homebrew page, which I haven't added to my repo yet because I'd have to figure out how to scrape the website.

I'd love to get corrections, suggestions or even contributions. Alternatively, if you want to take the things I've collected and make your own wiki/repo/whatever, that's cool too.


Top
 Profile  
 
PostPosted: Thu Jul 11, 2019 1:59 am 
Offline

Joined: Fri Nov 18, 2016 7:57 am
Posts: 22
Sour wrote:
Alright, so after a couple of days trying to figure out sprite evaluation & fetching, I think I've got something that's starting to be relatively decent (but it doesn't quite 100% match the hardware, according to the tests)


Great work. Nice to see you adding cycle by cycle sprite evaluation.

My OAM test is basic because I am terrible at SNES coding. Would be great if someone could make a proper OAM test rom that displays the current OAM address/data at every cycle.


Top
 Profile  
 
PostPosted: Thu Jul 11, 2019 8:33 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1533
Long ago, I made a test that at one point filled out OAM with some sort of pattern, and then hammered writes at every single clock cycle (one at a time of course), read out the OAM, and evaluated it to find where the write ended up going to, which I believe reveals what the PPU was actually evaluating at a given cycle. (And a similar test with CGRAM.)

The Hblank write results are loosely based around those findings, but the issue I had in trying to complete an evaluator this way was that it only handled a simple sprite pattern table. What would happen if FirstSprite was different, if sprites overlapped, if we hit range/tile over, if we toggled force blank in the middle of a scanline, if there were transparent sections in certain sprites, on and on ... there could be millions of combinations, and trying to suss out what actually mattered to timing and what didn't was too daunting.

You could also reveal information from reads in this same manner, but now you're back to that aforementioned issue with "what clock cycle within reads/writes do things happen on?", which if you follow Game Boy emulation, is very far from trivial in practice.

Timing this stuff to cycle accuracy is the easy part. Getting the actually correct cycle positions for these things is the brutally hard part. I didn't see it as worthwhile to guess something that might be a little closer, but was still not correct, unless it has a discernible benefit to emulation. I've never made a secret of it that PPU timings are my Achilles' Heel due to not being able to test most of it.

Of course, there's a real possibility that I've approached the PPU wrong, so it's great to have a new approach here. What you're doing so far is really impressive work! :D


Last edited by byuu on Thu Jul 11, 2019 9:37 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Jul 11, 2019 9:35 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 734
Screwtape wrote:
I've got a test ROM repository with a bunch of the ROMs from this thread
Ah, that's a good start. Good to know something like this exists!

paulb_nl wrote:
Would be great if someone could make a proper OAM test rom that displays the current OAM address/data at every cycle.
Sadly, I'm not really qualified for that!

Also, while I like accuracy as much as anyone, I do need to worry about performance, esp. considering that the debug tools do have a decent overhead when they're opened - and nobody is going to want to use a debugger that can't even run at 60fps. So there are certain things I will probably not realistically be able to add. That being said, there's never any harm in learning more about the hardware's actual behavior.

byuu wrote:
Timing this stuff to cycle accuracy is the easy part. Getting the actually correct cycle positions for these things is the brutally hard part.
I agree - and like I said above, there are limits beyond which I'm not really able to go. I mostly only gave this a shot because I had to implement the bg fetching logic to fix A.S.P's "Good luck" text and I figured I might as well try and see how much of an impact sprite evaluation would have on performance. I haven't been keeping track too closely, but I think between the background and sprites, performance is probably down 10-15%ish. I'll keep it in for now, but eventually might have to make this kind of behavior optional if performance becomes a problem (it's already not that great..)


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 13 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