It is currently Mon Dec 11, 2017 6:33 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 171 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12  Next
Author Message
PostPosted: Thu Jan 19, 2017 2:42 am 
Offline

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

Yup. After looking a bit more at the RawInput and DirectInput drivers to clean up the behavior of mine I think that makes sense. Both those API seem to work by acquiring exclusive access to the device and read out raw relative mouse movements. And as you said, that won't work with most vm hosts with the default configuration at least.

Kismet wrote:
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.

:o


Top
 Profile  
 
PostPosted: Fri Jan 20, 2017 1:54 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
By the way, that link Optiroc posted on the previous page is more or less the official Mac release for 073+3a; I just haven't added it as a proper release to the github project page/this thread/etc. Feel free to use it as an "official" build instead of building from source yourself if you want.


Top
 Profile  
 
PostPosted: Sat Jan 21, 2017 7:18 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
I'm pretty sure the VMWare Tools for ESXi clients enables absolute positioning for mouse control, but without the Tools installed, it behaves the way you describe. Just curious, with this talk about the input code, have you figured out the issue with input not working after the machine locks or goes to sleep?


Top
 Profile  
 
PostPosted: Sat Jan 21, 2017 8:01 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
qwertymodo wrote:
Just curious, with this talk about the input code, have you figured out the issue with input not working after the machine locks or goes to sleep?

Aside from making sure I was able to reproduce it, I haven't looked into it a great deal yet, but thanks for the reminder.

In other (less useful) news, having to debug some troublesome SPC dumps led me to write a new optional plugin for loading/playing SPC and SNSF files.


Top
 Profile  
 
PostPosted: Sat Feb 18, 2017 1:50 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
Okay, what's going on here?

Attachment:
bsnes-what.png
bsnes-what.png [ 11.73 KiB | Viewed 1293 times ]

It may or may not be relevant (probably not) that this ROM works in no$sns and Snes9X, but not any version of bsnes/higan, and that the problem seems to be that forced blank isn't getting turned off...

EDIT: As expected, the reason the ROM wasn't working was completely unrelated. I presume this is just a bug in the disassembler...


Top
 Profile  
 
PostPosted: Sat Feb 18, 2017 8:13 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
Hmm, I guess for some reason it's getting confused about whether the LDA is supposed to be two or three bytes and skips the first byte of the next instruction as a result. I'll have to check that out.

(edit: to clarify, this is almost definitely just a bug with the disassembler and not the actual emulator)


Top
 Profile  
 
PostPosted: Sat Feb 18, 2017 10:10 am 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 717
Location: New Mexico, USA
Any word on when the next release will be out? I could _really_ use those Run-to-next-hblank and Run-to-next-vblank buttons right about now. ;)


Top
 Profile  
 
PostPosted: Sat Feb 18, 2017 11:34 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
That code was never supposed to execute at all. The problem was that I was carelessly jumping to the ROM version of that routine when I should have been using the one in RAM. As you can see from the code, I had just started the GSU (and the GSU program was very short, just eleven bytes of code, but it wasn't cached). Still not sure why this would cause one byte to be skipped, instead of outright locking out the CPU... or maybe it did lock out the CPU, which could explain why the code started at that routine every time I broke for debugging...

And now that I actually look up brk it seems it can take a "signature byte", so I guess brk #$21 makes more sense than I initially thought once you accept that something caused the disassembler to skip the actual opcode...


Top
 Profile  
 
PostPosted: Sat Feb 18, 2017 7:36 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
jwdonal wrote:
Any word on when the next release will be out? I could _really_ use those Run-to-next-hblank and Run-to-next-vblank buttons right about now. ;)


when it's done ®


Top
 Profile  
 
PostPosted: Sat Feb 18, 2017 9:17 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 431
93143 wrote:
That code was never supposed to execute at all. The problem was that I was carelessly jumping to the ROM version of that routine when I should have been using the one in RAM. As you can see from the code, I had just started the GSU (and the GSU program was very short, just eleven bytes of code, but it wasn't cached). Still not sure why this would cause one byte to be skipped, instead of outright locking out the CPU... or maybe it did lock out the CPU, which could explain why the code started at that routine every time I broke for debugging...

And now that I actually look up brk it seems it can take a "signature byte", so I guess brk #$21 makes more sense than I initially thought once you accept that something caused the disassembler to skip the actual opcode...


The SNES doesn't have any provision to allow the CPU to be halted externally (from the cartridge or expansion slot). In the case of SuperFX cartridges, if the CPU reads from ROM while the SuperFX is busy with it, it gets the IRQ vectors no matter what address it reads from.


Top
 Profile  
 
PostPosted: Sat Feb 18, 2017 10:42 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
IRQ vectors, not open bus? Yeah, now that I actually look up the behaviour, I see that's true...

Well, it's not super relevant. I had thought it might be ending up in a tight loop, but I just tested the working version in bsnes-plus, and it too manages to always stop right at the ldx #SuperFX immediately above the code I've shown (you can see the partially cut off stx $310E at the top) - except this time it's in shadow RAM like it's supposed to be. I guess that's just how the timing works out...


Top
 Profile  
 
PostPosted: Wed Feb 22, 2017 7:52 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
I've been trying to debug some Super FX code, and it looks like when loop is executed, the debugger displays an instruction corresponding to the byte immediately prior to the jump target in R13 rather than the byte immediately following loop. Actual code execution seems to be correct.

Also, the display of conditional branch addresses seems to be one less than what shows up in no$sns; ie: bne $8418 instead of bne $8419. And sure enough, $8418 is the address of the byte immediately preceding the actual branch target, and instead of showing the byte following the branch instruction, the debugger shows the byte at $8418. Again, actual execution seems to be correct.


Top
 Profile  
 
PostPosted: Thu Feb 23, 2017 11:08 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
Also, I notice that the CLSR display says 10.7 MHz, even though I wrote a 1 to it, no$sns agrees that it's 1, and changing the code so that it writes a 0 instead results in slowdown.


Top
 Profile  
 
PostPosted: Fri Feb 24, 2017 8:20 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 336
Location: FL
93143 wrote:
Also, I notice that the CLSR display says 10.7 MHz, even though I wrote a 1 to it, no$sns agrees that it's 1, and changing the code so that it writes a 0 instead results in slowdown.

ARM9 fixed this (and added ROMBR to the property viewer) in a pull request a few weeks ago, so if you're able to use a newer development build then that should be fine.

I'll fix the branch/loop thing in the disassembler sometime soon, thanks for pointing that out.


Top
 Profile  
 
PostPosted: Fri Feb 24, 2017 2:58 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 818
Glad to help.

I just checked, and it looks like the same thing happens with iwt R15, #addr. The address displays correctly because it's baked into the ROM, obviously, but the next instruction displayed seems to be the one immediately preceding the jump target instead of the one that should be in the pipeline. I imagine jmp and ljmp behave similarly.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: HihiDanni 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:  
Powered by phpBB® Forum Software © phpBB Group