nesdev.org

I managed to compile a Windows 32-bit binary of bsnes-plus with the 6xBRZ filter from CarterLi's source code. It's highly recommended to use OpenGL rather than Direct3D for the xBRZ filter because of frame rate issues. Credit to the respective authors. http://www99.zippyshare.com/v/5Hl3rF00/file.html

I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile. https://github.com/sharknnth/bsnes-plus ... g/v073%2B3

Sharpy wrote:I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile. https://github.com/sharknnth/bsnes-plus ... g/v073%2B3

Thank you. Would it be worth doing the same for BSNES-Classic?

Thanks for both programms, they are coming in handy for my StarOcean spanish translation, specially ExtHiROM/ExtLoROM support and asembling to a IPS patch in xkas-plus

ADD: I tested the assembler a minutes ago after reading the documentation. I used some code which works in ASAR, a branch of xkas. But I get some errors and have some questions now:

1) How can I make the asesembler assume I coding for a HiROM, LoROM or ExtHiROM? The first line in all my source code since the times of x816 is "hirom" or "lorom", but with xkas I get an error.

2) How can I write comments? May I use ';'?

3) May I use .b, .w or .l after opcodes in order to set the instruction length?

Thanks!

Does anyone know what this is about. I cannot get it to run on my system.

http://www.emucr.com/2016/09/bsnes-plus ... v0735.html

I can't help too much but it looks like someone forked Revenant's fork. ....Heh. (Or is possibly malware...might want to be careful.)

In any case, I've been waiting for someone else to bump this thread (so I wouldn't have to...hehe) so I could tell Revenant that this debugger is A++++++++.

I've been using the mess debugger for some time which I think is a very underrated and not very well known debugger but I'm definitely switching to bsnes-plus now. I only wish I had known about it sooner.

Thanks so much for making this!

magno wrote: 1) How can I make the asesembler assume I coding for a HiROM, LoROM or ExtHiROM? The first line in all my source code since the times of x816 is "hirom" or "lorom", but with xkas I get an error.

2) How can I write comments? May I use ';'?

3) May I use .b, .w or .l after opcodes in order to set the instruction length?

Thanks!

1) with xkas v14 (and xkas-plus) you'll need to write arch snes.cpu first to set the architecture, then use hirom, lorom, etc. to select a memory mapping.

2) xkas v14 (and xkas-plus) uses // for comments.

3) Yes.

The doc/xkas.html file that comes with the assembler is probably slightly out of date by now, but covers most of the basics.

uVSthem wrote:Does anyone know what this is about. I cannot get it to run on my system.
http://www.emucr.com/2016/09/bsnes-plus ... v0735.html

I haven't looked at it yet, but I assume it's related to (or the same as) the xBRZ builds that Sharpy posted earlier.

jwdonal wrote:Thanks so much for making this!

Glad you find it worth using

Hopefully this isn't a dumb question...but why do I see the following:

Debug Properties window in NORMAL build:
- S-PPU tab shows all appropriate values
- S-DSP tab shows no values

Debug Properties window in ACCURACY build:
- S-PPU tab shows no values
- S-DSP tab shows all appropriate values

Anyone else experience this?

EDIT: Another thing I noticed is that the S-CPU trace log is missing the Program Bank Register (PBR). Actually the Debugger GUI window is missing this value as well.

I see the same thing with the properties window.

As for the PBR, though, that isn't missing. PBR is the top byte of PC.

Nicole wrote:I see the same thing with the properties window.

Okay, thanks for confirming. Hopefully a fix will come in the future. Probably a really simple fix.

Nicole wrote:As for the PBR, though, that isn't missing. PBR is the top byte of PC.

Wow, that's a big DUH on my part.

Thanks!

The properties window issue is just a basic oversight that I keep forgetting to fix. The normal and accuracy builds use two different PPU implementations, where one provides a property list to the GUI but the other doesn't (and vice-versa for the DSP). I posted a github issue about it as a self-reminder just now.

uVSthem wrote:

Sharpy wrote:I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile. https://github.com/sharknnth/bsnes-plus ... g/v073%2B3

Thank you. Would it be worth doing the same for BSNES-Classic?

You're welcome, I've done so here with BSNES-Classic and added awjackson's Super FX improvements to it. https://github.com/sharknnth/bsnes-classic/releases

jwdonal wrote:I can't help too much but it looks like someone forked Revenant's fork. ....Heh. (Or is possibly malware...might want to be careful.)

In any case, I've been waiting for someone else to bump this thread (so I wouldn't have to...hehe) so I could tell Revenant that this debugger is A++++++++.

I've been using the mess debugger for some time which I think is a very underrated and not very well known debugger but I'm definitely switching to bsnes-plus now. I only wish I had known about it sooner.

Thanks so much for making this!

Don't worry, it's not malware, I'm the bloke that has forked it.

uVSthem wrote:Does anyone know what this is about. I cannot get it to run on my system.

http://www.emucr.com/2016/09/bsnes-plus ... v0735.html

Thanks to CarterLi, this has been fixed with the latest build I posted here https://github.com/sharknnth/bsnes-plus/releases

Nice, thanks a lot.

Hey, I just noticed on the page https://github.com/sharknnth/bsnes-classic/release that the download link for bsnes-classic-6xBRZ.073u3-x64.zip links to the old bsnes-classic-6xBRZ.073u2-x64.zip file. The zip file is named 6xBRZ.073u2-x64.zip but when you unzip and compare the files it is the same contents as the 073u2 zip. Also, if you run the exe and check the about window it says 073u1. Does anyone know what's up with all the discrepancies?

Sharpy wrote:

uVSthem wrote:

Sharpy wrote:I managed to compile 64-bit builds including an accuracy build with the xBRZ filter, again from CarterLi's source. As before recommend using OpenGL for frame rate issues on other APIs. There are a couple of bugs in in snesfilter.dll but they're minor on the compatibility profile. https://github.com/sharknnth/bsnes-plus ... g/v073%2B3

Thank you. Would it be worth doing the same for BSNES-Classic?

You're welcome, I've done so here with BSNES-Classic and added awjackson's Super FX improvements to it. https://github.com/sharknnth/bsnes-classic/releases

jwdonal wrote:I can't help too much but it looks like someone forked Revenant's fork. ....Heh. (Or is possibly malware...might want to be careful.)

> I'm the bloke that has forked it.

"Yay", more bsnes forks.

Between the endless forks and now Piko selling my software on Steam, it's nice to know my fears when I had the bsnes reference license were entirely valid and justified.

> added awjackson's Super FX improvements to it

From what I understand, his timing changes were incomplete. Although it does look to be far enough along to be a substantial improvement over what was there before, it's still generally not a good idea to implement things in flux like that.