It is currently Tue Dec 18, 2018 6:32 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 202 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11 ... 14  Next
Author Message
PostPosted: Sat Oct 29, 2016 9:31 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 428
Location: FL
Just to prove that this project is still alive, here's a spiffy new overhaul of the VRAM viewer, much thanks to UnDisbeliver:

Image

Very well timed, too, because I've been gearing up to work on some other new graphics-related features (tilemap viewer, etc.) Now that I'm focusing on actual features again, another release should finally be not too far off.


Top
 Profile  
 
PostPosted: Sat Oct 29, 2016 10:53 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 771
Awesome! That'll be super helpful debugging msu-1 video code. While you're at it, I hope you can fix up that issue where the PPU registers dialog is blank in the accuracy profile.


Top
 Profile  
 
PostPosted: Sat Oct 29, 2016 11:27 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 719
Location: New Mexico, USA
Revenant wrote:
Just to prove that this project is still alive, here's a spiffy new overhaul of the VRAM viewer...
Sweet, so excited!! Nice work! :D
qwertymodo wrote:
I hope you can fix up that issue where the PPU registers dialog is blank in the accuracy profile.
I second that!

I've also found some other bugs:
1) The upper byte of the Bus-B address for all of the DMA channels on the S-CPU tab of the Properties window is shown as $00. It should be $21.
2) The H-counter/V-counter registers ($213C-D) in the S-PPU tab of the Properties window seem to be totally broken. They should only update when $2137 (Soft Latch) is read or by setting-and-clearing bit 7 of $4201. Instead, the H-counter seems to be stuck permanently at 0 and the V-counter updates continuously with the current scanline number.

I also have a few enhancement requests that I might as well throw out there:
1) Would be totally outstanding if you could add buttons in the Debugger window for "Run to next Vblank" and "Run to next Hblank". That would be super powerful.
2) The S-CPU tab in the properties window is missing a number of register values that would be very useful to have. Specifically $4210-4212 and $4214-421F.
3) I wonder if you could change the "H" count value in the Debugger window log to show the actual Dot number value as opposed to the master cycle count value. Right now the count displayed is always [current Dot number * 4] (each dot is 4 master cycles). It seems odd that the "V" count is the scanline number as expected but the "H" count isn't the Dot number...?
4) Would be a little nicer if the "Direction" value for each of the DMA channels in the S-CPU tab of the Properties window said either "A->B" or "B->A" instead of "true"/"false". True/false doesn't make much sense for a direction value.


Top
 Profile  
 
PostPosted: Sun Oct 30, 2016 11:27 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 428
Location: FL
I'll get around to fixing up the properties window soon, along with some of jwdonal's suggestions, and some other stuff like additional S-SMP properties (timer info, etc).


Top
 Profile  
 
PostPosted: Mon Oct 31, 2016 9:24 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 428
Location: FL
Alright, made the aforementioned fixes to the properties view, and changed the log window to display the H-counter in dots instead of cycles. Should be pretty consistent (and useful) across all three profiles.


Top
 Profile  
 
PostPosted: Tue Nov 01, 2016 3:23 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1391
Hcycle is much more useful for timing code than Hdot is.

It sounded like the problem was that you were reporting the real-time values instead of the latched values.

You should report the real-time Vcounter, Hcounter values somewhere prominent (like in the CPU tracer); plus the latched VCOUNTER, HDOT values in the register/properties viewer. Be sure to use the CPU version, as the Hcounter values are meaningless in the scanline-based renderers.

Very nice VRAM viewer, by the way!


Top
 Profile  
 
PostPosted: Tue Nov 01, 2016 8:53 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 428
Location: FL
The latched values are what the properties window now shows, with the tracer showing the real-time values. The latter is the same as before, just with hdot instead of hcounter.

I feel like having the log window express horizontal position in the same units that the latch and IRQ registers use is more intuitive/useful the majority of the time, but the properties window should probably still show the realtime hcounter value (and current lineclocks) for more advanced timing applications.

Or, maybe I should just add another config setting to let the user decide which value the debug window shows.


Top
 Profile  
 
PostPosted: Tue Nov 01, 2016 11:31 am 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 719
Location: New Mexico, USA
Revenant wrote:
Or, maybe I should just add another config setting to let the user decide which value the debug window shows.
This please. :) But of course beggars can't be choosers either. I'm just happy to have this amazing SNES debugger available at all!


Top
 Profile  
 
PostPosted: Fri Nov 04, 2016 11:26 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 719
Location: New Mexico, USA
byuu wrote:
Hcycle is much more useful for timing code than Hdot is.
Having thought more about this I agree with byuu, but I also still think that it makes more sense to have the 'H' value in the debugger log be the actual dot number and not the cycle number. But at the same time I think knowing the cycle number is also important and you could very simply add a "CYC:#" in each debug log entry.

I realize now that this is actually really important because looking at some of my logs I just realized that the Hcycle value is not always an exact multiple of 4 of the dot count. So you can't just take the current Hdot count, multiply by 4, and always get the correct Hcycle count. So I think the best approach would be to have this in the debugger log:
Code:
<blah blah> V:# H:# CYC:# <blah blah>


Top
 Profile  
 
PostPosted: Sat Nov 05, 2016 3:06 am 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 433
jwdonal wrote:
byuu wrote:
Hcycle is much more useful for timing code than Hdot is.
Having thought more about this I agree with byuu, but I also still think that it makes more sense to have the 'H' value in the debugger log be the actual dot number and not the cycle number. But at the same time I think knowing the cycle number is also important and you could very simply add a "CYC:#" in each debug log entry.

I realize now that this is actually really important because looking at some of my logs I just realized that the Hcycle value is not always an exact multiple of 4 of the dot count. So you can't just take the current Hdot count, multiply by 4, and always get the correct Hcycle count. So I think the best approach would be to have this in the debugger log:
Code:
<blah blah> V:# H:# CYC:# <blah blah>


The SNES has two separate h-counters (and two v-counters), one on the CPU and one on the PPU. When you latch the counters (by any method) and poll them it's the PPU counter you're reading, but IRQs are based on the CPU counter. The PPU counter has 340 dots, but on most scanlines a couple of the HBlank dots are stretched, so it takes 1364 master clocks to count from 0 to 339. The CPU counter has no stretched dots (every dot is exactly 4 master clocks) but it seems to count from -1 to 339 (or -1 to 338 on the short scanline without stretched dots). (I write "seems to" because you can't poll the CPU counter on a real SNES, but if you enable an H-IRQ with a position of 340 it'll never fire)

Because there are two counters with different behaviours, the meaning of "the actual dot number" is ambiguous.


Top
 Profile  
 
PostPosted: Sat Nov 05, 2016 5:22 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1391
> The PPU counter has 340 dots, but on most scanlines a couple of the HBlank dots are stretched, so it takes 1364 master clocks to count from 0 to 339.

Yep, two of them are like that. It varies per system and sometimes per power cycle, but is usually ~322 and ~326 that are two clock cycles "longer" for some reason. I've seen it be 321+325 (rarely) and 323+327 (most often.)

With the exception of scanline 240 on odd frames when not in interlaced mode, where those dots are of normal length. I hear there's a case like this in PAL too, but I haven't timed that out yet to confirm. You'd have to ask nocash.

Such a pain in the ass system :P

> The CPU counter has no stretched dots (every dot is exactly 4 master clocks) but it seems to count from -1 to 339

I prefer to think of it as a propagation delay. You see it take more cycles (4, I believe?) when you enable H+V IRQs as opposed to just V IRQs, for instance.

> Because there are two counters with different behaviours, the meaning of "the actual dot number" is ambiguous.

Even worse is that, due to performance requirements, the CPU and PPU counters are almost never truly in perfect sync (aside from the obvious long-dot differences) between the two, because one processor thread is ahead of the other under emulation. And with the balanced/performance cores, the PPU Hcounter is basically 'frozen' on account of it being a scanline-based renderer.


Top
 Profile  
 
PostPosted: Sat Nov 05, 2016 6:04 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
byuu wrote:
With the exception of scanline 240 on odd frames when not in interlaced mode, where those dots are of normal length.

At least on NTSC, that's supposed to be there to control variation of the color burst phase from one field to the next. The NTSC color subcarrier is 6 qpels wide; PAL is 4.8.

Quote:
I hear there's a case like this in PAL too, but I haven't timed that out yet to confirm. You'd have to ask nocash.

His doc says NTSC has a short (1360 qpel) line 240 in field=1 of 240p and PAL has a long (1368 qpel) line in field=1 of 576i.

Quote:
Such a pain in the ass system :P

It'd be even more of a pain visually if each field had the same phase, like most pre-PlayStation NTSC consoles other than the NES, SNES, and TG16. The PAL NES and PAL SNES output is "dirty" in much the same way as the NTSC Neo Geo AES output because the artifacts appear in the same position each frame rather than crawling the way they do on TG16, PlayStation, N64, and later consoles.

There's probably some cost cutting as well. The PPUs of both the NTSC NES and NTSC Super NES could generate only 1360 or 1364 qpels, presumably because some of the timing logic operates on a pixel basis. If they had a bit more resources, they could have had it generate a 240p signal with 1364 qpels on lines 240-242 and 1365 qpels on all other lines, for a total of 357627 qpels (59604.5 subcarrier cycles) per field. That'd at least give a closer-to-standard dot crawl in 240p mode. And 480i mode with all 1365 all the time would have been exactly standard timing.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 10:49 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 428
Location: FL
Responding to a post in a different thread to avoid derailment:

koitsu wrote:
1. BG VRAM addresses (ex. $2107 to $210a bits 7-2) were shown in bytes not words (ex. $7000 instead of $3800) -- I kept wondering why all the values were 2x larger than what I expected. It's a matter of preference which is "accurate"; IMO, I'd show both, but with notation of words vs. bytes for both

This is something from the old stock v073 debugger that I have wanted to change for a while now. I might get it out of the way soon for the upcoming (i.e. later this week, hopefully) +3 release, but if I do that then I don't know if I'll yet bother to add a proper 16-bit mode to the memory editor like I wanted to.

Quote:
2. BG sizes (ex. $2107 to $210a bits 1-0) depicted are backwards or wrong: they should be WxH, yet %10 is shown as 64x32 when in fact it's 32x64 (%10 = "long vertical screen", i.e. horizontal mirroring; %01 = "wide horizontal screen", i.e. vertical mirroring)

Call that another v073-ism, I guess. I can change that easily enough.

Quote:
3. There was a CPU or PPU MMIO register which wasn't being tracked. Now I'm annoyed because I didn't write down which register it was! :(

Whichever one it was, it probably shows up in the properties viewer in very recent (i.e. <10 days ago) revisions, since I greatly expanded that for all profiles and views. But if I somehow overlooked anything useful, I can add it in too.

Quote:
Again, not your problem, but: bsnes-plus gives you two binaries: bsnes.exe and bsnes-accuracy.exe. The former works (but what it's built with/what profile it's using I don't know, but it does randomise WRAM and registers), and bsnes-accuracy.exe crashes on startup. I don't run "official" bsnes/higan because of the debugger need and the file format/manifest ordeal (refuse to get into that again).

"bsnes.exe" is the compatibility profile, which is the default when building. In the (soon obsolete) v073+2 release from 2015, the power-on states of both of those profiles are extremely deterministic (but will still initialize WRAM with something that isn't zeros). I finally got around to adding higan's randomization behavior about two weeks ago.

No idea why the accuracy build crashes for you, assuming it's the official release version from this thread or the GitHub repo. I haven't had anyone else mention this happening since the release, but sometime later I can give you an up-to-date accuracy build to try.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 11:02 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3732
Location: A world gone mad
1. Gotcha. The inconsistency drove me bonkers until I remembered that most of the documentation refers to the VRAM as "in words", but when looking at things in a memory/hex editor, you're looking at bytes. So I can see the point of showing both the "word offset" and "byte offset" versions.

2. Yup, 64x32 and 32x64 were backwards. I submit a pull request: https://github.com/devinacker/bsnes-plus/pull/76

3. I'm using binaries from bsnes-plus-073.2-6xBRZ-x64 (see below), which was the latest I could find. bsnes.exe has a modification date of 2016-11-07 04:16. If I figure out what MMIO register it is, I'll be sure to let you know. Thanks!

Quote:
No idea why the accuracy build crashes for you, assuming it's the official release version from this thread or the GitHub repo. I haven't had anyone else mention this happening since the release, but sometime later I can give you an up-to-date accuracy build to try.

Where I got the binaries: https://github.com/sharknnth/bsnes-plus/releases


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 11:12 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 428
Location: FL
koitsu wrote:
2. Yup, 64x32 and 32x64 were backwards. I submit a pull request: https://github.com/devinacker/bsnes-plus/pull/76

Got it, thanks :)

Quote:
3. I'm using binaries from bsnes-plus-073.2-6xBRZ-x64 (see below), which was the latest I could find. bsnes.exe has a modification date of 2016-11-07 04:16. If I figure out what MMIO register it is, I'll be sure to let you know. Thanks!

Those are unofficial builds that add the xBRZ video filter option, but are otherwise pretty much the same. 7 Nov is when I most recently made any commits, so at least it's an up-to-date build (so disregard what I just said about power-on state, I guess). As for the accuracy build crash, you might try one of the previous releases on that repo, or wait for the next official release on my end, which should be just around the corner.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 202 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10, 11 ... 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:  
cron
Powered by phpBB® Forum Software © phpBB Group