 |
 |
|
 |
| Snes9x 1.42 Released! |
 |
Happy Holidays from the Snes9x dev forum!
We've got several new and (maybe) exciting features as something of an early Christmas. See changes.txt for full details, since it’s more practical to offer only the highlights.
First of all, the long project of rewriting the Windows UI is complete. The Cheat Search in particular might be a little on the raw side though. As such if you happen to come across things where the behavior isn’t quite as sane as it could be, or there appears to be a bug, please post it to the appropriately named sticky thread in the development forum.
Continuing with our Windows theme, I've posted the format of the valid.ext file generated by the Win32 UI on the dev forum. You can modify the file to include or exclude specific filetypes. If you are intending to make use of this feature you might want to remove the existing version of the file. I changed the code slightly to increase the ability to screen files.
Anomie has integrated a long-awaited sprite patch, implementing a feature of the SNES called "Range-Time Over". This feature has had a history of problems, so I'm really glad anomie found an implementation that works so well. Bugs fixed by this include two scenes in Final Fantasy 3 and some of the battle graphics, as well as the Tiny Toons title screen. Tiny Toons clipped a few blocks of the title on a SNES, but not on the emulator; Snes9x now clips those, too. Because of this you may see an occasional sprite disappearance, but before you report a bug, consider what the SNES really did.
As a result of anomie's work, a few tests by Overload, and a short implementation by me, we now pass the infamous Electronic test. Hurrah!
anomie also fixed the read behavior for vram. This fixes the intro for Moryo Senki Madara 2.
The most hyped feature (though range-time over is probably the most important) is Andreas Naive's cracking of the S-DD1 decompression algorithm. The feat is truly impressive. Idealistically, this is great news because it's another victory we thought we'd never win. Pragmatically, people with decently fast machines no longer need to deal with graphics packs. Consult your port's documents for the important usage details. In fact, read all of the documentation, because you will more than likely learn new things. In any case, salute Andreas for he's earned it.
In other news, the DSP-1, SuperFx, and SA-1 are all improved. The latter two no longer save sram for games that didn't use a battery and the DSP-1 is more accurate now. The next improvements (in future versions) should fix the graphics glitches as well. There’s only a handful of ops left, and all but one deals directly with the rendering.
Finally, we’ve added a secret Windows-only feature. In order to minimize the chances of spoiling the fun we've obfuscated the source, and we'd appreciate it if you didn't decode it just to tell people the details of the feature. Rather, it's a bit of a game for me. Board regulars will have most likely have an advantage, especially depending on what is in the folder with their new Snes9x. In the event no one gets it without looking at the source, I'll taunt you all and offer some new hints.
Along with the release, I have some housekeeping that needs to be public.
First, we are looking for someone both willing and able to maintain the Glide code. The current development staff is not able to maintain the mode. We will revaluate Glide support in a few months if we are not able to maintain the mode.
Second, and more importantly, we’d like to clarify the Snes9x license. It has come to our attention that several people have auctioned off Snes9x and ROMs on Ebay. Quite aside from the fact that selling ROMs is almost certainly illegal in any jurisdiction, it is a violation of the license to sell Snes9x. Please read and respect the license, and report anyone trying to scam money out of people for Snes9x. Thank you.
As per usua
Mkendora, 4-12-2003 18:59:00 |
|
 |
|
 |
 |
|
|
|
|
| Generic update on everything |
|
As most of you know, Andreas Naive has solved the S-DD1 compression scheme. What does that mean? Well, for one, it means that future generations of Snes9x can run without graphics packs for these games (SPC7110 games will still need packs until we've got the decompression routine for it)
This is a pretty major development, and Andreas produced code that dropped into Snes9x nicely. However, there's quite a lot going on in other places in the code.
For starters, let's take a look at the special chip status:
S-DD1 - compression is now emulated as well as the memory mapping features!
SPC7110 - compression is the major behavior we don't emulate. There may be a corner case missing here or there, because there are different mode registers, but the main chips is very well emulated in Snes9x, except for the decompression.
C4 - fully emulated, and C code is available for all platforms. This one isn't bit-perfect, but it has now migrated from "needs additional emulation" to "needs accuracy improvements", which means future improvements will be less noticable.
OBC1 - effectively emulated, in that it displays. There are probably still unemulated portions of this chip.
SA-1 - as far as I know, the chip itself is fully emulated, but some games trip emulation bugs somewhere, very possibly outside the SA-1
SuperFx - no change in status, it is the same as 1.39. The C core might see some improvement thanks to some dedicated porters.
There are multiple DSP chips, in case you did not know, and that makes "fixing" a certain DSP game difficult.
DSP-1: The only one known to be used in multiple games, this one is undergoing accuracy refinements. Overload and neviksti have put this chip up to about 21/27ths bit accurate. the remaining 5 or 6 Ops are very much display related, so if you report a DSP-1 bug, it's probably going to persist until this project tackles the inaccurate Op.
DSP-2: bit-accurate, except for one Op, because the floating point simulation gives us a little bit of anti-aliasing on skewed graphics. We have a bit accurate version in the source, for purists.
DSP-3: 5 Ops are known, 3 are bit perfect, and Overload had some idea what the 4th one is (Emulation infinite loops once this Op kicks in).
DSP-4: Numerous Ops are known, only 2 have a known purpose. Those are emulated already. Needless to say, Top Gear 3000, by using so many Ops so early, will take quite a bit of time to get any display.
Seta made their own custom chips, and these are relatively newly understood, outside of Japan. (Apparently, someone in Japan had documented the different Seta chips years ago, but we're just now learning about that)
ST-0010- This is the chip in F1-ROC 2/Exhaust Heat 2. Partially emulated, but not enough to warrant "playable" status.
ST-0011- Looks to make more use of the same interface as the ST010 (ST-0010), but seems to perform shogi positional analysis. No significant emulation code, just the shared interface with the ST-0010.
ST-0018- Supposedly, MAME has done some work on this, but we know it's a RISC chip, from our own research (ok, ok, Overload did it all). Overload has also figured out the interface, so it's a matter of long and difficult research now.
This is also used to speed up shogi AI, hence my doubts about our chances of any emulation in the short term.
There are also some games that supported add-ons and some add-on systems:
Sufami Turbo: This one has the research done. I'm currently working on the memory map, to make sure the games properly. I wish I could have someone confirm whether or not sram cards existed for the system, or talk to someone who developed for it. It would be interesting to know more about this system.
BS: The BS memory map is still under investigation, but the stumbling block is that we don't know where the flash cart is mapped to. It's quite likely that once we start mapping that correctly,
Mkendora, 17-8-2003 19:53:00 |
|
|
|
|
|
|
|
|
|
| Live and Learn |
|
Well, it's been a few hours since the release, and I am upset with myself, and relieved.
There's going to be a service release of 1.40, to fix some Superscope issues people are having on Windows. That's my fault, for testing only on my usual platform. Had I taken it off my PC, or installed Windows 2000 service pack 4, I would have tripped the issue. It's pretty much my fault if the light guns fail on you. On the other hand, the required fix should be more sensible than the fix I'd used before. (Snes9x 1.39 superscope didn't work for me at all, I guess now you all know what I was trying to fix)
I'm also upset I didn't try building from the source tarball. The Win32 project files do not like being in linux format, and you can't compile without first flipping them. I suppose Gary knew what he was doing with two source packages.
On the other hand, I am pretty relieved, because for the amount of the emulator that changed, especially so much of the memory map, I had expected we'd be fixing games, not a controller that was broken for some people before.
In any case, if you have simple cases of games not working that ran in 1.39, bring them up and we'll try o pack as many fixes as possible into the service release, on the condition of speed. Then, we move onward, because I've already got several Win32-specific and some general coding projects I wish to undertake.
Mkendora, 26-7-2003 09:35:00 |
|
|
|
|
|
|
|
|
