||Snes9x.COM: Developers Journal
heres a new mirror for snes9x:
Funkyass, 27-8-2003 2:36: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
1.41 is out. you can get it from the following, packages for most platforms should be up in a few days:
This build should fix any sprite(read graphical) oddites that we're not present in 1.39, and a few other bits:
- Win32 controllers now stay the same between games (MKendora)
- Win 32 Open ROM dialog fixes (MKendora)
- Win32 Display dialog fixes (funkyass)
- Win32 OpenGL ratio tweaking. (Reduces the gray line) (kode54)
- Fixed Win32 superscope for those having issues (MKendora)
- Generic accuracy fix in main Superscope emulation (MKendora)
- sprite bug fixed (gah! How'd we miss that) (anomie)
- SPC saving compatibility fix (Caz and zones)
- Window clipping update (anomie)
- Mode 7 clipping fix (TRAC)
- latching fix (anomie)
- BS BIOS checksum and mapping fix (MKendora)
- Working Uniracers hack (dma.cpp) (anomie)
- HDMA Indirect Address fix for Romancing Saga 2 (anomie)
- Better savestate hack, does it break anything? (anomie)
- C4 C core fixes. Mostly Trapezoid (thanks Nach),
some s/short/int16/, some indentation. (anomie)
- Damn, but the indentation in ppu.cpp was screwed up.
Killed some dead code too (twas commented forevermore). (anomie)
- fixed a potential crash in S-DD1 logging (MKendora)
- Improved accuracy of Hi/LoROM detection (~500 ROM test) (MKendora)
- Hack for Moryou Senki Madara 2, don't call
SelectTileRenderer from DrawOBJS if BGMode is 5 or 6. A
real fix requires at least rewriting SelectTileRenderer,
or inlining a special version in DrawOBJS. (anomie)
- DMA traces: add additional address info to reads too. (anomie)
- Killed the old Borland Joypad dialog (funkyass)
- Fixed issues with Dezaemon and CT, maybe others (anomie, MKendora)
- Changed the internal snapshot key from \ to VK_F12 (funkyass)
Fixes issues with non-US keyboard layouts.
- Fixed OAM reset to not occur during forced blank. (anomie)
- Killed some dead OAM reset code that doesn't need saving. (anomie)
- Unix/X11: Fixed screen jumping. CT enables overscan mid-
frame for only one frame, and we now update the rendered
screen height accordingly. Other ports are still broken. (anomie)
- Unix/X11: Fixed possible TV mode crash. (anomie)
- Fixed OAM reset timing (beginning of V-Blank rather than
end) for R-TYPE 3 (J). (anomie)
- Unix/X11: Fixed OpenGL target (PBortas)
- Unix/OSS: Fixed big endian sound (PBortas/ernstp)
- Tweaked the About Dialog so its read-only and no scroll (funkyass)
Before posting any bugs(as they probably will be), you should read this. Its vitally import for you to understand that in order for us to even attempt to fix bugs, we need to be able to reproduce those bugs consistently on our end, and with more than one game preferably.
Funkyass, 12-8-2003 1:17:00
|Joystick Dialog Done
And let me tell you, it was a bitch.
You'll see it soon, if not in the bugfix release, then in the one after that.
Which leaves only the cheat dialogs left in borland code space.
Which means soon the snes9xw.dll will go away for good. Smaller distrubution file too.
Funkyass, 5-8-2003 11:11: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 9:35:00
Go back in time