bsnes-plus and xkas-plus (new debugger and assembler)
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Just to prove that this project is still alive, here's a spiffy new overhaul of the VRAM viewer, much thanks to UnDisbeliver:
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.
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.
-
- Posts: 775
- Joined: Mon Jul 02, 2012 7:46 am
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Sweet, so excited!! Nice work!Revenant wrote:Just to prove that this project is still alive, here's a spiffy new overhaul of the VRAM viewer...
I second that!qwertymodo wrote:I hope you can fix up that issue where the PPU registers dialog is blank in the accuracy profile.
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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).
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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!
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!
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
This please. But of course beggars can't be choosers either. I'm just happy to have this amazing SNES debugger available at all!Revenant wrote:Or, maybe I should just add another config setting to let the user decide which value the debug window shows.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.byuu wrote:Hcycle is much more useful for timing code than Hdot is.
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: Select all
<blah blah> V:# H:# CYC:# <blah blah>
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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)jwdonal wrote: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.byuu wrote:Hcycle is much more useful for timing code than Hdot is.
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: Select all
<blah blah> V:# H:# CYC:# <blah blah>
Because there are two counters with different behaviours, the meaning of "the actual dot number" is ambiguous.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
> 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.
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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.byuu wrote:With the exception of scanline 240 on odd frames when not in interlaced mode, where those dots are of normal length.
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.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.
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.Such a pain in the ass system
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Responding to a post in a different thread to avoid derailment:
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.
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.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
Call that another v073-ism, I guess. I can change that easily enough.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)
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.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!
"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.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).
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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
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!
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!
Where I got the binaries: https://github.com/sharknnth/bsnes-plus/releasesNo 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.
Re: bsnes-plus and xkas-plus (new debugger and assembler)
Got it, thankskoitsu wrote:2. Yup, 64x32 and 32x64 were backwards. I submit a pull request: https://github.com/devinacker/bsnes-plus/pull/76
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.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!