It is currently Thu Jun 22, 2017 5:04 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11, 12  Next
Author Message
PostPosted: Mon Dec 19, 2016 8:28 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 280
Location: FL
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:
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.


Top
 Profile  
 
PostPosted: Sat Dec 31, 2016 12:20 am 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 759
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.


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 12:35 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 699
Location: New Mexico, USA
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


Top
 Profile  
 
PostPosted: Sun Jan 15, 2017 12:55 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 1:58 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 357
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)?


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 2:14 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 699
Location: New Mexico, USA
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.


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 2:30 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 280
Location: FL
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?


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 2:45 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 699
Location: New Mexico, USA
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.


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 3:41 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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


Top
 Profile  
 
PostPosted: Mon Jan 16, 2017 4:46 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 280
Location: FL
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.


Top
 Profile  
 
PostPosted: Tue Jan 17, 2017 2:42 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1276
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.


Top
 Profile  
 
PostPosted: Tue Jan 17, 2017 2:56 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 699
Location: New Mexico, USA
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. :)


Top
 Profile  
 
PostPosted: Wed Jan 18, 2017 6:18 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 92
Location: Sweden
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"?


Top
 Profile  
 
PostPosted: Wed Jan 18, 2017 9:45 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 92
Location: Sweden
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


Top
 Profile  
 
PostPosted: Thu Jan 19, 2017 12:16 am 
Offline

Joined: Wed Nov 30, 2016 9:59 pm
Posts: 52
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.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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