bsnes-plus and xkas-plus (new debugger and assembler)

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by Revenant »

Here is a minor release which fixes a few bugs of varying importance. I plan to start doing these more often, maybe monthly. Download links are in the OP as usual.

Code: Select all

Fixed low-res scanlines being horizontally resized too much when fast-forwarding
  while a high-res screen mode is active (compat/performance builds only) [Revenant]
Fixed potential issue with modifier keys triggering multiple wrong inputs [Revenant]
Fixed potential crashes when nonexistent cart RAM would be mapped by a manifest
  and/or certain coprocessors (such as the SA1) [Revenant]
Fixed potential crash when tracing SA1/SuperFX with trace mask enabled [Revenant]
Fixed trace mask being wrongly enabled when loading a cartridge [Revenant]
I'll start addressing more of your ideas and issues once the holidays are over. I wanted to get a few things taken care of before then, but hopefully I can start to keep up more frequent official releases.
qwertymodo
Posts: 775
Joined: Mon Jul 02, 2012 7:46 am

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by qwertymodo »

Something that would be incredibly helpful would be to make it easier and more straightforward to log or otherwise debug DMA transfers. Maybe a breakpoint that triggers upon the start of a DMA transfer to a specific destination, or triggers on the start of a transfer on a particular channel (I guess that's doable already with a write breakpoint on $420B with the data field set to the channel flag). And maybe a more compact dialog just for viewing DMA states (or perhaps the state of the last transfer per channel, if it differs from the current register state). Right now the best I can do is set a write breakpoint on a destination, then hunt through the properties dialog, but the values there don't always seem to match up to the values used for the transfer in question. The new VRAM and tilemap viewers have been fantastic, but I keep finding myself in need of hunting down where the video data is actually *coming from*, whether it's directly from ROM or a WRAM buffer.

Also, it would be nice if, in the tilemap viewer, you could hover your cursor or click on the image and have it tell you the address of the tile.
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by jwdonal »

A quick note on some registers that I just noticed are missing from the S-PPU tab of the Properties viewer.

MPYL/MPYM/MPYH: $2134-$2136
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by koitsu »

jwdonal wrote:A quick note on some registers that I just noticed are missing from the S-PPU tab of the Properties viewer.

MPYL/MPYM/MPYH: $2134-$2136
I believe I can add support for this (don't have a way to compile/test though). I'll file a pull request in a bit.

Edit: filed (and fully untested!): https://github.com/devinacker/bsnes-plus/pull/103
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by AWJ »

koitsu wrote:
jwdonal wrote:A quick note on some registers that I just noticed are missing from the S-PPU tab of the Properties viewer.

MPYL/MPYM/MPYH: $2134-$2136
I believe I can add support for this (don't have a way to compile/test though). I'll file a pull request in a bit.

Edit: filed (and fully untested!): https://github.com/devinacker/bsnes-plus/pull/103
That patch displays the last result the CPU read from the registers--the added member variables are only updated on reading from 2134-2136, not on writing to 211B-211C.

According to nocash, during Mode 7 rendering, the values read from 2134-2136 constantly change based on the Mode 7 calculations. This doesn't seem to be emulated by bsnes at all. Has anyone investigated exactly how this works (particularly timing-wise)?
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by jwdonal »

AWJ wrote:That patch displays the last result the CPU read from the registers--the added member variables are only updated on reading from 2134-2136, not on writing to 211B-211C.
I haven't looked at the patch since I'm not familiar with the source, but if that's true then it should definitely be changed to update on any writes to 211B/C since 2134/5/6 have no (user apparent) delay. Updating only on CPU read is not particular useful - not that I don't appreciate Koitsu's help!!
AWJ wrote:According to nocash, during Mode 7 rendering, the values read from 2134-2136 constantly change based on the Mode 7 calculations. This doesn't seem to be emulated by bsnes at all. Has anyone investigated exactly how this works (particularly timing-wise)?
I doubt it but it only really matters if a particular game ever tries to read the result registers during mode 7 rendering _and_ uses that result for a particular purpose. This is probably unlikely but who knows. In any case I can pretty much guarantee that the behavior is determinate based on whatever mode 7 parameters are currently configured.
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by Revenant »

I responded to the PR, but it looks like AWJ beat me to part of my response :P

I don't think anything is known about how the registers behave when Mode 7 is active. Is this something that could feasibly be looked into with a test ROM?
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by jwdonal »

Revenant wrote:I don't think anything is known about how the registers behave when Mode 7 is active. Is this something that could feasibly be looked into with a test ROM?
Certainly. And a logic analyzer is useful as well. ;) But I really don't think it's that critical. You'd want to show that at least one game depends on reading a very specific byte value in order to justify all that coding/testing effort. Given that BSNES doesn't implement the behavior, and every SNES game already runs on BSNES, then I think you might have a hard time finding that justification.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by koitsu »

Issue has been discussed in the pull request: https://github.com/devinacker/bsnes-plus/pull/103

And yes, I got the code wrong (keying off of reading, not writing). devinacker covered this in his follow-up.

Related to that, some annoyance/complexity here is what actually "triggers" the mathematical operation. I thought about how the official docs outline a double-write to $211b followed by $211c followed by getting your result from $2134-2136, but started wondering what would happen if you did the writes in the opposite order (multiplier first, followed by low/high multiplicand). Would the registers internally reflect the value if read? I referred to nocash's docs, which specifically state "After writing to 211Bh or 211Ch, ...", which to me means the calculation/result is being provided all the time. This is compounded by the aspect AWJ mentioned. I'm thus left with the impression -- for lack of better phrasing here, my apologies -- that the hardware is essentially doing the calculation constantly/non-stop.

I also now sympathise with byuu having literally 3 separate CPU/PPU cores to maintain. What a fucking nightmare.

Welcome to how a feature request opens a can of worms. :P
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by Revenant »

koitsu wrote:I'm thus left with the impression -- for lack of better phrasing here, my apologies -- that the hardware is essentially doing the calculation constantly/non-stop.
Seems plausible to me, assuming that the calculation involves some of the same circuitry responsible for Mode 7 rendering.

Anyway, I just got home from work, so I'll merge the fix shortly.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by Near »

AWJ wrote:According to nocash, during Mode 7 rendering, the values read from 2134-2136 constantly change based on the Mode 7 calculations. This doesn't seem to be emulated by bsnes at all. Has anyone investigated exactly how this works (particularly timing-wise)?
No. I know that it's using it for the mode 7 multiplication calculations, but I have not emulated it. I don't even believe I'm caching the mode 7 multiplications themselves yet (it should only be adding things per-pixel.)

The PPU multiplication updates are like one piece of a large jigsaw puizzle. Trying to tackle it alone would just make a mess of things. If we were to form proper cycle stepping of all PPU operations, $2134-2136 would naturally fall seamlessly into place.

I desperately need jwdonal's test ROMs and PPU timing findings to improve bsnes further. But ... I have three other emulation cores to keep me busy in the mean time, so I guess it's no great rush.
jwdonal wrote:You'd want to show that at least one game depends on reading a very specific byte value in order to justify all that coding/testing effort. Given that BSNES doesn't implement the behavior, and every SNES game already runs on BSNES, then I think you might have a hard time finding that justification.
I emulate all kinds of things that no games rely on. It's not so much about making regular games run better, it's about ensuring someone in the future doesn't decide to use those registers as "free, fast multiplication" while also using mode 7, and then end up surprised when their game breaks on real hardware.

I've been on the other end of that (with different limitations) ... it's not fun.

I don't think most emulators should bother. Especially not Snes9X/bsnes-performance/bsnes-balanced. But we should ideally have one emulator that a person uses as a final test before releasing their games, and that should emulate anything that is humanly possible.
koitsu wrote:I also now sympathise with byuu having literally 3 separate CPU/PPU cores to maintain. What a fucking nightmare.
After probably 4+ years of maintaining them all (and building profile-optimized binaries for all three, in both 32-bit and 64-bit configurations), I finally threw in the towel and discontinued the performance/balanced cores.

I'm very appreciative that someone out there understands why I had to do that. It was a very difficult decision for me, and one that's obliterated most of the small userbase I still had left.

..........

By the way, if you guys want an even bigger rabbit hole to chase ... the regular CPU mul/div stuff isn't 100% emulated either.

As most of you know, it's a multi-cycle process of updating the math computations one bit at a time. And thanks to blargg, we know the algorithms and have that emulated.

But it is possible to start a division during a multiplication, and even easier to start a multiplication during division. The result is that both run simultaneously, only they share some transistors along the way. The resultant computations are a complete mess, and even blargg was unable to make sense of them. This is currently unemulated, and probably the easiest way to quickly detect bsnes versus real hardware today.
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by jwdonal »

byuu wrote:I emulate all kinds of things that no games rely on. It's not so much about making regular games run better, it's about ensuring someone in the future doesn't decide to use those registers as "free, fast multiplication" while also using mode 7, and then end up surprised when their game breaks on real hardware.
I agree. I should clarify that an emulator would want to at a bare minimum ensure that the Mode7 mult does not provide correct answers during mode 7 rendering in order to avoid that scenario. But as far as having the readback result be what it actually is in real hardware cycle for cycle...meh. :)
Optiroc
Posts: 129
Joined: Thu Feb 07, 2013 1:15 am
Location: Sweden

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by Optiroc »

I'm working on some SNES Mouse stuff so I'm adding mouse support to the Carbon input driver.

However! Since I don't have access to the canonical windows build at the moment I'm not quite sure how it's supposed to map the mouse input. At the moment I'm just feeding mouse coordinate deltas to table[mouse(n).axis(x)] as a proof of concept. It works, kind of, but is it supposed to translate the coordinates in some smarter way to get more of a 1:1 relation between the host operating system's mouse and what you end up with in "emulator space"?

Edit: I got the 32-bit Windows build running in a virtual machine. With the RawInput driver the pointer (using Mario Paint for testing) wouldn't move at all, and with the DirectInput driver the pointer basically only jumps from corner to corner. Can I chalk that behavior up to the virtual machine tripping things up, or has the mouse support been "orphaned"?
Optiroc
Posts: 129
Joined: Thu Feb 07, 2013 1:15 am
Location: Sweden

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by Optiroc »

Update: After some digging through old Apple documentation I managed to "pin" and hide the cursor when mouse access is requested, while still retrieving movement deltas. Works like a charm now!

PS: My macOS build is downloadable at https://goo.gl/06Ofmd
Kismet
Posts: 60
Joined: Wed Nov 30, 2016 9:59 pm

Re: bsnes-plus and xkas-plus (new debugger and assembler)

Post by Kismet »

Optiroc wrote:I'm working on some SNES Mouse stuff so I'm adding mouse support to the Carbon input driver.

However! Since I don't have access to the canonical windows build at the moment I'm not quite sure how it's supposed to map the mouse input. At the moment I'm just feeding mouse coordinate deltas to table[mouse(n).axis(x)] as a proof of concept. It works, kind of, but is it supposed to translate the coordinates in some smarter way to get more of a 1:1 relation between the host operating system's mouse and what you end up with in "emulator space"?

Edit: I got the 32-bit Windows build running in a virtual machine. With the RawInput driver the pointer (using Mario Paint for testing) wouldn't move at all, and with the DirectInput driver the pointer basically only jumps from corner to corner. Can I chalk that behavior up to the virtual machine tripping things up, or has the mouse support been "orphaned"?
Virtual Machines don't emulate absolute positioning, they only emulate relative positioning. eg, if I move the mouse over the window the virtual machine is running in and click, the mouse "real coordinates" will be in the center of the screen, and it will calculate the movement from the center of the screen. This also happens with the joystick. Suffice it to say, you can not play the vast majority of games inside a Windows virtual machine using emulated input, because you don't have any precision to work with. The solution I came up with if I wanted to play a game inside a virtual machine was to actually map the USB port to the real USB port for a mouse or joystick and that solves it. Without doing it this way, when you move an analog stick, it will only be 0% or 100% moved, because it's only tracking the relative movement and when it stops moving, it's back to zero. I hope this makes some kind of sense. This was the trick I used to run a MMORPG game on a Mac inside Parallels, as well as the MMORPG game inside a Windows VM on top of Windows when I needed to move inventory items between two characters without going through the auction house.

That said, the "moves from corner to corner" is exactly the expected behavior from a virtual machine. You can sometimes enable an alternate relative movement feature in some VM's, but they tend to only take it from one extreme to the other.
I come from the net. Through systems, peoples and cities to this place.
Post Reply