bsnes v0.034 released

[byuu]

2008-08-10 - bsnes v0.034 released

For this release: SPC7110 emulation speed has been greatly optimized, massive improvements to HDMA timing have been implemented, Multitap support was added, and the user interface was polished a bit more.
Changelog:

* SPC7110 decompression code updated to latest version by neviksti and converted to a state machine; SPC7110 overhead is now identical to S-DD1 overhead (eg ~5% speed hit over standard games)
* Fixed a major bug in SPC7110 data port emulation that was crashing Super Power League 4 [Jonas Quinn]
* HDMA trigger point corrected to H=1104, bus sync timing corrected
* All illegal DMA A-bus accesses should now be properly blocked
* DMA state machine rewritten, greatly simplified
* Major corrections to HDMA run timing; fixes flickering bugs in Mecarobot Golf and Super Mario Kart
* Emulator now defaults to 2/1/3 SNES (CPU/PPU1/PPU2 revision numbers)
* Multitap emulation added, can be attached to either or both controller ports; user interface updated to reflect this
* Status messages (cartridge loaded / unloaded, UPS patch applied, etc) now appear in status bar
* Added advanced configuration option, "input.analog_axis_resistance", to control gamepad analog stick sensitivity

Also, the SPC7110 emulator download link below was removed: if you are looking for this, please download the bsnes v034 source code, which has the most up-to-date version in the src/chip/spc7110 folder.

I've also moved the contributors list to the readme file and the website's bsnes page. I apologize if I've missed anyone.

[mudlord]

SPC7110 overhead is now identical to S-DD1 overhead (eg ~5% speed hit over standard games)

Nice!
Brilliant job on the new release byuu!

[Snark]

2008-08-10 - bsnes v0.034 released

For this release: SPC7110 emulation speed has been greatly optimized, massive improvements to HDMA timing have been implemented, Multitap support was added, and the user interface was polished a bit more.
Changelog:

* SPC7110 decompression code updated to latest version by neviksti and converted to a state machine; SPC7110 overhead is now identical to S-DD1 overhead (eg ~5% speed hit over standard games)
* Fixed a major bug in SPC7110 data port emulation that was crashing Super Power League 4 [Jonas Quinn]
* HDMA trigger point corrected to H=1104, bus sync timing corrected
* All illegal DMA A-bus accesses should now be properly blocked
* DMA state machine rewritten, greatly simplified
* Major corrections to HDMA run timing; fixes flickering bugs in Mecarobot Golf and Super Mario Kart
* Emulator now defaults to 2/1/3 SNES (CPU/PPU1/PPU2 revision numbers)
* Multitap emulation added, can be attached to either or both controller ports; user interface updated to reflect this
* Status messages (cartridge loaded / unloaded, UPS patch applied, etc) now appear in status bar
* Added advanced configuration option, "input.analog_axis_resistance", to control gamepad analog stick sensitivity

Also, the SPC7110 emulator download link below was removed: if you are looking for this, please download the bsnes v034 source code, which has the most up-to-date version in the src/chip/spc7110 folder.

I've also moved the contributors list to the readme file and the website's bsnes page. I apologize if I've missed anyone.

wow, lots of emulation accuracy fixes and features added in this release..great work!

edit and thanks to Jonas Quinn for the $4810 register/Super Power League 4 fix.

[byuu]

New WIP (yes, already.)
Nothing that affects emulation, just a bunch of core changes I didn't want to make last-minute before the release.

All of the APURAM / VRAM / OAM / CGRAM memory blocks have been moved to the Memory class, and I've added operator[] bindings and such so that I don't have to add .read(), .write() around everything. Required several dozen individual changes, and I was afraid of introducing a new bug. Everything looks good so far, anyway.

I also missed the translate[] call around "Paused", so it's not possible to localize that in the new version. Oops.

edit and thanks to Jonas Quinn for the $4810 register/Super Power League 4 fix.

Definitely, I wasn't going to release a new version this week because of that bug.

Speaking of which, I just tried SPL4 on the Windows port. Holy hell, that completely changed my opinion of OpenAL.

Seriously, those on Linux ... compare that game with OpenAL and ALSA. With DirectSound / ALSA, the game actually has echo / reverb. It's completely missing with OpenAL. The woman announcer sounds like she's speaking over a megaphone, but OpenAL makes her sound like she's two feet away from you. Wild stuff.

And SDL video is going crazy on me now, it seems to be setting each pixel's alpha value to some sort of inverse of chroma. Eg you can see the background through the emulator window, and it's completely transparent on full white / black screens. Really trippy looking. Definitely be sure to set system.video to "glx" or "xv" if you use the Linux port.

[tetsuo55]

Cool!

What are the advantages of those memory changes?

[Chano]

A lot of Tales of Phantasia fan made translations that worked with Bsnes 0.032a don't work with this new version (for example, THIS translation). However, the original game keeps working.

Thanks for this new release.

[tetsuo55]

A lot of Tales of Phantasia fan made translations that worked with Bsnes 0.032a doesn't work with this new version (for example, THIS translation). However, the original game keeps working.

Thanks for this new release.

Does the translation work on a real snes with a copier? (i doubt it)

[tetsuo55]

Strangeness.

With the new WIP, when i play Zombies ate my neighbours with Frameskip=1 the level-name-animation does not work.

it worked fine in the older builds tested 22 too, works correctly with frameskip 1

[byuu]

What are the advantages of those memory changes?

Nothing major. It'll make a debugging interface easier. Rather than using ppu.vram_read() + smp.ram_read() + cpu.wram[], etc; I can just use memory::vram[], memory::apuram[], memory::wram[], etc. It'll also make it easier to spot out-of-bounds memory accesses, and to add breakpoints for memory writes. Eg before, with the S-DSP writing directly to raw memory handles, I couldn't add a hook for any writes to APURAM address 0x0000.
The downside is that even though the code should be identical with operator overloaded inlining, it tends to be infinitesimally slower, due to compiler weaknesses. Not enough to see an FPS dip, at least.

A lot of Tales of Phantasia fan made translations that worked with Bsnes 0.032a don't work with this new version (for example, THIS translation). However, the original game keeps working.

No idea. Will have to see what happens on hardware.

With the new WIP, when i play Zombies ate my neighbours with Frameskip=1 the level-name-animation does not work.

If it's just the WIP and not v034 official, it's possible the memory changes broke something. Sounds weird, but I'll have a look.

EDIT: I don't see what you mean. I see the "Level 1 Zombie Panic" thing, and it bounces around the same in v032 and v034.01 ...

[tetsuo55]

To reproduce:

Open bsnes > Set frameskip to 1
Load game, start playing

it either happens or it doesn't (pretty random)

Reset the game using "system>reset"

Now it happens every time without fail

[byuu]

Okay, not too bad.

First, ToP. All fan translations are 'broken', due to a mapping issue. It's falsely detecting the game as HiROM due to changes I've made to support FEoEZ's 40mbit mapper.

For whatever reason, DF fixed the "blank" checksum in the HiROM area ($ffc0), it used to be 0x0000 / 0xffff, and the extended HiROM header was valid (0x4f6b / 0xb094). In the translation, both are valid. What ends up happening is the HiROM mapper slightly beats out the ExHiROM mapper (which the game requires.)
Yet another reason to hate these alchemic header formulas.

If you want to run a fan translation of ToP in the current release, you'll need to hex edit and change the HiROM checksum to be invalid. Eg edit $ffdc to 0x00. Add 512 to that offset if you have a header.

I'll see what I can do for future releases.

Second, ZAMN.

The reason it doesn't bounce anymore is due to the new offset-per-tile caching code, added between v030 and v031. The frameskipping just so happens to cache the changes and present that odd anomaly. I'll see if there's something I can change, but frameskip was never really meant to be used in the first place, as games can detect it (eg SNES test program will fail RTO tests.)

[tetsuo55]

This is exactly why i want the add-on-pcb-info file

So the problem with ZAMN is not an emulation bug but a problem with the frameskip option?

[byuu]

This is exactly why i want the add-on-pcb-info file

Likewise. But few people are going to use them even when they come out, so I still have to rig this header detection some more. Maybe I'll be lazy and special case it based on the ROM size of exactly 48mbits (eg not 40mbits as in FEoEZ ...)

So the problem with ZAMN is not an emulation bug but a problem with the frameskip option?

Looked into it a bit more, I was wrong about it being related to offset-per-tile caching. It actually still happens all the way back to v018, oldest version I've bothered to test. Probably happens in older ones, but it doesn't really matter.

Suffice to say it's been there a long time. I ran frame by frame, and it appears as though every other frame is always in the same spot. This is why it works fine with a frameskip of 2. And yet not for 3, etc. So, really, it's a lot like how frameskip 1 means your character is either always invisible or always visible when you get hit, rather than blinking as with frameskip 0.

It seems the code I use to set the frameskip setting is simply being reset every time, so that the same frame is skipped every time. Before, in previous versions, the screen would only stay still ~50% of the time. For whatever reason, it's always evenly aligned now, and you can't make it use the alternate frame. Not sure what I changed there, honestly.

But yes, it's 100% related to frameskipping -- the emulation itself is fine, it's just visually displeasing. The only thing I can think of is to alternate which of the frames in the frameskip list is skipped (eg for FS=1, skip 0 the first time, then 1 the next, and repeat), which would help show the animation better. But it may cause odd jumpiness / lag.

But really, I think it's better that we just leave it alone. As I've mentioned in the past, a dot-based renderer will require killing frameskipping anyway (as it will be useless -- the overhead is due to RTO calculations, just skipping the actual blit to screen only speeds up emulation by ~5% at frameskip of 9.)

Obviously, you're not able to get 60fps without the frameskip ... very sorry about that :(
For all the testing you've done, I'd be happy to go in on an E2180 or something for you, if you'd like.

EDIT: tried it anyway.

Code: Select all

  frameskip_counter++;
  frameskip_counter %= config::video.frameskip + 1;
  if(frameskip_counter == 0) frameskip_render = rand() % (config::video.frameskip + 1);
  ppu.enable_renderer(frameskip_counter == frameskip_render);

The good news is that things like Link blinking when hit in Zelda 3 and the ZAMN level text bounce work. The bad news is that the video output is a bit more jumpy than without it.

I'll leave it up to you guys to choose which you'd prefer.

[Nach]

Maybe I'll be lazy and special case it based on the ROM size of exactly 48mbits (eg not 40mbits as in FEoEZ ...)

And break Star Ocean, brilliant. Special casing is also evil.

The obvious solution (aside from using external mapping info) is to see if it's large enough to have an Extended HiROM header, if it is, check for it being valid, and if it's valid, ALWAYS map according to it, and don't bother checking elsewhere.

[tetsuo55]

Obviously, you're not able to get 60fps without the frameskip ... very sorry about that
For all the testing you've done, I'd be happy to go in on an E2180 or something for you, if you'd like.

EDIT: tried it anyway.

Code: Select all

  frameskip_counter++;
  frameskip_counter %= config::video.frameskip + 1;
  if(frameskip_counter == 0) frameskip_render = rand() % (config::video.frameskip + 1);
  ppu.enable_renderer(frameskip_counter == frameskip_render);

The good news is that things like Link blinking when hit in Zelda 3 and the ZAMN level text bounce work. The bad news is that the video output is a bit more jumpy than without it.

I'll leave it up to you guys to choose which you'd prefer.

Could you upload a wipwip with the code so we can see for ourselves?

I would LOVE to take you up on that offer, but i would need a completely new system to replace my current crappy one

[Nach]

For all the testing you've done, I'd be happy to go in on an E2180 or something for you, if you'd like.

Isn't that a Pentium 4 family CPU?

[Verdauga Greeneyes]

I would LOVE to take you up on that offer, but i would need a completely new system to replace my current crappy one

What's your current system like? (I'm also trying to remember where you live; I seem to recall you have a PAL SNES but that's as far as I got )

[byuu]

ToP translation fix, which won't break FEoEZ (which has a header in the HiROM region, despite being > 32mbits.)

Code: Select all

  if(cart.rom_size >= 0x401000) {
    if(rom[0x7fc0 + MAPPER] == 0x32) score_lo++; //star ocean
    else if(rom[0x40ffc0 + RESH] >= 0x80) score_ex += 16; //tales, dkjm2
    else; //feoez
  }

Isn't that a Pentium 4 family CPU?

It's labeled as one, but it's really a Core 2 Duo series with some defective cache that was disabled. But the cache doesn't help bsnes out that much. My E2160 @ 1.8GHz gets 60-90fps, and it can easily overclock to ~2.4GHz, so it should be more than enough.

The reason to like them is price: I paid $49 for mine, though it seems to fetch ~$59 on average. Still, much cheaper than the E8400 @ $159.

[Rhapsody]

Isn't that a Pentium 4 family CPU?

The E2180 is a Pentium Dual-Core, which is derived from the Core and Core 2 processors. The E2180 in particular is a 2Ghz Allendale, so it's effectively an E4400 (a Core 2) with half the level 2 cache.

[Deathlike2]

So the problem with ZAMN is not an emulation bug but a problem with the frameskip option?

It sounds to me you've never seen frameskip look awful. In the FF SNES series of games, the cursor tends to flash when highlighting multiple targets with spells.. and when frameskip is used, you will occasionally see "fixed" cursor that either it totally missing or totally solid, which completely doesn't match what the original game does. Personally speaking, that is what you will be living with when frameskip is in use. That's more of a non-issue IMO than anything else.

[FitzRoy]

Lots of games use blinking sprites and frameskip 1 will literally make things invisible or impossible to know if you've been hit. And anything over 1 is an absolute slideshow, I can't imagine anyone actually enjoying themselves with it. Besides, even if bsnes offers frameskipping, who's going to use that when you can get a smooth 60fps with an older emulator? It's really close to being pointless.

[Nach]

ToP translation fix, which won't break FEoEZ (which has a header in the HiROM region, despite being > 32mbits.)

Code: Select all

  if(cart.rom_size >= 0x401000) {
    if(rom[0x7fc0 + MAPPER] == 0x32) score_lo++; //star ocean
    else if(rom[0x40ffc0 + RESH] >= 0x80) score_ex += 16; //tales, dkjm2
    else; //feoez
  }

That looks like you're asking for trouble, but hey, it's your funeral.

Isn't that a Pentium 4 family CPU?

It's labeled as one, but it's really a Core 2 Duo series with some defective cache that was disabled. But the cache doesn't help bsnes out that much. My E2160 @ 1.8GHz gets 60-90fps, and it can easily overclock to ~2.4GHz, so it should be more than enough.

Odd, all the info I can find on it says it lacks SSSE3 and VMX. Sites talking about it must be confusing it with a Pentium 4 if it really is a Core 2.

[Verdauga Greeneyes]

Lots of games use blinking sprites and frameskip 1 will literally make things invisible or impossible to know if you've been hit. And anything over 1 is an absolute slideshow, I can't imagine anyone actually enjoying themselves with it.

I think that's a good argument for using the alternating method byuu whipped up, even if it may make video look a bit more choppy. This sounds better than the old behaviour to me and as bsnes may eventually lose frame-skipping anyway (besides the obvious arguments for using a different emulator in this case) there's not much point in making this an advanced option.

[FitzRoy]

By the way, I tried Zombies and it should be rather obvious why frameskipping makes it look "broken" tetsuo. The way it bounces up and down is equivalent to something blinking. If you're shifting an object from up to down, and all of the up frames are being cut out, it will appear as though it is stationary. Just like if a game is showing a sprite every other frame to achieve a blinking effect, and every other frame gets cut out by frameskip 1, it will either appear invisible or solid depending on the frame the effect was initiated.

[Hatsuyuki]

Updated Russian translation