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.
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 »

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
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 »

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

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

Post by qwertymodo »

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?
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 »

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.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

Okay, what's going on here?
bsnes-what.png
bsnes-what.png (11.73 KiB) Viewed 13987 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...
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 »

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)
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 »

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. ;)
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

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...
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 »

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 ®
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

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

Post by AWJ »

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.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

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...
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

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.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

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.
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 »

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.
93143
Posts: 1715
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

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.
Post Reply