bsnes v0.036 released

[henke37]

It's a still picture, of course that is there too while you are trying to load the cart.

[Panzer88]

Hey byuu do you remember when you found out you were partially color blind when you were adjusting the color settings in bsnes and you adjusted it to display more colors, and more accurately. At that time I think there was an even higher setting that displayed more colors. I know the visual difference would probably be negligible but I was wondering how much of a speed hit that would cause.

thanks ~Panzer

[Verdauga Greeneyes]

bsnes uses a runtime-generated colour look-up table to convert from the SNES' 15-bit BGR555 to the standard 32-bit XRGB888 (well, it only uses 24 bits). That's what your monitor is most likely using, so you can't get better quality than that. (except by compensating for the monitor's ICC profile, and as the firefox developers are noticing, a lot of people have broken profiles installed) What you might be referring to is the algorithm bsnes uses to generate the colour table. There was a lot of discussion about this, and what bsnes uses optimises for a regular spread of peaks in colour differences. At the time I suggested an alternative that minimises the standard deviation from the floating point optimal values. The differences are minimal though, and it's still not truly clear which of the two is optimal.

[_willow_]

bsnes uses a runtime-generated colour look-up table to convert from the SNES' 15-bit BGR555 to the standard 32-bit XRGB888 (well, it only uses 24 bits). That's what your monitor is most likely using, so you can't get better quality than that. (except by compensating for the monitor's ICC profile, and as the firefox developers are noticing, a lot of people have broken profiles installed) What you might be referring to is the algorithm bsnes uses to generate the colour table. There was a lot of discussion about this, and what bsnes uses optimises for a regular spread of peaks in colour differences. At the time I suggested an alternative that minimises the standard deviation from the floating point optimal values. The differences are minimal though, and it's still not truly clear which of the two is optimal.

@All:

I'm curious can be this kind of processing (15-bit->24 bit expansion, or may be HDR texture?) off-loaded to GPU shader processors? I'd like to hear every image processing operation can be done with expansive computing, moreover with no real CPU usage hit. Is it real?

[Verdauga Greeneyes]

I'm curious can be this kind of processing (15-bit->24 bit expansion, or may be HDR texture?) off-loaded to GPU shader processors? I'd like to hear every image processing operation can be done with expansive computing, moreover with no real CPU usage hit. Is it real?

In a word: yes.

Shaders work by independently processing each pixel of the output rect. This means that if you have say, 120 shading units, 120 pixels can be processed in parallel, so scalability is very high. However, shading units are fairly slow and simple compared to your CPU, not to mention the fact that they operate at lower precision, so some of the advantage is lost. Also, because each pixel is processed independently you can be forced into doing a lot of extra work (i.e. calculate some constant value for each pixel). Still, just look at projects like Nvidia's CUDA and AMD's CAL and you'll see that there's definitely potential. Of course, massive parallellisation is also very good for ray-tracing, so we might see more of that in the future.

In this case there's not much point to doing it, as the look-up table is generated when bsnes is first started, and using it incurs almost no speed hit.

[byuu]

The only thing the lookup table will do is add a tiny cache hit. But it's very insignificant to speed.

Verdauga, if you wanted to post some pictures and a table generator for your idea, and people like it, I suppose we could add it. But yeah, it's difficult for this color adjustment thing to work precisely, since we don't know what the monitor is actually displaying. I have the gamma ramp checkbox only because it does something none of the sliders can do: only adjust the bottom half of the ramp.

[Verdauga Greeneyes]

Verdauga, if you wanted to post some pictures and a table generator for your idea, and people like it, I suppose we could add it.

If anyone could tell the difference, I would be very impressed. But the change is quite simple:

Code: Select all

    col = (255 * (i       & 31) + 15) / 31 << 16
        | (255 * (i >>  5 & 31) + 15) / 31 <<  8
        | (255 * (i >> 10 & 31) + 15) / 31;

As you can see, some multiplication and division is involved, which the current approach doesn't have. Though I don't think it'll make much of a difference in this case.
If you were asking about colour management, I really don't know much about it ... would be nice if monitors actually came with decent ICC profiles, but I know for a fact the one I got with my new monitor is broken, as it completely screws up the firefox nightlies that have colour management enabled. (white becomes yellow and grey becomes purple )

[Verdauga Greeneyes]

Some statistics. Columns 3 and 5 are the differences between subsequent colours - the peak distribution. Note that 8-bit-byuu has a very regular distribution ... but whether this actually means anything aside from looking pretty I don't know. As you can see at the bottom, my version is slightly closer to the floating point optimal, but the difference is minimal.

Code: Select all

5-bit  8-bit-byuu  8-bit-ver  floating point
00     000  x      000  x     000.0000000
01     008  8      008  8     008.2258065
02     016  8      016  8     016.4516129
03     024  8      025  9     024.6774194
04     033  9      033  8     032.9032258
05     041  8      041  8     041.1290323
06     049  8      049  8     049.3548387
07     057  8      058  9     057.5806452
08     066  9      066  8     065.8064516
09     074  8      074  8     074.0322581
10     082  8      082  8     082.2580645
11     090  8      090  8     090.4838710
12     099  9      099  9     098.7096774
13     107  8      107  8     106.9354839
14     115  8      115  8     115.1612903
15     123  8      123  8     123.3870968
16     132  9      132  9     131.6129032
17     140  8      140  8     139.8387097
18     148  8      148  8     148.0645161
19     156  8      156  8     156.2903226
20     165  9      165  9     164.5161290
21     173  8      173  8     172.7419355
22     181  8      181  8     180.9677419
23     189  8      189  8     189.1935484
24     198  9      197  8     197.4193548
25     206  8      206  9     205.6451613
26     214  8      214  8     213.8709677
27     222  8      222  8     222.0967742
28     231  9      230  8     230.3225806
29     239  8      239  9     238.5483871
30     247  8      247  8     246.7741935
31     255  8      255  8     255.0000000

mean difference from floating point:
8-bit-byuu: 0.2741935
8-bit-ver:  0.2419355

[_willow_]

Thats right. The differences are minor. Both columns are equally good. That column you can compute faster, the better one. BTW, i think OpenGL & Direct3D are able to display the floating point texture, aren't they?

[Verdauga Greeneyes]

Well, I know for a fact that the GLSL (OpenGL shaders) treats colour as a normalised floating point vector, but whatever happens during the rendering pipeline, it still has to send it to the monitor in a standard format eventually.. unless that's not what you're asking.

[_willow_]

So do the 3D rendering circuit interpret colors as floating point vector internally? I bet it do just for gamma correction, bilinear interpolation or for whatever reason. And so we have precision loss on float->integer->float->integer conversion for the moment.

[Verdauga Greeneyes]

And so we have precision loss on float->integer->float->integer conversion for the moment.

Well, in the shaders it takes each colour channel seperately, so you convert three 8-bit integers to three 32-bit floating point values.. no precision loss there. Of course, there's no telling what it's doing internally.

[_willow_]

There is a quality loss on values getting extension twice:

5bit integer -> 8bit integer -> floating point.

besides, you comparing the quality of 5bit integer to 8bit integer transformation by floating point standard yourself. Why to guess then, let the video chip decide what to do with floating point vector. More likely it would be native for GPU and SNES all together.

why not just use 5bit integer -> floating point translation table for 3D API's?

[byuu]

Finally got belegdol's Polish locale up. Thank you again for that!

New WIP. The main thing is that all of the "Load N Cartridge ..." options have been merged into one. Here's how it works:

- Load a normal cart, and the game starts right away.
- Load a BS-X slotted cart, and you get a window with the slotted cart set to base, and the slot section empty. You can use Same Game + SG-FEoEZ or whatever to test.
- Load a Sufami Turbo cart, and you get a window with the BIOS set to whatever was used last (blank for the first time), the ST cart assigned to slot A, and slot B blank. The ST won't actually play any games with a cart only in slot B ... but it does display a unique error message if you try. You can always clear slot A and then assign again to slot B if you want.

Another benefit is this works with command-line loading, too. Before, it was impossible to load BS-X / ST games from the console / bsnes executable association. There is a bit of a lag in startup, as always, so that's a bit noticeable.

Right now, I'm missing the algorithm for BS-X flash cart detection ... Nach, I don't suppose you'd mind posting that for me, please?

Further, in the future I'd like to also detect the BS-X and ST BIOS files, and assign those and show windows with all slots empty.

FitzRoy, if you want to mess around with the System menu layout again, that's cool. Just keep in mind that "Power Cycle" is still there in advanced mode. It looks tacky with load+unload+reset+powercycle with no separator.

Unload cart does appear to have limited use, so if necessary, we can consider removing that, I suppose :/

[Verdauga Greeneyes]

why not just use 5bit integer -> floating point translation table for 3D API's?

Hmm, well I see that Direct3D does support floating point formats for the back buffer (i.e. D3DFMT_A32B32G32R32F), but I don't know if all the drivers bsnes supports do or, for that matter, if all graphics cards support them. In the end it only matters if you plan to modify the colours using shaders, as the integer conversion is simply the floating point conversion rounded to the nearest integer, which is what the monitor ends up using anyway. (I think! There's colour management too, but I don't know what type of input -that- takes...) Still, I think you brought up an interesting point there

[byuu]

Oh yeah, because I merged the image loading to one routine; it means BS-X and ST images will now remove headers if they exist.

What do you guys think? Should I take a stand against this absurdity and manually disable header removal for these systems, or compensate to sites like this that keep copier headers on BIOS images?

(Neat site though, be sure to check out the main index.)

---

Also, have some BS-X detection code. It's not pretty, but Derrick verified it against a complete image set, and it passes 100% of the time.

http://cinnamonpirate.com/hobby/docs/bsx-info/

Code: Select all

/**
	 * Tests if a loaded ROM is a Broadcast Satellaview ROM.
	 *
	 * @return bool
	 * @access public
	 */
	private function is_satella()
	{
		
		if(($this->_data{$this->_infoblock + 0x24} == "\0" && $this->_data{$this->_infoblock + 0x25} != "\0" && ord($this->_data{$this->_infoblock + 0x24}) % 0x10 == 0x0) && (in_array($this->_data{$this->_infoblock + 0x25}, array("\0", "\x80", "\x84", "\x9c", "\xbc", "\xfc")) && in_array($this->_data{$this->_infoblock + 0x23}, array("\0", "\xff"))))
			return(true);
		else
			return(false);
		
	} // is_satella();
(11:36:09 AM) Derrick: 	## Test if loaded ROM is a Broadcast Satellaview ROM.
	def issatella(self):
		## Ported from OLD code. Nees a clean up.
		if self._data[self._infoblock + 0x24] == "\0":
			if ord(self._data[self._infoblock + 0x29]) % 10 == 0:
				if self._data[self._infoblock + 0x25] == "\0" or self._data[self._infoblock + 0x25] == "\x80" or self._data[self._infoblock + 0x25] == "\x84" or self._data[self._infoblock + 0x25] == "\x9c" or self._data[self._infoblock + 0x25] == "\xbc" or self._data[self._infoblock + 0x25] == "\xfc":
					if self._data[self._infoblock + 0x23] == "\0" or self._data[self._infoblock + 0x23] == "\xff":
						return(True)
		else:
			return(False)

Conversion:

Code: Select all

  if(data[index + 0x13] == 0x00 || data[index + 0x13] == 0xff) {
    if(data[index + 0x14] == 0) {
      uint8_t n15 = data[index + 0x15];
      if(n15 == 0x00 || n15 == 0x80 || n15 == 0x84 || n15 == 0x9c || n15 == 0xbc || n15 == 0xfc) {
        info.bsx = true;
      }
    }
  }

Seems to work good enough, I guess ...

[grinvader]

Code: Select all

      if(n15 == 0x00 || n15 == 0x80 || n15 == 0x84 || n15 == 0x9c || n15 == 0xbc || n15 == 0xfc) {
        info.bsx = true;
      }

Ugh. I hope the compiler sorts this out. Else, use this.

Code: Select all

info.bsx = (n15 == 0x00 || n15 == 0x80 || n15 == 0x84 || n15 == 0x9c || n15 == 0xbc || n15 == 0xfc);

Geeze.

[tetsuo55]

New WIP. The main thing is that all of the "Load N Cartridge ..." options

Awesome, You combined the best parts of everyones ideas and made it even better

Unload cart does appear to have limited use, so if necessary, we can consider removing that, I suppose :/

Well it should guarantee a fresh start(like a cold boot) for all registers(i suppose regular load works like this too). The reason it looks/works strange now is because "Load Cartidge ..." does not get greyed out, basically making it useless.
It would add an extra step to loading a new game while one is running, not sure if we really want to do this if the load over current game function is already perfect (all memory and registers get a full reset like cold boot)

Oh yeah, because I merged the image loading to one routine; it means BS-X and ST images will now remove headers if they exist.

What do you guys think? Should I take a stand against this absurdity and manually disable header removal for these systems, or compensate to sites like this that keep copier headers on BIOS images?

(Neat site though, be sure to check out the main index.)

Do the headers get physically removed or only in memory?

Personally i don't see the point to headers(i apply them on the fly when testing on hardware), if you decide to not remove headers from bioses you might as well disable it completely. You could add a header removal tool to the non-wip releases zip folder

[byuu]

Ugh. I hope the compiler sorts this out. Else, use this.

Code: Select all

info.bsx = (n15 == 0x00 || n15 == 0x80 || n15 == 0x84 || n15 == 0x9c || n15 == 0xbc || n15 == 0xfc);

Geeze.

How unbearably inefficient, when I could be using this instead:

Code: Select all

#define n data[index + 0x15] or const uint8_t n = data[index + 0x15];
info.bsx = uint8_t(data[index + 0x13] + 1) < 2 && !data[index + 0x14] && (!(n & 0x7f) || n == 0x84 || n == 0x9c || n == 0xbc || n == 0xfc);

Still wasteful, all that excess space ... like we're worried about readability or something. Hmm ...

Code: Select all

#define n d[i+21]
info.bsx=(d[i+19]+1&0xff)<2&&!d[i+20]&&(!(n&127)|n==132|n==156|n==188|n==252);

There we go, much better.

[grinvader]

Why didn't you put that to begin with, then ? *sigh*

[creaothceann]

I think (or at least hope) that byuu is joking with his last post. :/

[byuu]

I believe we were both joking around. Again, hopefully :)
Note: now that I'm looking more closely, maybe he was thinking that I wasn't initializing info.bsx. The entire info_t structure is initialized directly above this code. It is false by default, so we need only set it to true, if needed. But then, his correction wouldn't have addressed that fully either, so probably not ...

Combining multiple actions into a single line on one of the absolute coldest sections of code would be beyond pointless.

I know where the hot spots in my code are, and they're as optimized as they get. It's the model I use that's the problem with speed, not the finest minutiae of detail.

I'm sure grinvader is aware that while I'm not as skilled as blargg, I'm still quite good with the low level optimizations. Yes, believe it or not, I do know how to write efficient code. For instance, this code is called on every memory address access:

Code: Select all

  //fastSpeed = 6 or 8, based on $420d.d0
  alwaysinline unsigned speed(unsigned addr) const {
    if(addr & 0x408000) {
      if(addr & 0x800000) return fastSpeed;
      return 8;
    }
    if((addr + 0x6000) & 0x4000) return 8;
    if((addr - 0x4000) & 0x7e00) return 6;
    return 12;
  }

It implements this:
http://www.romhacking.net/docs/memmap.txt

Code: Select all

  Banks  |  Addresses  | Speed | Mapping
---------+-------------+-------+---------
 $00-$3F | $0000-$1FFF | Slow  | Address Bus A + /WRAM (mirror $7E:0000-$1FFF)
         | $2000-$20FF | Fast  | Address Bus A
         | $2100-$21FF | Fast  | Address Bus B
         | $2200-$3FFF | Fast  | Address Bus A
         | $4000-$41FF | XSlow | Internal CPU registers (see Note 1 below)
         | $4200-$43FF | Fast  | Internal CPU registers (see Note 1 below)
         | $4400-$5FFF | Fast  | Address Bus A
         | $6000-$7FFF | Slow  | Address Bus A
         | $8000-$FFFF | Slow  | Address Bus A + /CART
---------+-------------+-------+---------
 $40-$7D | $0000-$FFFF | Slow  | Address Bus A + /CART
---------+-------------+-------+---------
 $7E-$7F | $0000-$FFFF | Slow  | Address Bus A + /WRAM
---------+-------------+-------+---------
 $80-$BF | $0000-$1FFF | Slow  | Address Bus A + /WRAM (mirror $7E:0000-$1FFF)
         | $2000-$20FF | Fast  | Address Bus A
         | $2100-$21FF | Fast  | Address Bus B
         | $2200-$3FFF | Fast  | Address Bus A
         | $4000-$41FF | XSlow | Internal CPU registers (see Note 1 below)
         | $4200-$43FF | Fast  | Internal CPU registers (see Note 1 below)
         | $4400-$5FFF | Fast  | Address Bus A
         | $6000-$7FFF | Slow  | Address Bus A
         | $8000-$FFFF | Note2 | Address Bus A + /CART
---------+-------------+-------+---------
 $C0-$FF | $0000-$FFFF | Note2 | Address Bus A + /CART

Note 2: If bit 1 of CPU register $420d is set, the speed is Fast, otherwise
  it is Slow.

I would be extremely impressed if anyone here could optimize that any further. And no, a memory lookup table is not faster on modern processors.

[FitzRoy]

FitzRoy, if you want to mess around with the System menu layout again, that's cool. Just keep in mind that "Power Cycle" is still there in advanced mode. It looks tacky with load+unload+reset+powercycle with no separator.

Unload cart does appear to have limited use, so if necessary, we can consider removing that, I suppose :/

I think it's useful, sometimes I feel like returning to that state just to sit there to think in peace for a moment. Anyone who has the emulator window set to keep running while unfocused would definitely want to do this from time to time.

Now that you have that loading detection, my suggestion would be this:

Code: Select all

Cartridge Port...
-------------------
Power >             [x]On [ ]Off
Reset
-------------------
Controller Port 1 >  ""
Controller Port 2 >  ""
-------------------
Expansion Port >    [x] None [ ] Broadcast Satellaview-X

4 ports, 2 switches (one with two settings). Exactly like the real SNES. Power cycle can appear above reset in advanced mode. Exit should either find a new home or be eliminated in favor of the title bar cross.

This obviously tosses aside the plastic blockage stuff. An SNES cartridge played when the system was electrified, it makes no difference if it got there while it was electrified or before.

[byuu]

Not too wild about "Cartridge Port ...", although I see the logic. Describe what each is rather than what each does. But it might confuse some people.

Power off+on makes power cycle redundant. I'll just remove that, but leave the key binding.

I like being able to take the Satellaview on and off, and if we ever track down the mythical SNES CD player add-on, or pay someone to design an ASIC so we have an excuse to "emulate" such a thing, it would fit in great there. Too bad I can't design real hardware.

I suppose we'll default to having the BS-X base attached. It shouldn't affect any non-BSX games. Not going to add the expansion port option just yet, as it's a bit of work. Will wait until I get into BS-X RE mode for that.

We'll have cart insertion auto-power on the system, and I guess power off will just be a special pause state, to keep the game in-memory.

Removing exit ... I just don't know. It's a pretty bold move. I can't think of a single application without a quit option in the main menu. I know, there's the X at the top right (what 99% of people use). And you can escape out of fullscreen mode easily enough, though it's slightly handy to have the exit option there in case people forget the shortkey to exit fullscreen mode. But yeah, it's really pushing it ...

Overall, very nice. Thanks for the suggestions.

[_willow_]

byuu:

fairly the same just less letters,

Code: Select all

alwaysinline unsigned speed(unsigned addr) const {
  return (addr & 0x408000)
    ?
    ((addr & 0x800000) ? fastSpeed : 8)
    :
    (((addr + 0x6000) & 0x4000) ? 8 : ((addr - 0x4000) & 0x7e00) ? 6 : 12);
}

Hmm, well I see that Direct3D does support floating point formats for the back buffer (i.e. D3DFMT_A32B32G32R32F), but I don't know if all the drivers bsnes supports do or, for that matter, if all graphics cards support them. In the end it only matters if you plan to modify the colours using shaders, as the integer conversion is simply the floating point conversion rounded to the nearest integer, which is what the monitor ends up using anyway. (I think! There's colour management too, but I don't know what type of input -that- takes...) Still, I think you brought up an interesting point there

Well i did ask my OpenGL skillful mates and they agreed the GPU do all kind of the computing in floating point internally and our colors too. Any texture gets transformed into normilized floating point colors with no distinction of the source. It's simply the nature of the nowadays GPU's. And so they do the gamma correction, bilinear filtering and all duties in floating point standard.
I see the best solution is to use floating point for 3D and 8bit unsigned integers for 2D renderers. And so i'd stay until you provide the tech sheets which would say the GPU indeed compute the colors in integer. I mean not DAC, which is of cource producing integers, but the rendering core that do image scaling for us and possibly the other things.