bsnes v030 released

byuu · Post by **byuu** » Thu Apr 03, 2008 11:19 pm

You probably did it backwards.

You want the first 512kb to be act-rais.ic3, and the second 512kb to be act-rais.ic2. Don't worry about act-rais.ic8.

Also, it takes a while to show up after loading it. No more than 15 seconds, though.

Palin · Post by **Palin** » Thu Apr 03, 2008 11:39 pm

Yup, did it backwards

Dullaron · Post by **Dullaron** » Fri Apr 04, 2008 12:39 am

Oh I did it wrong then. Thanks byuu.

<From Haze> http://www.mameworld.info/ubbthreads/sh ... art=1&vc=1

Deathlike2 · Post by **Deathlike2** » Fri Apr 04, 2008 12:42 am

byuu, the only majorly annoying behavior you somehow added to BSNES is that the keyboard input is generating a system noise in Windows to be played. It becomes very prominant if you hold down a key for long durations. You would never normally notice this if you don't have a sound scheme enabled.

byuu · Post by **byuu** » Fri Apr 04, 2008 12:55 am

byuu, the only majorly annoying behavior you somehow added to BSNES is that the keyboard input is generating a system noise in Windows to be played. It becomes very prominant if you hold down a key for long durations. You would never normally notice this if you don't have a sound scheme enabled.

Don't ask me. I don't get that on my WinXP box, but I've gotten it once or twice on Win2k. Switching window focus fixed it.

I return DefWindowProc() on all WM_KEYUP and WM_KEYDOWN messages, and I poll for and process all pending messages once for every emulated frame. If it is possible to hold a key down and fill the entire Windows keyboard buffer in 1/60th of a second ... then I don't know what to tell you. Nothing I can do about that, because I'm not breaking up SNES::runtoframe() just to clear the message loop more than 60 times a second.

If anyone has ideas, I'd appreciate hearing them.

Deathlike2 · Post by **Deathlike2** » Fri Apr 04, 2008 1:18 am

byuu wrote:
byuu, the only majorly annoying behavior you somehow added to BSNES is that the keyboard input is generating a system noise in Windows to be played. It becomes very prominant if you hold down a key for long durations. You would never normally notice this if you don't have a sound scheme enabled.
Don't ask me. I don't get that on my WinXP box, but I've gotten it once or twice on Win2k. Switching window focus fixed it.

That briefly works, but then it happens again.

Dullaron · Post by **Dullaron** » Fri Apr 04, 2008 1:34 am

I tested all the nss arcade games. All working great.

You didn't even have to mess with anything on bsnes which is good.

I don't know why those sets have extra roms. Must be part of system or some kind of protection. I will careless as long the nss arcade games are running on bsnes.

Gil_Hamilton · Post by **Gil_Hamilton** » Fri Apr 04, 2008 1:40 am

Dullaron wrote:I tested all the nss arcade games. All working great.

You didn't even have to mess with anything on bsnes which is good.

I don't know why those sets have extra roms. Must be part of system or some kind of protection. I will careless as long the nss arcade games are running on bsnes.

I suspect the extra ROM image is for the overlay text.
Been a while since I've seen one, but I believe the NSS had a text instruction overlay you could call up, as well as the obvious credit/time notes.

Dullaron · Post by **Dullaron** » Fri Apr 04, 2008 8:02 am

Test out F-Zero on Mame and bsnes. I saw that F-Zero on Mame is missing some graphics and colors. Also the colors are darker on Mame. F-Zero have everything there on bsnes. Mame already report that all the nss arcade games have issues.

You have to blown the snapshots to see what is missing.

Oh yea one more thing. There is 3 dots on the top screen on Mame. I have no idea what that is. Doesn't show on bsnes screen.

etabeta · Post by **etabeta** » Fri Apr 04, 2008 9:24 am

nss is very close to snes hardware-wise. every difference you can notice on MAME vs BSNES is 99.999% due to incomplete emulation of snes hw in the former (which shares the code in MESS, known to be only partial: it's the reason you get a red screen at start saying the emulation is not perfect

)

on the other hand, nss had an additional 'menu' system which added the already mentioned overlays, the coins/timer and (iirc) allows you to have more than one cart in the same cabinet. this menu system is completely undocumented (and Reip spent some time digging into the code with no success) and it's the reason you have those additional roms

once made correctly working, NSS should work like a real Playchoice 10 with snes carts

byuu · Post by **byuu** » Fri Apr 04, 2008 4:32 pm

Deathlike2 wrote:byuu, the only majorly annoying behavior you somehow added to BSNES is that the keyboard input is generating a system noise in Windows to be played. It becomes very prominant if you hold down a key for long durations. You would never normally notice this if you don't have a sound scheme enabled.

Found it.

Code: Select all

bool pHiro::run() {
  MSG msg;
  if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) {
    //the below line is causing the beeping
    if(!IsDialogMessage(GetParent(msg.hwnd) ? GetParent(msg.hwnd) : msg.hwnd, &msg)) {
      TranslateMessage(&msg);
      DispatchMessage(&msg);
    }
  }
  return pending();
}

I'm not implementing my own clone of IsDialogMessage() to avoid fucking up the keyboard buffer clearing. So, you guys pick. Would you rather have the tab key working in the UI, or no beeping on some systems? I'm partial to the latter, myself.

byuu · Post by **byuu** » Mon Apr 07, 2008 3:34 am

New WIP.

Direct3D driver: removed diffuse color vertex information, and made driver re-initialize whenever window size changes. Should fix ATI resize in pixel scale mode bug once and for all. Confirmation would be appreciated. Speed will still be bad on some cards that can't handle large textures, and I don't really want to implement StretchRect() profiling, so that's still an issue.

Windows/hiro: disabled IsDialogMessage(). This will prevent the tab key from working in the configuration panel, but will also stop the main window from beeping every time you push a key -- the lesser of two evils. Blame Microsoft for this bullshit. IsDialogMessage() should empty the key buffer, but it doesn't when there are no tabbed controls on a window. I'll rig something up in the future for this.

Linux/hiro: GTK+ file open / file save / folder select dialogs will now save the path if you selected a valid file, so that next time you will start in that folder. This didn't matter if you set hard-coded paths in bsnes, but it makes a positive difference if you did not.

byuu · Post by **byuu** » Mon Apr 07, 2008 4:32 am

New bsnes subsection.

http://byuu.cinnamonpirate.com/bsnes/errata/

I don't intend to hide bugs in bsnes' emulation from the general public. If anyone knows of additional flaws, and can prove them (eg with a trimmed, explicit hardware test ROM), I'll add them to the list. Things such as the Mecarobot bug do not belong, because we don't yet understand the underlying mechanism of the bug.

I'll go ahead and put a bounty on one of them, myself. $100 to the man who figures out what the hell is up with IRQB / NMIB timing. I want to know what the hardware is doing, not how to bullshit the timing (I can do that now myself.) The solution must not rely upon lookup tables for the previous opcode. There's no fucking way hardware is doing anything like that. If it turns out the CPU is reading from another address for the second IRQ pseudo-opcode cycle, then I'll pay $150 to know how to calculate that address.

While we're at it, I'll put $100+ on a proper hardware fix for Meacrobot, too. Why not?

If you want even more money, we can discuss it.

I want this badly, because it's the last thing standing in the way of truly perfect IRQ timing.

Dullaron · Post by **Dullaron** » Mon Apr 07, 2008 8:36 am

Why not post this over here at too? http://www.mameworld.info/ubbthreads/ub ... s.php?Cat=

Just to see any of those guys pop up with something.

byuu · Post by **byuu** » Mon Apr 07, 2008 8:39 am

What's the point? None of them work on SNES emulation.

I do bounce questions off of them on other matters. Aaron had some ingenius ideas for cothreading, for instance.

Dullaron · Post by **Dullaron** » Mon Apr 07, 2008 8:44 am

1. Ok I see your point. >>> They don't work on bsnes.

2. Oh ok.

Fes · Post by **Fes** » Thu Apr 10, 2008 2:08 am

It looks like you've found a fix for the keyboard beeping issue, but I just thought I'd jump in with an observation I made in 0.30, as this is the issue that caused me to search the forums in the first place.

At first I thought it was odd that it seemed to start happening at a random time after having pressed some keys, but once it started it wouldn't stop until focus was switched away and back. A little trial-and-error later it appears that, at least on my rig (xp32 sp2), it only starts happening after pushing the following keys:

Down arrow
Right arrow
Tab

Knowing that, I changed my directional controls to the numpad (with numlock on) and it no longer happens at all. Just thought I'd pass this along to anyone else still using 0.30 and wants an easy way to avoid the beeping.

byuu · Post by **byuu** » Thu Apr 10, 2008 11:05 am

New WIP posted, which adds the immediate-mode opcode IRQ delay findings from this past week. Doesn't have any visible effects on anything. I also went back to a switch table for the CPU / SMP opcodes instead of the jump table. Shaves ~100kb off the object files and compiles faster with no speed loss. I used the jump table before to simplify PGO, but since that's been broken for at least a year now anyway ...

Fes, thanks for the temporary workaround. I'll try and get a new release out this weekend if possible. I'd like to have UPS soft-patching in before the next release, though, hence the delay.

DataPath · Post by **DataPath** » Thu Apr 10, 2008 2:52 pm

Fes wrote:It looks like you've found a fix for the keyboard beeping issue, but I just thought I'd jump in with an observation I made in 0.30, as this is the issue that caused me to search the forums in the first place.

At first I thought it was odd that it seemed to start happening at a random time after having pressed some keys, but once it started it wouldn't stop until focus was switched away and back. A little trial-and-error later it appears that, at least on my rig (xp32 sp2), it only starts happening after pushing the following keys:

Down arrow
Right arrow
Tab

Knowing that, I changed my directional controls to the numpad (with numlock on) and it no longer happens at all. Just thought I'd pass this along to anyone else still using 0.30 and wants an easy way to avoid the beeping.

Based on that sequence of keys, it looks to me like it could be a control got input focus that wasn't expecting it, and thus the windows "thunk" sound.

Fes · Post by **Fes** » Thu Apr 10, 2008 9:47 pm

That's my hunch as well. I haven't done much win32 development (more of a .NET guy myself), but my debugging sense is tingling, saying something is going funny with input focus. It just feels too deterministic and consistent to be random buffer filling.

And just to clarify, the behavior happens after pushing any one of those keys, not just after pushing all of them.

DataPath · Post by **DataPath** » Thu Apr 10, 2008 9:57 pm

Fes wrote:That's my hunch as well. I haven't done much win32 development (more of a .NET guy myself), but my debugging sense is tingling, saying something is going funny with input focus. It just feels too deterministic and consistent to be random buffer filling.

And just to clarify, the behavior happens after pushing any one of those keys, not just after pushing all of them.

Nevertheless, it sounds like input focus is moving to something (the next thing in the tab order, probably, since tab, down, and right all signify "next") that doesn't like having input focus.

edit: It occurs to me that one way to strengthen this theory would be to check and see if <Shift>+<Tab> fixes the problem. It wouldn't prove or disprove the theory either way, but it would give us a better idea.

Fes · Post by **Fes** » Thu Apr 10, 2008 10:15 pm

Heh, actually I just tried that a few minutes ago. Great minds and all that. Unfortunately, it had no effect. At least as I understand it though, tab order isn't guaranteed to work both ways under all conditions, so if focus is indeed arriving at some errant control, the tab order could very well become trapped as well.

EDIT: Quick followup. I just tried doing shift-tab BEFORE the behavior starts, and it does NOT trigger it. So at least we have further consistency in that only forward-order commands trigger it.

-toolkiks- · Post by **-toolkiks-** » Thu Apr 10, 2008 11:45 pm

I am also experiencing the "Default Beep" when using one of the keys Fes mentioned. It began with version .29. I waited to see if anyone else was experiencing it before mentioning the "issue." I wasn't sure if it was just my system. I actually tried it on 3 different machines...2 Dell Latitudes and one Dell Optiplex.

Thanks byuu, never thought I'd enjoy SNES emulation this much.

Dullaron · Post by **Dullaron** » Fri Apr 11, 2008 10:54 am

I have the short cut keys turn off on my computer. No beep and no short cut keys option pop up. I haven't had a problem yet.

-toolkiks- · Post by **-toolkiks-** » Sat Apr 12, 2008 6:36 am

Are you referring to Sticky Keys, rather than shortcut keys? If so, I do have Sticky Keys disabled. If this is incorrect, please explain.