Release version 1.54 #124
Comments
|
We also need to update the copyright to add something about byuu's S-SMP core, and your Windows port one. I've already bumped the version number and our respective core copyrights. |
|
Ok, copyrights are updated. |
|
Besides the Sufami Turbo fix I'd want to finally merge in some of the libretro changes from their repo. I'll see if I can also do that this weekend. Other than that the windows port should be fine, but maybe I'll switch the project to vs2015 before a release. I'll send a pm to zones to see if he is around at all. We could also try contacting ryan if he can then update the s9x homepage, it seems some work has been done there. |
|
One thing I noticed when looking into the "Hook" issue was that we still have no working APU debugger, but I guess that shouldn't really matter for a release. |
|
I had the APU debugger working when I first attached byuu's core, and it was fairly easy. I don't know why I reverted that. The code is there to be hooked up, but you're right, it shouldn't matter for an end-user release. |
|
When you say hook issue OV, is that the one i reported? I put the line to true and it is still showing a bunch of q's on the screen. |
|
Multicart fix and libretro changes are in, the visual studio change is also done. No answer from zones so far. Do you want to take a look at the rewind pull request? I think I also added that to the unix version when I pulled it over from retroarch, would be nice if it is in all versions. But also not a necessity I'd say. |
|
Yeah, the pull request uses it unconditionally, and I wanted to make sure it didn't allocate anything if it wasn't going to be used, especially not by default. I'll look at it and try to get it in. |
|
Ok, the rewind stuff is in and working. |
|
Awesome! Finally a v1.54 release! I'm hoping we can get official binaries for the Windows-side since it is more difficult to compile source code on Windows (and costly to boot). Any progress on helping Orphis get their buildbot up and running for SNES9X builds? Would be nice to help them do automated (official) builds so that you can have an official reliable mirror like several other emulation projects use (most notably PCSX2). Also would love to know if a certain retrolib 'hack' will be ported over regarding the overclocking of the SuperFX chip. It is supposed to permit StarFox to run a lot smoother. StarFox 2 uses an updated/faster version of the SuperFX chip (SuperFX2?) but wasn't ever officially released except for various leaked beta ROMs. |
|
Yes, that would be the Super FX2 (real name GSU-2-SP1) used in Star Fox 2, Yoshi's Island and a few others I can't think of right now; can't wait to see this released. Overclocking would be nice, but not a deal-breaker if not included. |
|
I'm pretty sure binaries for Windows are guaranteed. And I'm sure that retrolib 'hack' is just that, a hack. It overclocks the SuperFX faster than what the SuperFX2 ran at to make StarFox 2 more playable. We're generally against backpedaling accuracy with speed hacks. I know Snes9x's C SuperFX core is actually a little glitchy compared to the old ASM core, so it might be due for some fixes in the future. |
|
Again, do what you need to do, if it's not in the Windows/Libretro binary, no biggie, getting it ready for release and ensuring it's ready is more vital; keep up the good work :) |
|
I'd rather the release not be delayed just for the sake of including that speed hack. However, that being said I wouldn't mind future versions possibly including it as an option. Again, following the PCSX2 model of allowing the end-user to decide on sacrificing 'accuracy' for a smoother/faster gameplay experience for certain (SuperFX) games. |
|
Anything else still missing? |
|
I don't think so. I'll do some tests with older windows versions tonight, then everything is ready on my end. |
|
Heads-up: you've still got some version numbers to bump in the win32 directory that I didn't want to mess with. I also assume we should write a changelog/update changes.txt. |
|
Ok, testing went fine. I've updated the version number for the exe, couldn't find any others. As for the changelog, I added everything I could remember and find in the commits that seemed worth mentioning. |
|
I've rolled a source tarball, and put it at https://sites.google.com/site/bearoso/ Once you've made your binaries, I'll upload them there as well. |
|
I've uploaded them here: http://www.s9x-w32.de/dl/ |
|
Everything is copied to my site, as well. |
|
Excellent work on the new release, guys :) |
|
Was there going to be 64-bit build too, like with your testbuilds OV2? |
|
I definitely built it yesterday - it seems I forgot to upload the zip file... I'll do that after work today. |
|
I did upload the x64 version, but the zip file was named 1.53... should both be there now. |
|
WOHOO! Time to finally update SNES9X! @OV2 @bearoso Don't get me wrong. It was fantastic for the time but ~10 FPS is cringe-worthy today and barely playable. Getting it up to even 25 or 30 fps would be much more tolerable and a speed slider for the SuperFX chip would be a dream :) Having it as a selectable OPTION instead of baked-in would also keep the 'accuracy' enthusiasts happy. |
|
Just of of interest, is the random crash on the PAL Version of Secret of Evermore fixed in this version? |
|
The crash in SoE may or may not be better or even worse. I suspect DMA timings are at fault, causing a desync of S-CPU and S-SMP. jcdenton2k: I understand your desire for said option, but that's more of the philosophy of the Snes9x-next guys. You're always able to use Retroarch or something for just that one game and mainline Snes9x for anything else if you prefer the Snes9x UI or something. |
|
The GSU-2 (SuperFX 2) does NOT run faster than the GSU-1. There is a clock divider register that allows both to run at half-speed, and I have confirmed on real hardware that both revisions perform identically to each other in both modes. I was not able to test the MARIO-CHIP revision found on Star Fox 1, but I was able to test both GSU-1 and GSU-1A revisions and confirmed it on both. Yes, overclocking the GSU will allow the game to run more smoothly, but this is NOT HARDWARE ACCURATE. This is a long-standing misconception that needs to die. See: |
|
@qwertymodo If needed, I'm hoping to use this information to create a 'speed up' .BPS patch for StarFox 1 for those that would prefer smoother gameplay. This would allow the end-user to customize the experience to their preferences without requiring additional work from the SNES9X devs or breaking the accuracy options of SNES9X itself. |
|
If you're referring to 0x018354: 0x01 -> 0x00, that's a ROM patch, and the address is a direct file offset, not the SNES mapped address. I'm pretty sure Star Fox 1 also sets the clock divider to high-speed mode, so a ROM patch won't make any difference. The only option to increase the framerate would be to overclock the chip, which actually speeds up the entire game, it doesn't just smooth out the display. |
|
OV2, you want to do the announcement forum post? |
|
Updated the source tarball to fix the libretro issue. Doesn't concern the binaries. OV2, you should copy the new one over. |
|
Thanks, copied it. I can make a post after work, it's 1AM here. Ryan hasn't answered so far, not sure how often he checks the forum. |
|
Tag please, 1.53/1.52 have one. |
|
It's tagged. If there are any more problems, they go into a 1.54a or 1.54.1. |
|
I made the forum post, hopefully ryan will come around to make it sticky. |
|
@qwertymodo |
|
@jcdenton2k Star Fox 1 runs on the earliest revision of the GSU (labeled MARIO-CHIP on the PCB), which may or may not support the clock select register $3039. I was unable to test it, due to being unable to get Star Fox 2 running on a Star Fox 1 board. It's been over a year since I ran those tests, but I think it had something to do with the MARIO-CHIP not supporting the larger SRAM chip that Star Fox 2 required. However, if you were to run Star Fox 1 on a GSU-1 or GSU-1A board, then at least I can confirm that it would support it, though IIRC the entire game runs faster, as the main game code doesn't have any kind of frame limiting and just runs as fast as possible, with the SuperFX as the bottleneck (at least that's the behavior I've seen with overclock mods, I would assume that you would experience the same result with the clock select register). I just ran a quick debug session, and Star Fox 1 does not write to $3039 at all (at least not during the intro video, menu screen, or the first few seconds of the first mission). So, if you want to try it out in an emulator, just find somewhere early in the game startup sequence and add in a simple lda #$01; sta $3039; and see if that makes any difference. One of these days I may try it out in hardware, but we'll see. I don't have any way of reprogramming it in-circuit, so I have to pull the chip, clean it, throw it in a socket, and then re-solder it, so it's a real pain... |
|
Zophar updated but only with the x86 version. Seems http://www.s9x-w32.de/dl/ is the most direct route. Might be worthwhile to post some official 'direct' download links for those who aren't aware of how to navigate directories directly? Why not include bearoso's website in the mirrors? Also the source link on that website should have -src in the file name like the other versions to maintain consistency.
|
|
Would also love to see a proper ReadMe.md for the Github main page as well as some updated clear build instructions for the various ports (at least Windows, Mac, and GNU/Linux) |
|
We do not have direct access to the snes9x frontpage. Those are the mirrors that were put up the last time. I'll try to update the build txt file this weekend for the vs2015 build. |
|
Who does have access to the front page? Surely, the one who does can be contacted and then the privilege given to you guys? |
|
OV2, I think there's been enough problems to do a 1.54.1 release. I'll bump the version numbers. Let me know if there's anything you want to get in before that. |
|
I just updated the build instructions txt file for win, other than that I have nothing at the moment. |
|
Ok, I've tagged 1.54.1 and uploaded a tarball to my site. I'll copy over the Win32 port files when you make them. |
|
Uploaded the binaries and copied the source tarball over. |
|
Do you want to update the forums post with a new small block for the 1.54.1 changelog and just alter the numbers in the title? We can close this issue after that. |
|
I can no longer edit the first post so I added the log at the end. But I've got a response from Ryan, maybe he can fix that. |
Out of curiosity, is this just a simple matter of someone doing a build, or is there nontrivial work involved in integrating the changes from this repo into the Mac port? |
|
Nontrivial work. (just noticed it says stagnate instead of stagnant) |
I'm at a point where I'm satisfied with the stability of the Gtk+ port. It could use a couple of features, but I'd like to get the eternally delayed 1.54 out finally before any more tinkering.
OV2, what is your opinion on the state of the Windows port? I know you mentioned fixing a Sufami Turbo issue on the forums, so that is a TODO, but are you otherwise satisfied with the stability and OK with pushing out a release?
I'm no longer comfortable doing binaries for linux systems, given its own form of "dll hell" that has developed. So I'd just do a source release. That simply involves running autogen.sh in the gtk directory to bootstrap configure, then building the tarball. The unix release has configure in git, so that's unnecessary there. The actual binaries would then be built by the distributions.
Given zones' MIA status, we'd have to let the Mac port be stagnate for this one.
The text was updated successfully, but these errors were encountered: