SPC7110 Test Build

[Nach]

Okay, at long last, I think I finally completed all the SPC7110 programming and tweaking (famous last words). If you find any issues, let me know, and I'll try to fix it (sigh).

Windows: http://zsnes.sourceforge.net/zsnesw-spc7110-5.zip
DOS: http://zsnes.sourceforge.net/zsnes-spc7110-5.zip

Changes:
_Demo_ and I optimized the code even more, to the extent that we don't think there's anything else significant we can do.
Fixed a bug with save states/rewind that Deathlike found.
Removed the gfx packs stuff from the GUI and config file.
Added to the config file an option to turn off the graphics cache.
The cache isn't used if there's not enough free memory, but you can play SPC7110 games anyway.
Cleanup.

Post results of speeds with the cache on and off (changing the setting requires ZSNES to be restarted). I'd appreciate if people with sub 1 GHz machines can post some FPS and CPU info with and without cache.

Todo:
Post source changes for people who want them.
Coordinate with some translation teams to get the 4 SPC7110 games translated. If you need a special build of ZSNES for something, or some info which I can provide, let me know.
Party?

[Agozer]

I don't know about a party, but we could definitely drink to this.

[Nach]

Source changes for anyone who wants them:
http://zsnes.sourceforge.net/spc7110-changes.tar.bz2

[byuu]

That license is too onerous for me. I'll stick with neviksti's code, as I prefer PD/BSD licensing over speed. Feel free to revert it to pure GPLv2 for simplicity's sake if you like.

The code itself does look really good though, excellent job on that!

[odditude]

I don't know about a party

Fie on thee, and a pox on your kind!

++party

[mnk]

Just to clarify, those changes are on top of
zsnes151bsrc.tar.bz2 (from around 15.05.2008), right ?

Well, at least it seems to work with that one.

[mudlord]

That license is too onerous for me. I'll stick with neviksti's code, as I prefer PD/BSD licensing over speed.

...................................No comment.

[Deathlike2]

That license is too onerous for me. I'll stick with neviksti's code, as I prefer PD/BSD licensing over speed.

...................................No comment.

I'm just disappointed in reading those words.

[byuu]

It's really very simple. The key words: "too onerous for me."

My license is infinitely worse, yes. I'll release bsnes as PD when I discontinue it, but I'm not going to legally sanction someone else to compete against me with my own code, ala bsnes-Cloud or bsnes PP SE XD SD++. Period. It's not a debate. If they want to do it illegally, well I can't stop that. It's a risk I take by posting source at all.

If you're not happy with that, I'm sorry, but I owe you nothing.

The SPC7110 license is not a problem for me now, but it would be in the future. I want my PD release to be unencumbered by any GPL code, and I want anyone to be able to close source my work at that point if they so choose. Right now, that means I only have to disable JMA for that release. I don't want any part of the core emulation to be copylefted if there's an alternative.

Giving credit is great, I'm happy to do that; but forcing the source to be released is a problem for me.

But you guys want copyleft, and that's fantastic!! I would much rather you license the code the way you see fit, since you wrote it, than to cater to me by changing your license. Hence why I didn't ask you to change your license before. In this case, I have another decompresser I can use that works just fine.

It's win-win. There's nothing further to discuss.

[mudlord]

The SPC7110 license is not a problem for me now, but it would be in the future. I want my PD release to be unencumbered by any GPL code, and I want anyone to be able to close source my work at that point if they so choose. Right now, that means I only have to disable JMA for that release. I don't want any part of the core emulation to be copylefted if there's an alternative.

Sounds fair.

Giving credit is great, I'm happy to do that; but forcing the source to be released is a problem for me.

I agree. Its not nice when licenses hold a gun to your throat and say "release the source or die". I much rather the developer gets thier own choices in how they do things, rather than some license that tries to be all about liberation and free expression.

It's win-win. There's nothing further to discuss.

Okay. Your choice.

[byuu]

Thank you for being understanding in your reply. Sorry for throwing the thread off, by the way. We can take the license discussion over to /dev/null from here on.

Coordinate with some translation teams to get the 4 SPC7110 games translated. If you need a special build of ZSNES for something, or some info which I can provide, let me know.
Party?

For what it's worth, I'm planning to hack FEoEZ, and hopefully Tomato can translate it. That'll be sometime in 2009. Unless you want to backport SPC7110 support to ZSNES v1.42 DOS, I should have all the tools I need (thanks to neviksti.)

Not interested in SJnS (not enough differences), but if it's easy, we can work on that after the original is finished.

And good fucking luck getting anyone to translate SPL4 and MDH :P
Waste of time, mediocre games. Lots more deserving titles out there.

[ZH/Franky]

It's really very simple. The key words: "too onerous for me."

My license is infinitely worse, yes. I'll release bsnes as PD when I discontinue it, but I'm not going to legally sanction someone else to compete against me with my own code, ala bsnes-Cloud or bsnes PP SE XD SD++. Period. It's not a debate. If they want to do it illegally, well I can't stop that. It's a risk I take by posting source at all.

If you're not happy with that, I'm sorry, but I owe you nothing.

The SPC7110 license is not a problem for me now, but it would be in the future. I want my PD release to be unencumbered by any GPL code, and I want anyone to be able to close source my work at that point if they so choose. Right now, that means I only have to disable JMA for that release. I don't want any part of the core emulation to be copylefted if there's an alternative.

Giving credit is great, I'm happy to do that; but forcing the source to be released is a problem for me.

But you guys want copyleft, and that's fantastic!! I would much rather you license the code the way you see fit, since you wrote it, than to cater to me by changing your license. Hence why I didn't ask you to change your license before. In this case, I have another decompresser I can use that works just fine.

It's win-win. There's nothing further to discuss.

Well, I truly think that you should release the software under the GPL when you discontinue it. Then again, if you're going to release it to the public domain, then I don't see any reason why someone else can't license their copy of it under the GPL. Hell, even if I never learn to code well, I could take bsnes and license it under the GPL, and give it to other people who could improve it. I could hand it over to major GNU/Linux distributions too, so they can bundle it into their systems ( am I correct in assuming that no distro will currently bundle it because of the BSNES Reference License?).

Honestly though, what's wrong with the GPL? You mention in one of your articles that while it's great for users, it takes away some of the authors rights over the software since they can never change the license (because the license is owned by the FSF), and they can never choose not to release the source code later on. But if they had that power, and chose not to release the code, they'd be bad-people because they're not sharing. You yourself said to me elsewhere on another forum (specifically, on http://www.fantasyanime.com/forums before the admin changed the forum software from burning board 1.2 to phpBB3; in a thread called "Best SNES emulator" I talked about SNESGT and said it's a bad emulator because it's closed source; my user handle was "Chain Hustler", and you replied to me saying that you agree). Under the GPL, sharing is forced, and people's rights to use the software how they wish and change it if they want to, is ensured.

So if you release it to public domain, while you give the source, others might take it and only distribute a binary. The same thing applies if you license it under the BSDL.


PS:
As you've probably guessed, I strongly support the GPL.

[byuu]

Sigh, sorry. Mods may want to at least split this off, then. But I have to respond to this:

I talked about SNESGT and said it's a bad emulator because it's closed source; my user handle was "Chain Hustler", and you replied to me saying that you agree

I can't imagine I said that. I may have said I agree that it's closed source and I don't personally like closed source in emulation. But I think SNESGT is a very nice emulator. GIGO is a great guy, more than helpful and willing to share source for individual parts if you ask him. Even if I disagree about the source being closed, at the end of the day I still respect his right to do that (same for AamirM).

[ZH/Franky]

Well, that's fair enough. But even so, I still think it's bad when someone releases an emulator without the source code.

If an emulator programmer doesn't release the code though, but allows other programmers to see the code so they can help out, with the promise that they'll respect him/her and not release the code but still look at the code and offer improvements, I suppose that's acceptable.

My only real problem with closed-source is that you then have to choose to trust that the developer doesn't put in any malicious features. If the developer releases the code, you can at least feel safe because you know that if s/he puts malicious features in there, someone else can take them out (but then, s/he'd know that since someone will take it out, s/he won't bother putting it in in the first place). But without the code, you simply don't know. I understand that this won't be as prevailent (if at all) in emulators, but it's possible. Just look at the emulator called "MagicEngine". They not only keep the source closed, but you have to have a special key to make full use of the software.

Also, what if the developer finds a technique that will improve the emulation quality in his closed-source emulator, and doesn't share his/her findings for whatever reason. This is prevailent in the Sega Saturn emulation scene, and somewhat prevailent in others aswell, such as Sega Master System emulation, Nintendo 64 emulation, and others. It only slows down progress of that system's emulation as a whole.

Personally, if you don't like the GPL, I think that rather than releasing your final version to the public domain, yuo should keep it licensed under your own current license, the BSNES Reference License, but assign others the right the licensor (i.e. the part in your license where you say "The licensor" means the copyright holder of the software, byuu.").
You could maybe keep the rights to this license, but maybe modify it and allow others to have that "main developer to which all code goes to" right, through asking you for permission. That way, even if only one person gets a certain peice of code from someone, they with the "developer" rights can still pass the code that's offered to other people that you've granted "developer rights".

Still, answer this: zsnes is under the GPL, and has that done it any harm?

PS:
You may be reading this and be thinking "he's trying to convince me to change my mind". Well, I'm not really doing that at all. If you release your software to the public domain, I still respect that since it's your software, and you have the right to decide what you do with it. I'm just stating my own opinion really; you obviously don't have to agree.

[mudlord]

My only real problem with closed-source is that you then have to choose to trust that the developer doesn't put in any malicious features. If the developer releases the code, you can at least feel safe because you know that if s/he puts malicious features in there, someone else can take them out (but then, s/he'd know that since someone will take it out, s/he won't bother putting it in in the first place). But without the code, you simply don't know. I understand that this won't be as prevailent (if at all) in emulators, but it's possible. Just look at the emulator called "MagicEngine". They not only keep the source closed, but you have to have a special key to make full use of the software.

Bottom line: Developers have the say in how they use thier software. So, there's no excuse to get all shitty if it is closed source. Just accept it or move on, OR code your own open source version.

[ZH/Franky]

My only real problem with closed-source is that you then have to choose to trust that the developer doesn't put in any malicious features. If the developer releases the code, you can at least feel safe because you know that if s/he puts malicious features in there, someone else can take them out (but then, s/he'd know that since someone will take it out, s/he won't bother putting it in in the first place). But without the code, you simply don't know. I understand that this won't be as prevailent (if at all) in emulators, but it's possible. Just look at the emulator called "MagicEngine". They not only keep the source closed, but you have to have a special key to make full use of the software.

Bottom line: Developers have the say in how they use thier software. So, there's no excuse to get all shitty if it is closed source. Just accept it or move on, OR code your own open source version.

Well, you've hit the nail on the head. If I saw a peice of software I really liked but it was closed source, (if I wanted to and was able to) I would code my own open source version (or if there was another version written by someone else and their version was open source, I would use their version and maybe contribute code aswell).

All I'm saying is that I don't like the idea of closed source software. It's like driving a car with an invisible engine; you have no control if something goes wrong.

[Nach]

Coordinate with some translation teams to get the 4 SPC7110 games translated. If you need a special build of ZSNES for something, or some info which I can provide, let me know.
Party?

For what it's worth, I'm planning to hack FEoEZ, and hopefully Tomato can translate it. That'll be sometime in 2009. Unless you want to backport SPC7110 support to ZSNES v1.42 DOS, I should have all the tools I need (thanks to neviksti.)

If you do need a ZSNES v1.42 for DOS with real decompression to translate, or it would help out immensely, let me know, and I'll do a back port.

And good fucking luck getting anyone to translate SPL4 and MDH
Waste of time, mediocre games. Lots more deserving titles out there.

I think all games should be translated into all languages. But hey, that's just me.

Edit:
BTW, I had a crazy idea. If there's no desire to getting a translation to work in a real cart (how many are going to buy an SPC7110 board and replace the ROMs?), we could go a bit beyond. There's a byte specifying the compression algorithm, yet only 3 values are used. We could easily use values 3 or higher for other algorithms. Deflate seems to beat SPC7110 on average by about 2x. Not a big deal to call some zlib functions for other modes.

Technically, with a full index of the decompression data (which we already have for some of them), I could recompress the data ROM right now. Although, some of the entries are ordered that compressed sections can overlap, which would cause issues with doing that. If we had a program which could parse the program ROM, and grab the table, entry and start offset, we could find them all, build any data ROM we like, and rewrite those values to be more optimal for a new compression algorithm.

Of course all this is theoretical fun we could have, for the sole sake of having fun, because we can. But something to consider if you really wanted to go wild with a translation, and offer higher res graphics, or even use the data ROM for audio and start streaming in high quality audio or any other insanity I've seen some translators are trying to do to make the game go above and beyond.

[mnk]

Just to make sure, all of those
'signed byte value exceeds bounds' warnings nasm spits out
are safe to be ignored ?

[Nach]

Just to make sure, all of those
'signed byte value exceeds bounds' warnings nasm spits out
are safe to be ignored ?

I haven't looked into NASM's new warnings, so I have no idea.

Some of them I think are bugs in NASM, while others are genuine, don't know anything for sure yet.

[I.S.T.]

Coordinate with some translation teams to get the 4 SPC7110 games translated. If you need a special build of ZSNES for something, or some info which I can provide, let me know.
Party?

For what it's worth, I'm planning to hack FEoEZ, and hopefully Tomato can translate it. That'll be sometime in 2009. Unless you want to backport SPC7110 support to ZSNES v1.42 DOS, I should have all the tools I need (thanks to neviksti.)

If you do need a ZSNES v1.42 for DOS with real decompression to translate, or it would help out immensely, let me know, and I'll do a back port.

And good fucking luck getting anyone to translate SPL4 and MDH
Waste of time, mediocre games. Lots more deserving titles out there.

I think all games should be translated into all languages. But hey, that's just me.

Edit:
BTW, I had a crazy idea. If there's no desire to getting a translation to work in a real cart (how many are going to buy an SPC7110 board and replace the ROMs?), we could go a bit beyond. There's a byte specifying the compression algorithm, yet only 3 values are used. We could easily use values 3 or higher for other algorithms. Deflate seems to beat SPC7110 on average by about 2x. Not a big deal to call some zlib functions for other modes.

Technically, with a full index of the decompression data (which we already have for some of them), I could recompress the data ROM right now. Although, some of the entries are ordered that compressed sections can overlap, which would cause issues with doing that. If we had a program which could parse the program ROM, and grab the table, entry and start offset, we could find them all, build any data ROM we like, and rewrite those values to be more optimal for a new compression algorithm.

Of course all this is theoretical fun we could have, for the sole sake of having fun, because we can. But something to consider if you really wanted to go wild with a translation, and offer higher res graphics, or even use the data ROM for audio and start streaming in high quality audio or any other insanity I've seen some translators are trying to do to make the game go above and beyond.

This reminds me of byuu's theoretical snes attachment so he could port some of the changes of the PC-FX version of Der langrisser over to the snes version.

[mnk]

Just to make sure, all of those
'signed byte value exceeds bounds' warnings nasm spits out
are safe to be ignored ?

Some of them I think are bugs in NASM, while others are genuine, don't know anything for sure yet.

All of those I'm talking about seem to come from constructs like:
cmp ax,0FFFFh
As I know only the very basics of assembler,
I can only guess, that nasm expects in those cases 0FFh
not 0FFFFh. Of course, it's just a guess.

[Rashidi]

All of those I'm talking about seem to come from constructs like:
cmp ax,0FFFFh
As I know only the very basics of assembler,
I can only guess, that nasm expects in those cases 0FFh
not 0FFFFh. Of course, it's just a guess.

no, AX is an 16 bit register not 8 bit registers (that should be AL & AH)

[Nach]

Coordinate with some translation teams to get the 4 SPC7110 games translated. If you need a special build of ZSNES for something, or some info which I can provide, let me know.
Party?

For what it's worth, I'm planning to hack FEoEZ, and hopefully Tomato can translate it. That'll be sometime in 2009. Unless you want to backport SPC7110 support to ZSNES v1.42 DOS, I should have all the tools I need (thanks to neviksti.)

If you do need a ZSNES v1.42 for DOS with real decompression to translate, or it would help out immensely, let me know, and I'll do a back port.

And good fucking luck getting anyone to translate SPL4 and MDH
Waste of time, mediocre games. Lots more deserving titles out there.

I think all games should be translated into all languages. But hey, that's just me.

Edit:
BTW, I had a crazy idea. If there's no desire to getting a translation to work in a real cart (how many are going to buy an SPC7110 board and replace the ROMs?), we could go a bit beyond. There's a byte specifying the compression algorithm, yet only 3 values are used. We could easily use values 3 or higher for other algorithms. Deflate seems to beat SPC7110 on average by about 2x. Not a big deal to call some zlib functions for other modes.

Technically, with a full index of the decompression data (which we already have for some of them), I could recompress the data ROM right now. Although, some of the entries are ordered that compressed sections can overlap, which would cause issues with doing that. If we had a program which could parse the program ROM, and grab the table, entry and start offset, we could find them all, build any data ROM we like, and rewrite those values to be more optimal for a new compression algorithm.

Of course all this is theoretical fun we could have, for the sole sake of having fun, because we can. But something to consider if you really wanted to go wild with a translation, and offer higher res graphics, or even use the data ROM for audio and start streaming in high quality audio or any other insanity I've seen some translators are trying to do to make the game go above and beyond.

This reminds me of byuu's theoretical snes attachment so he could port some of the changes of the PC-FX version of Der langrisser over to the snes version.

I don't care to invent new theoretical attachments and co-processors for everything under the sun. But if someone wants to allow a game to use two co-processors or expand an existing set of decompression routines to use another which we're bundling with ZSNES anyway, I don't mind doing the few modifications needed to support that.

[mnk]

Never mind, it looks like those warning, while
not bugs, are simply aftereffects of a certain bugfix
in nasm, so they seem to be safe to be ignored.

[TheManuel]

Thank you.
That's it.