Does no$sns 1.6 really have malware?

[tepples]

Could you use something like SPCamp to test the SPC engine?

Does it have debugging? Once I determine that the program is behaving incorrectly, how do I go about determining which instruction in my SPC700 program is responsible for the difference from intended behavior? If there is no debugger, there is no advantage of using SPCAMP over something like Game_Music_Emu by blargg.

And the page for SPCAMP on Zophar's Domain states that it's a Winamp plug-in. Will I now have to install the whole of Winamp in Wine? Or is there a lightweight host application for Winamp plugins?

Failing that Geiger's ?

Is it good for the Super NES scene to continue relying on that abandoned piece of software?

[Oziphantom]

My point was more do you need a full emulator or can you use just a SPC emulator? as just emulating the SPC would help with performance on an Atom. But if you want need the SNES CPU to interact for you needs then not enough. For you more debugging based needs and Linux? based usage this would probably suit better http://vspcplay.raphnet.net/ than same SPCamp(which I feel is the most famous of SPC players ) and being open source you could tack a debugger and code stepper in as well with probably little effort.

Its not, but always an option. Or if you don't want WINE, ZSNES and DOS BOX? *ducks*

[tepples]

My point was more do you need a full emulator or can you use just a SPC emulator?

I can use an SPC emulator if it supports debugging.

http://vspcplay.raphnet.net/

Thank you for the suggestion. I built it and tried it, and it core dumped:

Code: Select all

*** buffer overflow detected ***: ./vspcplay terminated

I plan to open another topic about my failure to get it to work.

and being open source you could tack a debugger and code stepper in as well with probably little effort.

Other than having to learn native programming and SPC700 programming at once.

Or if you don't want WINE, ZSNES and DOS BOX? *ducks*

I started this topic because I'm willing to use Wine. But in any case, zsnes -d appears to be "now available in all ports". Thank you for the suggestion. Is ZSNES maintained? Because I just installed it (sudo apt install zsnes), tried my test ROM, and the envelopes appeared to be way off. Is it "for the S-SMP, use the debugger in ZSNES, but for the DSP, use an SPC player and play it by ear"?

I just tried zsnes -d /path/to/my/rom.sfc, and F1 didn't do what it said it'd do. I plan to open another topic about my failure to get it to work.

[Oziphantom]

ZSNES is the most ancient of emulators, it is written in i386, its job was to run a SNES on a 486DX66. I use to run it on my P133 and it still had some issues, My VESA driver ( stupid S3 piece of crap) couldn't do 16bit so no transparency effects for me. I had to play Chrono Trigger with the 3rd layer disabled so I could see in some levels. I'm from Oz so no real cart for me.. It has not been updated in 10 years ( I was going to say 20, but the sneaked one out in 2007 ). It prays heavily at the alter of speed, not accuracy, a lot of the old SNES patches and home brew don't work on the newer emulators or even hardware as they are ZSNES compatible only. However I would think for your needs it should be sufficient, you might need to do a debug session on something newer at the end, but for the most part ZSNES should get you through the ZSKnight

[Revenant]

The program is packed with UPX though, which many antivirus programs have a history of being overly sensitive about.

After bothering to actually un-UPX the latest no$sns release, I ran it through VirusTotal to test this theory.

Detection ratio before unpacking: 31/61
Detection ratio after unpacking: 5/61

One of the 5 AVs that still gives a negative result after unpacking is AVG, which I've been able to trigger false positives from on multiple occasions by writing basic command-line tools that do nothing more than convert/extract files.

Two of the other negative results are some no-name AV programs that describe it as "malicious_confidence_65%" and "malicious (moderate confidence)", which is not particularly convincing.

[Near]

UPX is a nightmare, and never worth it. I fought false positives for a few years but eventually threw in the towel and just rely on the 7zip archive for compression during distribution. It's not UPX' fault, but it's a battle you cannot win, much like screensaver suppression and joypad input.

AV software is worse than having most real viruses.

Also, even without UPX, I'm pretty sure Martin employs other tricks to try to protect his binaries from modifications, like a CRC check on the uncompressed binary. Could be mistaken, but I know there was one closed source emudev that loved doing that.

(Don't be surprised if I make a post soon ranting about how closed-sourcedness is of the devil. It's why I gave up on the SNES and frankly, if you are a software developer who won't share things because you want your name plastered on them or you think it's okay to just release a program on Windows and make everyone else use Wine, I don't like you.)

I like you :)

The thing that pushed me toward the GPL instead of the ISC license was actually FuSoYa's Snes9X SuperFX tracer. He botched a detail (turned out to be ROMB reads) in a way that broke Doom exactly like I had in my early SuperFX support. Had he released the source, it would've been a five minute fix to see what he changed from the mainline Snes9X and to fix that bug in my core.

But because he was too selfish to share a few fprintf commands after taking the entirety of Snes9X's source for himself (his site had a screed about -not- asking him for source, too, or I'd have tried that), I had to spend a few days trying to figure out the bug with no help at all.