2011-12-31 - bsnes_v084r08.tar.bz2 (Windows binary included.)
Okay, everything can now load XML again, including board layouts for all three systems. New is the ability to load external Game Boy layouts (not really that useful, but it's there.)
I'd like to aim for a v085 release soon. I've included a binary, so I'd appreciate testing. I had to redo all of the XML mappings for every system (I like consistency), so basically the following things need to be tested:
load one of every type of game for every system (every NES board type, every Game Boy MBC type, every SNES chip and layout type.)
test cheat codes and the cheat database
test pixel shaders for OpenGL and Direct3D (sepia for the win)
test anything else for v085 release
2011-12-30 - bsnes_v084r07.tar.bz2
Added the new super-fast XML parser. So far, the shaders, cheat files, and cheat database have been updated to allow XML mode once again. Which is sure to please Screwtape =)
So it's down to just the cartridge mapping files now, which are always a major pain.
I still think BML is better for parsing simplicity, memory usage, disk size, lack of red tape and speed (but horrendously bad for ease of creating files manually), but since the base API is identical, there's no reason not to support both. Especially since the pixel shaders have kind of taken on a life of their own.
HuC1 flag sets RAM writable, not RAM enable (fixes Pokemon Card)
removed within<> template, didn't turn out to be all that useful
I would be almost certain no games would break by allowing reads when it is disabled, no game would rely on that behavior.
I prefer to be overly restrictive. Better to not allow valid behavior than to allow invalid behavior. The latter is what gives us a dozen broken SNES translations.
2011-12-17 - bsnes_v084r05.tar.bz2
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to $4016/4017/4201/4213, but that doesn't work because the controllers have access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am guessing because the days of massive development are long over, and the code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of the time.
Did the same for the Super Scope: it may not have the same problem, but I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and Justifier games.
But ... at least it works now. Slow and working is better than fast and broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on Debian.
2011-12-11 - bsnes_v084r04.tar.bz2
Fixed the Ys 5 input bug in the auto joypad polling code. Can't guarantee it's hardware-accurate (I have no way to extensively test it), but I can guarantee it is closer to being correct now.
Also uses updated version of phoenix.
The justifier input is indeed all fucked up now. Seems like it stops updating input after firing for a few frames.
I really don't want to debug that code anymore ... anyone want to make $10 by fixing it? :P
2011-12-03 - bsnes_v084r03.tar.bz2
snesfilter_20111202.tar.bz2
Internally, all color is processed with 30-bit precision. The filters also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24. This causes the final output to downsample to 24-bit, as most will require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will ask ruby for a 30-bit surface. If you don't have one available, you're going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate visual in place.
30-bit mode will really only work if you are running Linux, running Xorg at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD FireGL card with the official drivers, and have a 30-bit capable monitor.
Lots of planning and work for very little gain here, but it's nice that it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but they still work and look nice.
2011-11-16 - bsnes_v084r01.tar.bz2
I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further.
This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
2011-11-07 - bsnes_v084-source.tar.bz2
This release adds preliminary Game Boy Color emulation. Due to lack of technical information, this is undoubtedly the least stable module I provide at this time; but improvements should continue as it is developed.
This release also polishes the NES emulation and user interface code.
Changelog:
added preliminary Game Boy Color emulation
NES: added MMC6, VRC1, VRC2, VRC3 emulation
NES: fixed MMC5 banking and added split-screen support [Cydrak]
NES: pass all of blargg's ppu_vbl_nmi tests, pass more sprite tests
NES: palette is now generated algorithmically [Bisqwit]
SNES: fixed SA-1 IRQ regression caused by code refactoring
Game Boy: rewrote audio channel mixing code; sound output is greatly improved as a result
Game Boy: uses DMG boot ROM instead of SGB boot ROM
Game Boy: fixed potential bug when loading save states
phoenix: fixed ListView focus issue [X-Fi6]
phoenix: fixed dialog message parsing [X-Fi6]
ui: video output is truly 24-bit now; SNES luma=0 edge case emulated
ui: audio frequency, latency, resampler are now user configurable
ui: gamma ramp is dynamically adjustable
ui: all filters ported to 24-bit mode (speed hit to HQ2x)
ui: added turbo button mappings for all generic controllers
ui: fixed audio volume on unmute via menu [Ver Greeneyes]
ui: shrink window option does nothing when no cartridge is loaded
ui: re-added compositor disable, driver verification from v082
2011-11-03 - bsnes_v083r10.tar.bz2
Changelog:
NES: added VRC1, VRC2, VRC3, MMC6 emulation
shrink window doesn't do anything when no cartridge is loaded
phoenix Horizontal,VerticalLayout use const Size& instead of unsigned width,height [for consistency]
So, all official NES ASICs are supported now. Just need sound output for MMC5+VRC7 to complete them; and then some board re-arrangement stuff for VRC2+MMC3.
Note that MMC6 uses the same mapper ID as MMC3, and VRC2 uses the same ID as VRC4, so you have to make a BML board mapping or toggle which type is chosen in the source file to use these two chips.
2011-10-31 - bsnes_v083r09.tar.bz2
Specifically asked not to be bugged about L/R turbo, sigh :(
Added frequency, latency, resampler selection to the audio settings panel (I really only wanted it there for resampler selection ... having three options matches the driver selection style though, so whatever.)
The linear/hermite sampler will double the framerate when running Game Boy games, and sounds the same. Same framerate and sound quality on SNES. But it will cause buzzing in many NES titles.
Also re-added the composition { never, fullscreen, always } modes. I think that option is clutter, but it's just impossible to get good audio+video on Windows 7 without it ...
Lastly, HQ2x was ported over, but not very well. I just convert source pixels from RGB888 to RGB555, and output pixels in the opposite direction.
Need someone good to port the diff() and blend functions over to RGB888 in a way that's not terribly slow.
2011-10-29 - bsnes_v083r08.tar.bz2
Fixed SA-1 IRQ regression for Super Mario RPG
Added turbo B,A to NES+GB; B,A,X,Y to SNES (please don't ask for turbo L,R; you never use those keys rapidly.)
Re-added video color adjustments, which are now done in full 8-bit colorspace for more precision
Gamma ramp option is gone. It's now the gamma option, which now only affects the lower-half of the colors.
A value of 1.0 gives you the original, washed out colors. 1.75 is what the gamma ramp checkbox used to do (roughly).
The new default is 1.5, which still prevents color washout, but isn't as overly dark as before.
I wanted to make the core/interface stuff abstract the complexity of setting up a new C++ class, but it really didn't make anything easier. It was all one-line stubs to internal functions, and there was just too many platform-specific things that needed to be captured, so I did away with that. Made a base class for the ui/interface stuff to get rid of a lot of switch(mode()) stuff, still a work in progress.
2011-10-28 - bsnes_v083r07.tar.bz2
Game Boy: audio should sound a lot better, eg Zelda: DX first opening scene
Game Boy Color: now uses cothread Processor::frequency to dynamically clock GB-CPU to 8MHz. Proper OAM DMA and timer speed. Fixes SMT: DC - WB audio.
Added the break; statements to phoenix/windows/platform message loop
Added audio latency/frequency to config file only
2011-10-27 - bsnes_v083r06.tar.bz2
All cores: Video classes have internal->{RGB30,24,16,15} palette generation support
All cores: video output is now RGB24, all filters except HQ2x were updated to reflect this (HQ2x will be very hard)
NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF) [Cydrak]
NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak]
Game Boy + Game Boy Color: fixed a potential freezing bug when loading save states (re-create cothreads on state load; was implied when using SGB mode.)
Game Boy Color: fixed freezing bug with Zelda: DX opening (SVBK is readable.)
SNES: luminance of zero is no longer pure black, as on real hardware. This is possible thanks to using RGB888 output now.
2011-10-25 - bsnes_v083r05.tar.bz2
NES: passes ppu_sprite_overflow tests 01, 02, 05.
Game Boy: uses DMG BIOS (the one with the slow title scroll) or SGB BIOS, based upon how you load the game
Game Boy Color:
http://byuu.org/images/bsnes_20111025a.pnghttp://byuu.org/images/bsnes_20111025b.pnghttp://byuu.org/images/bsnes_20111025c.pnghttp://byuu.org/images/bsnes_20111025d.png
Everything except the IR port is emulated. I don't have any plans to allow linking two instances of bsnes. And that's frankly never going to happen over netplay anyway, due to latency requirements of the serial/IR ports.
The new DMA stuff is possibly incorrect, my test games don't seem to use it.
Zelda: DX usually resets or crashes on the intro right before the beach scene. I'm not sure why. Skip the intro and the game plays fine.
This is the best I can do when the most up-to-date GB/C reference document is over ten years old and half-assed (pandocs.)
I could really use some help from anyone who understands the system. Probably the worst part of my emulation at the moment is the interrupt system.
Lots of things real hardware doesn't allow (DMA outside HRAM, CGB DMA to invalid addresses, etc) isn't blocked yet.
LCD renderer is still scanline-based, which is just terrible. Doesn't seem to be any good docs on cycle-level operation. I only know that it's incredibly pathological and variable.
2011-10-24 - bsnes_v083r03.tar.bz2
Lots of phoenix issues fixed, especially for Windows and GTK+.
NES emulation passes all ten ppu_vbl_nmi tests from blargg.
Sprite timing is nowhere near accurate yet (always consumes four clocks per sprite), but oh well.
2011-10-17 - bsnes_v083r02.tar.bz2
It seems impossible to pass blargg's NES ppu_vbl_nmi test 03 and 07 at the same time. Wrote up a description of the problem here:
http://nesdev.parodius.com/bbs/viewtopi ... 5156#85156
2011-10-16 - bsnes_v083r01.tar.bz2
This adds Bisqwit's NES palette generation code:
http://nesdev.parodius.com/bbs/viewtopi ... 5060#85060
I set the saturation to 2.0 to closer match the existing "bright" palette, although it still has a greater contrast range (some colors are darker.)
The gamma ramp option works now. Like SNES, best to also set gamma to 0.8 afterward.
Once I think of a good way to expose the saturation/hue settings, I'll do so.
I've also merged in the updated nall. Adds Cygwin uname check, and replaces linear_vector with vector in lstring and the GUI.
2011-10-14 - bsnes_v083-source.tar.bz2
This release adds preliminary Nintendo / Famicom emulation. It's only a week or two old, so a lot of work still needs to be done before it can compete with the most popular NES emulators.
It's important to clarify: bsnes is primarily an SNES emulator. That will always be its forte and my core focus. I have added Game Boy support previously for Super Game Boy emulation, and I've added NES support mostly for something fun to work on to break up the monotony of working on one system for seven years now. Obviously, I'd like the emulation to be accurate and highly compatible, but I simply cannot afford to invest the same amount of time and money into any other systems.
Still, either way the NES and GB emulation serve as fun side-diversions, and allow for a unified emulator interface with all of bsnes' unique features applied to all systems. My personal favorite feature is mightymo's extended built-in cheat code database that now also includes NES and Game Boy codes. And it even works in Super Game Boy mode now, too!
I'm also not worried about speed at all: so long as NES/GB are faster than SNES/compatibility, it's fine by me. Note that due to the NES audio running at 1.78MHz, and Game Boy audio at 4MHz stereo, a more sophisticated audio resampler was needed: Ryphecha (Mednafen author) has graciously written a first-rate resampler: it is a band-limited Kaiser-windowed polyphase sinc resampler. It is combined with two highpass filters to remove DC bias. The filter itself is SSE optimized, but even still, approximately 50% of CPU usage for NES/GB emulation goes to the audio filtering alone. However, you now have the best sound possible for NES and Game Boy emulation as a result.
The GUI has also been heavily re-structured to accommodate multiple emulators from the same interface. As such, it's quite likely a few bugs are still lurking here and there. Please report them and I'll iron them out for the next release.
Changelog:
SNES core outputs full 19-bit color (4-bit luma included) for more accurate color reproduction (~5% speed hit)
audio resampler is now a band-limited polyphase resampler [Ryphecha]
cheat database includes NES+GB codes as well [mightymo, tukuyomi]
lots of other changes
2011-10-11 - bsnes_v082r34.tar.bz2 (source only)
Added MMC2, MMC4, VRC4, VRC7 (no audio.)
Split NES audio code up into individual modules.
Fixed libsnes to compile: Themaister, can you please test to make sure it works? I don't have a libsnes client on my work PC to test it.
Added about / license information to bottom of advanced settings screen for now (better than nothing, I guess.)
Blocked PPU reads/writes while rendering for now, easier than coming up with a bus address locking thing :/
I can't seem to fix MMC5 graphics during the intro to Uchuu Keibitai. Without that, trying to implement vertical-split screen mode doesn't make sense.
So as far as special audio chips go ...
VRC6 is completed
Sunsoft 5B has everything the only game to use it uses, but there are more unused channels I'd like to support anyway (they aren't documented, though.)
MMC5 audio unsupported for now
VRC7 audio unsupported, probably for a long time (hardest audio driver of all. More complex than core NES APU.)
audio PCM games (Moero Pro Yakyuu!) I probably won't ever support (they require external WAV packs.)
Three days to release, so whatever's missing / broken then will be staying that way for a while.
2011-10-07 - bsnes_v082r32.tar.bz2 (source only)
Added delay to MMC1 register writes, to fix Bill & Ted's Godawful Adventure.
Fixed up MMC5 RAM+fill mode, and added EXRAM mode support (8x8 tiles/attributes.)
Just Breed is fully playable now.
MMC5 is a total pain in the ass, the documentation on it is just terrible. I basically just tried seven hundred variations until something worked.
I still need to add MMC5 vertical split screen (for one single game's attract screen, ugh), and the extra sound channels.
Would like to rework the NES APU first. Since the pulse channels are identical sans sweep, it'd be nice to just inherit those and mask out the sweep register bit writes.
So that probably won't make it into the first release, at least.
Still, overall I think it'll be an impressive showing of complex mappers for a first release: MMC3, MMC5, VRC6 and 5B. The latter two with full audio. The only other really, really hard bit is the VRC7 audio, supposedly.
2011-10-05 - bsnes_v082r31.tar.bz2 (source only)
Enable Overscan->Mask Overscan [best I'm doing]
Video settings -> Overscan mask: (horizontal, vertical: 0-16 on each side) [only works on NES+SNES]
BPS patching works for NES+SNES+GB; note that long-term I want BPS to only patch headerless PRG+CHR files, but we'll need a database / completed board mapping system first.
MMC1 splits the board/chip markups a bit better. My attempts to emulate the extra CHR bits per hardware fail repeatedly. Docs do not explain how it works at all.
Emulated enough of the MMC5 to play Castlevania 3.
The MMC5 is easily the most complicated mapper the NES has to offer, and of course, has the most pitifully vague and difficult documentation of any mapper around.
It seems the only way anyone is able to emulate this chip is empirically.
Everyone else apparently hooks the MMC5 right into the PPU core, which I of course cannot do. So I had to come up with my own (probably wrong) way to synchronize the PPU simply by observing CHR bus accesses.
I must say, I over-estimated how well fleshed out the NES hardware documentation was. Shit hits the fan right after MMC3.
It's miles beyond the GB scene, but I find myself wanting for someone with the technical writing ability of anomie.
I can't find anything at all on how we're supposed to support the $2007 port reads/writes without it extra-clocking the PPU's bus, which could throw off mapper timing.
Absolutely nothing at all on the subject anywhere, something everybody is required to do for all cycle-based emulators and ... nada.
Anyway, I'd like to refine the MMC5 a bit, getting Just Breed playable even without sound would be really nice (it's a fun game.)
Then we need to get libsnes building again (ugh, getting worn out in backporting changes to it.)
Once v083 is public, we can start discussing a new API for multiple emulators.
2011-10-04 - bsnes_v082r30.tar.bz2 (source only)
cheats.xml -> cheats.bml, includes NES+SNES+GB codes now. Absolutely awesome, thanks to mightymo and tukuyomi.
I also added Sunsoft-FME7/5B (with sound) emulation. Really only useful for playing the Japanese release of Gimmick!
Fun game, but balls to the wall hard.
Been a while since a WIP-release thread made it into the 30s. Anyway, you guys can probably guess when I'm hoping to release. So ... test accordingly please =)
2011-10-03 - bsnes_v082r29.tar.bz2 (source only)
I doubt anyone is going to like these changes, but oh well.
The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing.
Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now.
Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values.
The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing.
If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases.
On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming.
If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/
Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-01 - bsnes_v082r28.tar.bz2 (source only)
Was mostly working on BML. Still working on the spec.
Added NES-BNROM, NES-GNROM/NES-MHROM boards. I don't even know why. The latter games do not work very well without Zapper support.
2011-09-30 - bsnes_v082r27.tar.bz2 (source only)
Finished porting over all mappers to board/chip disambiguations. Had to nearly rewrite the MMC1 code to do it, but all variants should be supported.
iNES1 is too stupid to express them all, so you'll need a board markup if you want to play the >8KB PRG RAM games.
For whatever reason, they call VRC6's memory WRAM, and MMC1's PRG RAM. I am calling them all PRG RAM, since it's the same damn thing.
Board spec is not going to be stable until I have a hell of a lot more mappers implemented, so be wary of that.
Anyway, at this time, all games can be loaded sans iNES header, if you have the board markup. I'd also like to have a board database for all commercial titles.
I'm treating *.fc as PRG-ROM(+CHR-ROM). Will work on loading the split files later possibly.
2011-09-28 - bsnes_v082r25.tar.bz2 (source only)
Ryphecha fixed Gun Nac, it was some sort of problem with blank sprite address fetching messing with the MMC3
I've started on an XML parser for iNES-free loading, but it's pretty barebones right now. Only NROM-256 loads, and you have to make it a compile-time thing (so other games work for now.)
Updated nall with nullptr stuff.
nall/detect is now nall/intrinsic and has both #defines + static constants that can be used to detect the platform (allows for run-time platform checks where practical.)
ruby has a Makefile now, that makes using it in other projects a lot easier
I need to rework my XML parser, it's not really all that suitable for this, and NES is going to need probably 50x the XML parsing code of the SNES.
I want to be able to quickly test if a required element exists or not, and grab its data. I also want to design it around start/end offset pairs, so that there's not so much malloc overhead.
2011-09-27 - bsnes_v082r24.tar.bz2 (source + Windows 64-bit binary)
Upgraded to GCC 4.6.1.
Removed nall/foreach and nall/concept, upgraded iterator support on all of my containers, and replaced everything with range-for.
Fixed up Qt geometry a good bit, should at least create windows now without bouncing around.
Added some initial nullptr / constexpr changes.
Some other minor cleanups ... removing foreach() took about 6-8 hours alone.
Turns out GCC has a 0bNNN extension for binary. I'm not big on being locked to specific compilers, but the syntax is so much more elegant than binary("100101010"); so we will see.
2011-09-26 - bsnes_v082r23.tar.bz2 (source only)
Ryphecha fixed the FF1 glitch, added two highpass filters to NES audio output (still working on a lowpass), and fixed VRC6 audio issues.
I reduced the complexity of all eight supported mapping modes, and standardized them; and added in an overscan filter (not in archive) for chopping off all the NES edge garbage (8 pixels on the left and right, 16 on the top and bottom.)
It's extreme, but anything less shows junk. I may make this part of the menu option, just clip
2011-09-25 - bsnes_v082r22.tar.bz2 (source only)
Mappers are now optionally threaded.
Fixed up MMC3 emulation, SMB3 and MM3-6 are all fully playable. However, many unusual variants of this chip are not supported still.
Added UNROM+UOROM for Contra and MM1, allowing all six MM games to play now.
Added VRC6 with sound emulation, because I wanted to get audio mixing in place.
Chose VRC6 because it has Esper Dream 2, which is an absolutely amazing game that everyone should play :D
The game didn't use sawtooth, and I didn't test any other VRC6 games, so hopefully that is emulated passably well enough.
Anyway, I think we have enough of the mappers down now to start thinking about a stable API for them.
iNES is basically right out, I have no intention of the core emulator supporting it. We can write an iNES->XML translator for compatibility from the UI, but the core is going to want cleaner information.
It's really just a question of how low-level we want to get: describe only what is NEEDED for known configurations, or allow for more flexibility?
A) VRC6 would have an attribute like "swap_address_lines=true/false" to swap A0/A1 wiring, as ED2 needs but AD does not.
B) we would specify how the pins were connected: "A0->A1, A1->A0, A12-15->A2-5"
bsnes_v082r21.tar.bz2 (source only)
2-6% speed hit in SNES core for outputting 19-bit (rounded to 32-bit ... sigh) video, so that luma non-linearity can eventually be emulated properly.
Now using sinc audio resampler, massive speed hit of course to NES+GB only, but it's required to get rid of aliasing (buzzing) present in many, many games otherwise.
Fixed fast forward and none/blur select.
Finally fixed texture clearing for changing pixel shaders and video filters.
Some realllly basic NES MMC3, extremely broken so don't bug me about it.
Other stuff, probably.
2011-09-23 - bsnes_v082r20.tar.bz2 (source only)
NES now has save state support.
NES A/B buttons were indeed swapped, so that's fixed now.
nall/dsp now puts resamplers into separate classes, so that each can have their own state information.
opengl.hpp uses GL_RGBA internal format and doesn't regenerate textures on resize. No speedup, no fix to junk on resize, so I will be very unhappy if this breaks things for anyone.
GLSL shaders use as you guys wanted.
ui-snes was removed.
2011-09-21 - bsnes_v082r19.tar.bz2 (source only)
This will be the last release with the ui-snes folder (it's broken now anyway.)
Re-added cheat code database searching + add window. It hashes NES+SNES+GB images now and will look them up in the database.
Re-added filter support, all filters now output at RGB555. Stacking is possible, but I don't currently allow it.
Removed mouse capture + test options from tools menu.
Removed smooth video output from settings menu.
There are now two built-in "shaders": "None" (point filtering) and "Blur" (linear filtering).
OpenGL shaders can now use (or "linear") to specify their filtering mode.
Individual emulator versions are gone, and names are hidden from the GUI: you just see bsnes v082.19 now. A new release bumps all core versions.
I cannot for the life of me get the video to clear properly when toggling the shaders. Say you set pixellate2x filter, then turn on curvature shader, then turn off the filter, you get junk at the bottom right.
I have tried clearing and flipping the OpenGL surface 64x in a row ... I don't know where the hell it's getting the data from. If anyone can make a small patch to fix that, I'd greatly appreciate it.
2011-09-20 - bsnes_v082r18.tar.bz2 (source only)
There we go, the GUI is nearly feature-complete once again.
All cores now output their native video format (NES={emphasis}{palette}, SNES=BGR555, GameBoy={ bright, normal, darker, darkest }), and are transformed to RGB555 data that is passed to the video renderer.
The video renderer then uses its internal palette to apply brightness/contrast/gamma/ramp adjustments and outputs in RGB888 color space.
This does add in another rendering pass, unfortunately, but it's a necessary one for universal support.
The plan is to adapt all filters to take RGB555 input, and output RGB555 data as well. By doing this, it will be possible to stack filters.
However, it's a bit complicated: I need to plan how the stacking should occur (eg we never want to apply scanlines before HQ2x, etc.)
Added input frequency adjustments for all three systems. I can easily get perfect video/audio sync on all three now, hooray.
Long-term, it seems like we only really need one, and we can do a video/audio delta to get an adjusted value. But for now, this gets the job done.
Added audio volume adjust. I left out the balance for now, since it's obviously impossible to balance the NES' single channel audio (I can duplicate the channel, and do twice the filtering work, but ... why?)
I replaced NTSC/PAL TV mode selection with an "Enable Overscan" checkbox. On, you get 240 lines on NES+SNES. Off, you get 224 lines on NES+SNES.
Also added aspect correction box back. I don't do that gross PAL distortion shit anymore, sorry PAL people. I just scale up the 54/47*(240/224) aspect correction for overscan off mode.
All memory is loaded and saved now, for all three systems (hooray, now you can actually play Zelda 1&2.)
Added all of the old bsnes hotkeys, with the exception of capture screenshot. May add again later. May come up with something a bit different for extra features.
Re-added the NSS DIP switch setting window. Since geometry is saved, I didn't want to auto-hide rows, so now you'll see all eight possible DIPs, and the ones not used are grayed out.
Ultimately, nobody will notice since we only have DIPs for ActRaiser NSS, and nobody's probably even using the XML file for that anyway. Whatever, it's nice to have anyway.
Took FitzRoy's advice and single-item combo boxes on the input selection are disabled, so the user doesn't waste time checking them.
I wanted to leave text so that you know there's not a problem. Qt disabled radio box items look almost exactly like enabled ones.
Fixed lots of issues in phoenix and extended it a bit. But I was still having trouble with radio box grouping, so I said fuck it and made the panels show/hide based instead of append/remove based.
That's all for stuff off the checklist, I did a bunch of other things I don't recall.
So yeah, I'd say the GUI is 100% usable now. This is my opinion on how multi-platform GUIs should be done =)
Oh, I figure I should mention, but the NES core is GPLv3, and all future SNES+GB releases will be as well. It's a move against Microsoft's Metro store.
2011-09-19 - bsnes_v082r17.tar.bz2 (source only)
Adds BS-X/Slotted/SufamiTurbo/SGB cartridge loading. Calling it Satellaview as I'm more partial to that at the moment.
FileBrowser now remembers your folders per filter type like before, and will keep your place in the list if you don't switch away.
I wanted there to be ONE slot loader, so the loader will show a grayed out secondary slot on non-ST loading, but it's more consistent to only have one window instead of two for geometry placement.
Removed help menu. Will try and work it in somewhere unobtrusive later on I suppose.
Added timed messages and the usual "no cart loaded / paused" messages and such.
Multi-cart loading stuff took ENTIRELY too long.
2011-09-18 - bsnes_v082r16.tar.bz2 (source only)
Binary output is once again called bsnes. No versioning on the title without a system cartridge loaded. Still saving config files to .config/batch for now.
Finally fixed NES APU frame IRQ clearing on $4015 reads.
Added mouse button/axis binding through buttons on the input capture window.
Added advanced settings window with driver selection and focus policy settings. Will show your default driver properly if none are selected now, unlike old bsnes.
That exposed a small bug where phoenix isn't removing widgets on Layout::remove, worked around it for now by hiding the panels. Damn, sick of working on phoenix.
Added all missing input controllers, which can all now be mapped, and bound them to the main menu, and added NES support for selecting "no connected controller."
Added mouse capture and the requisite tools menu option for it.
Added WindowManager class that keeps track of both position and size now (eg full geometry), so now you can resize your windows and save the settings, unlike old bsnes.
WindowManager has more stringent geometry checks. The client area (not the window border) can't be below 0,0 or above the width/height of three 30" monitors. If you have 4+ 30" monitors, then fuck you :P
settings.cfg is now also saved, captures all currently available settings. Right now, there's only one path for the file browser to remember. I will probably make this per-system later.
FileBrowser has been made a bit more friendly. The bottom left tells you what type of files the list is filtered by (so you see "*.sfc" for SNES), and the bottom right has an open button that can enter folders or load files.
Added video shader support.
Fixed nall/dsp variadic-channel support, was only outputting the left channel.
Things left to do:
Add multi-cart loading { BSX, BSX slotted, ST, SGB }
Add video filter support (very tricky, only SNES output 16-bit video for them.)
Add video color adjustment support (same problem as above.)
Add audio input frequency adjustments, volume adjustments, and balancing adjustments.
Add video aspect correction and NTSC/PAL TV selection.
Add preferred region selection (needed for NES (W) games, SGB BIOS.) [NES still needs to emulate PAL, period.]
Add SNES expansion port device selection { BSX, None }
Save and load emulated system memory (SRAM files, etc.)
Add smart status bar text for main window (show messages on events, advise when paused, etc.)
Add a whole lot more hotkeys (pause, state load/save, etc.)
Add a proper about window. Tempted to just drop the whole about window entirely. A whole Help menu for one vanity item is pretty stupid.
Add NSS DIP switch window (ugh.)
2011-09-17 - bsnes_v082r15.tar.bz2 (source only)
7.5 hours of power coding. Das Keyboard definitely helped (but didn't eliminate) RSI, neato.
Okay, the NES resampler was using 315 / 88.8 by mistake, so the output rate was wrong, causing way more video/audio stuttering than necessary.
STILL forgot the NES APU frame IRQ clear thing on $4015 reads, blah. Why do I always remember things right after uploading the WIPs?
Recreated the input manager with a new design, works much nicer than the old one, a whole lot less duplicated code.
Recreated the input settings window to work with the new multi-system emulation.
All input settings are saved to their own configuration file, input.cfg. Going to batch folder for now.
Okay, so the new input settings window ... basically there are now three drop-downs, and I'm not even trying to label them anymore.
They are primary, secondary, tertiary selectors for the listed group below. Examples:
"NES -> Controller Port 1 -> Gamepad"
"SNES -> Controller Port 2 -> Super Scope"
"User Interface -> Hotkeys -> Save States"
I am aware that "Clear" gets disabled when assigning. I will work on that later, being lazy for now and disabling the entire window. Have to add the mouse binders back, too.
Escape and modifiers are both mappable as individual keys now. If you want to clear, click the damn clear button :P
Oh, and all input goes to all windows for now. That'll be fixed too when input focus stuff is re-added.
2011-09-16 - bsnes_v082r14.tar.bz2 (source only)
Emulates DMC channel (sound effect when Link gets hit in Zelda 1, for instance), fixes up bugs in rectangle/sweep and triangle channels, adds DMC/frame APU IRQs, adds proper stalling for DMC ROM reads (should even be cycle accurate, but has one extra cycle when triggered during OAM DMA, I think), but forgets the frame IRQ acknowledge clear on $4015 read (will fix next WIP.) All sound courtesy of Ryphecha.
Made template configuration settings window (empty for now.) Simplified SNES cheat.cpp code. Some other stuff.
Further developed RSI.
2011-09-15 - bsnes_v082r13.tar.bz2 (source only)
I've updated the {System}::Interface classes to encapsulate all common functionality, so they are C++ equivalents of libsnes now.
The idea being, use the interface class and you'll never have to reach into core objects (unless you really want to.)
Not guaranteeing as stable an API as I do with libsnes for that, though. C++ doesn't make for nice dynamic libraries, anyway.
Added back the state manager, and it now works for both SNES and Game Boy. NES save states aren't in yet.
Anyway, this should give you a pretty good feel for what the combined UI is going to be like: same as before, everything works the same. Only difference is the dynamic system menu and cartridge menu with more load options. The settings window will be mostly the same as well, but will obviously have options that only apply to some systems.
2011-09-14 - bsnes_v082r12.tar.bz2 (source only)
Merged Ryphecha's APU emulation, so NES has sound output now. We are still missing the DMC memory fetch, so there will be missing sound effects here and there.
2011-09-14 - bsnes_v082r11.tar.bz2 (source only)
Emulates grayscale and color emphasis modes, improves sprite timing and PPU bus fetching behavior with the PPU disabled.
2011-09-14 - bsnes_v082r10.tar.bz2 (source only)
Emulated the Game Genie for the NES and Game Boy, and wrote a new cheat editor that doesn't reach into specific emulation cores so that it would work.
Before you ask: yes, long-term I'd like Super Game Boy mode to accept Game Boy codes. But that's not high on the priority list.
Renamed the mappers toward board names, LZ...->BandaiFCG, LS161...->AOROM, added CNROM emulation (Adventure Island, Gradius, etc.)
Added the tools menu load/save state stuff, but note that the NES doesn't have save state support yet (waiting for the interface to stabilize a bit more first.)
Note: this will be the last release to have the ui-gameboy folder, it's been deleted locally from my end, as the new multi-GUI does all that it does and more now.
2011-09-12 - bsnes_v082r09.tar.bz2
Skip this build if you can, it's CPU+PPU timing improvements that should not visibly affect anything.
Cheat codes and save states are going to work 100% the same between every system. I'll leave the database for NES/GB up to mightymo, if he is interested. They can even be in the same cheats.xml file, it doesn't really matter. That's why XML is so nice, it can store any form of cheat code for any system, no problem.
2011-09-10 - bsnes_v082r07.tar.bz2 (source only)
Wrote a cycle-based PPU renderer, ~95% hardware accurate for BGs, not so much for sprites yet. Mednafen has been helping out a lot.
2011-09-10 - bsnes_v082r06.tar.bz2 (source only)
Emulated MMC1, currently defaults to B2 configuration. Fixed a whole bunch of timing things, render things, nametable mirroring things, etc.
Zelda and Mega Man II are fully playable, but they have odd vertical scrolling issues that make it a not so fun experience.
Not sure what the problem is there, yet. The Y scroll register writes seem to be wonky ... I don't know.
Keeping the Cartridge menu always visible now, so it's faster to load carts, but I am still hiding the non-loaded system menus.
2011-09-09 - bsnes_v082r05.tar.bz2 (source + Windows binary)
Okay, I fixed up many outstanding phoenix issues.
Windows/GTK+ fixed by using processEvents instead of main(); Windows can run unthrottled, and GTK+ shows the window contents now
fixed keyboard beeping once and for all on Windows: I now whitelist tabbable controls
fixed main menubar setVisible calls
Qt and GTK+ now allow you to resize windows smaller than they initially were
Both Qt and GTK+ still fuck up the geometry a bit when toggling fullscreen mode. I have tried, and tried, and tried and tried and tried to fix it all. Nothing works. I give up.
Easier to destroy and recreate the fucking window than figure out how to resize it on Linux (and no, I can't do that. ruby would not like the handle changing.)
As for the GUI:
file browser is back in, still need remember place and open folder code; that needs to be extended to handle multiple systems now
shrink window command added to tools menu
2011-09-03 - bsnes_v082r02.tar.bz2 (source only)
Has Jonas Quinn's many Game Boy APU fixes, and two more from blargg's notes that I added.
It also has the new dynamic phoenix. So yeah, it'll crash on bsnes/Qt exit. If anyone can fix it properly and wants the money, I'll pay them $20 for the trouble =)
As for auto-saving SRAM, last time I tried it was destroying the frame rate on solid state drives that would choke the whole program using synchronous writes.
Even if I make it an option, which will be a bit of a hassle, most people won't know to turn it on until it's too late.
if config file window coordinates are >= 30000, it snaps them back to 128,128; should end the "why aren't windows visible?" posts
updated GUI code to match new phoenix changes
phoenix: Layout and Widget inherit from Sizable; directional layouts make no distinction between widgets and layouts
phoenix: individual widgets / layout can maintain visible/hidden status in spite of their parents' visibility
2011-08-20 - bsnes_v082
This release features many substantial Game Boy emulation improvements (all courtesy of Jonas Quinn), a new audio DSP class, and BPS patching support.
Changelog:
added new DSP audio engine; supports sample-averaging for the Game Boy's high frequency rate
GB: MMM01 images with boot loader at bottom of ROM can now be loaded
GB: EI is delayed one cycle; fixes Bubble Bobble [Jonas Quinn]
GB: fixed window -7 offset behavior; fixes Contra 3 first boss [Jonas Quinn]
GB: disable LCD interrupts when rendering is off; fixes Super Mario Land 2 [Jonas Quinn]
GameBoy: fixed window behavior for Contra 3 first boss [Jonas Quinn]
GameBoy: fixed noise channel for Zelda: LA intro [Jonas Quinn]
GameBoy: completely disable LCD when turned off, no interrupts; fixes Super Mario Land 2 [thanks to Jonas Quinn]
GameBoy: keep track of where pixels come from for OBJ priority mode [Jonas Quinn]
updated mode+slot-dependent name handling: simplifies Path class, allows SGB/BSX/ST games to show the slot title (instead of BIOS name) on the title bar
Makefile allows command-line definitions for ui and profile now (make profile=compatibility ui=ui-libsnes)
Makefile now allows (make pgo=instrument) and (make pgo=optimize)
added BPS patching support, removed UPS patching support
Beta-testers, if you could please test the path stuff extensively, that'd be great. I do not use custom paths, so there's a chance I may have broken something there. I'd like to release a new build once snespurify and the standalone BPS patcher are finished.
Would also be wise to play some more Game Boy games, as compatibility should have increased a good deal.
2011-08-14 - bsnes_v081r02.tar.bz2 (source only)
This release adds nall/dsp, which is a new framework for audio DSP effects. It currently supports the usual fractional hermite resampling and volume adjustments from ruby; but it also adds balance, and arbitrary precision input and output (still limited to two channels, and still signed audio [just subtract 1<<(bits-1) from an unsigned value.]) Internally, all samples are converted to doubles in the range of -1.0 to +1.0, to allow for far greater precision with the hermite resampler and volume/balance/etc adjustments.
As a result of this, all of the extra resampling/volume code from ruby::audio has been removed. bsnes pulls in a copy of nall::dsp to handle that stuff now.
The overall framework is meant to be far more flexible in the future. I'd love to add more resampling algorithms (especially an averaging one for Game Boy emulation), and more special effects (echo, reverb, bass, treble, equalization, etc.) Thing is, I just don't know a damn thing about audio, so I'm not sure how to implement them. Would love some help here. I don't want to just plug in other peoples' libraries, I want to learn how to do these things and implement them into nall, so that I can learn about audio processing, and have my own neat little audio library.
Finally fixed SNES::Interface::audio_sample to take int16_t parameters, since SNES audio is signed. libsnes stays the same for backward-compatibility.
EI takes an extra cycle to raise IME; fixes Bubble Bobble, and likely many more games [Jonas Quinn]
nall/gameboy/cartridge.hpp descrambles MMM01 images (header can be at top or bottom of image now)
screenshot timestamps use filename-yyyy-mm-dd hh.mm.ss.bmp format; so that they can save on Windows
closing the emulator will switch to windowed mode first, so that geometry is preserved
2011-08-12 - bsnes_v081-source.tar.bz2
Changelog:
rewrote S-DD1 module to decompress individual bytes at a time
simplified SPC7110 deinterleaving code
OBC1 should not clear RAM on reset [Jonas Quinn]
fixed enum-cast compilation errors with the latest GCC 4.6.x releases
added bsnes logo to about screen
make phoenix=gtk will now build the GTK+ port on Linux
added settings.startFullScreen to the config file for front-end users
added advanced settings option to disable window compositor (only works on Windows and Xfce)
merged settings windows into the panel approach used by bsnes/Qt in the past
fixed a crashing bug on input settings window
fixed GTK+ auto-geometry sizing
added screenshot capture capability
added exit emulator hotkey (defaults to being unmapped)
Xorg keyboard polling now uses cached Display variable [Bisqwit]
cheat code database updated [mightymo]
2011-08-08 - bsnes_v080r08.tar.bz2 (Windows binary + source)
Fixed all of the above phoenix issues, and improved the auto-disabling of buttons on the input setting and state manager windows.
Also manually initiailized lastConfigure for Valgrind in GTK+. Windows and GTK+ ports look a lot nicer now.
2011-08-08 - bsnes_v080r07.tar.bz2 (Windows binary + source)
Please test this one as much as you guys can, I'd like to release a new build soon.
Changelog:
fixed a long-standing crash: when you have a device index above the range permitted by another port, the app would crash (eg Controller Port 2 -> Mouse, then switch to Hotkeys)
Qt bug workaround: have to use currentItemChanged signal instead of itemSelectionChanged signal for QTreeWidget, otherwise scrolling with mouse gives you the previous item with currentItem() ...
added support for toggling the Xfce compositor
added support for detecting if the compositor is enabled in the first place on Windows, so that it won't get turned on when you had it off permanently
added advanced setting to toggle behavior (never disable, disable only in fullscreen mode, disable whenever emulator is open)
worked around GTK+ ../... button height issue
worked around Windows slider position issue when attaching to a new window (need to research this one more)
fixed up input settings window more: closing window ends assignment, custom mapping buttons hidden by default
Some of those bugs have been there since the phoenix port began, good times.
2011-08-07 - bsnes_v080r06.tar.bz2 (source only)
Ran out of time, so this is incomplete, but ...
Windows will disable the compositor in fullscreen mode, and enable it when switching back to windowed mode.
Should help with Vsync issues, but of course only in fullscreen mode.
I've also merged the four settings windows back into a panel with a list view (since I have no tab control widget.)
The input settings window is a bit incomplete, need to break assignment on window close, hide the capture buttons on first showing, etc.
Will probably try and finish that up tonight.
2011-08-06 - bsnes_v080r05.tar.bz2 (source only)
Includes updated versions of nall and phoenix, which mostly improves the GTK+ version.
However, it appears to be crashing at the moment after loading a game. Unfortunately it works when gdb is used, so I can't easily debug it :/
You can now build with make phoenix=gtk if you want the GTK+ version on Linux (the Qt version is leagues better even on Gnome, please use it if at all possible.)
There's also settings.startFullScreen, config-file only, to allow for front-end use. Forgot to add the reset/power hotkeys.
I also fixed compilation of ui-gameboy on GCC 4.6. I hope that's the last switch(enum) error, those are damn annoying. Can't wait to switch to GCC 4.6 on Windows.
2011-07-24 - bsnes_v080r04.tar.bz2 (source only)
Adds nall/inflate.hpp and nall/unzip.hpp. Updates nall/resource.hpp to encode and decode using ZIP/deflate files, rather than a much simpler (and less powerful) LZSS implementation. Cuts the bsnes-logo.hpp file from 270KB to 130KB, and the binary overhead from 80KB to 35KB (better than PNG! Hah.)
2011-07-22 - bsnes_v080r03.tar.bz2 (Windows 32-bit accuracy binary included)
Wow, nothing in 19 days. Anyway, I wanted to get Nick's logo back in on the about screen.
Adds 80kb to both the binary and source archive, but eh. Gotta have some style. Nothing else new.
Probably won't be much news until the ST-0018 ROM is extracted.
./sshots/bsnes_20110722.png
Oh, and phoenix/Canvas sucks with GTK+, that'll be fixed eventually. Hopefully prior to v081.
2011-07-03 - bsnes_v080r02.tar.bz2
Changelog:
added qstrlower and qstrupper; mainly for the sake of others wanting to patch bass
cleaned up the NEC DSP and Hitachi DSP XML mapping code; they are consistent now as well
"necdsp" in paths.cfg is now "firmware", since it also affects the Hitachi DSP
XML mapping was using program= for DSP-n/ST-001n and data= for Cx4; they both use firmware= now instead
fixed icd2/interface casting issue for GCC 4.6.0 (thanks for the reminder, vEX)
removed the last parts of code that used string << foo; and removed that from nall/string entirely
*** I need to do this for the debugger as well, I'll make sure that it compiles before v081 though
converted all string(...) syntax to { ... } syntax that I could (obviously it won't cast to a function that takes const char* instead of const string&)
Probably some other tiny things. Just basic maintenance here.
2011-06-27 - bsnes_v080r01.tar.bz2 (source only)
There was one unfortunate aspect of the S-DD1 module: you had to give it the DMA length and a target buffer, and it would do the entire decompression at once.
Real hardware would work by streaming the data byte by byte. So with that, I went ahead and rewrote the code to handle byte-based streaming.
This WIP is an important milestone for me personally. Up until now, bsnes has always had code that was directly copy-pasted from other authors.
With all of the DSP and Cx4 chips rewritten in LLE, and the SPC7110 algorithm already ported over from C, and archive decompression code removed for a long time, the S-DD1 was the only module left like this.
It's obviously not that big of a deal. The code is basically still a copy of the original. S-DD1 decomp from Andreas Naive, SPC7110 decomp from neviksti, and S-DSP from blargg.
And the rest of the emulator is of course only possible because of code and research before it, although everything else has no resemblance at all to code before it.
The main advantage, really, is absolute code consistency. I always use the same variant of K&R, for instance.
I dunno, I guess I just never really liked the "Build-a-Bear Workshop" style of emulators, like is so prominent in the Genesis scene: "My new Genesis emu (uses Starscream/Musashi 68K core, Marat Fayzullin's Z80 core, YM2612 core from Game_Music_Emu, VDP core from Gens, SVP core from picodrive)", sorry, but you wrote a front-end, not an emulator :/
I also updated the SPC7110 decompression module: I merged the class inside the SPC7110 class (not sure why it was separate before), and replaced the morton lookup tables with for-loops.
The morton tables were added to be a tiny bit faster when I was more interested in speed than code clarity.
It may be a tiny bit slower (or faster due to less L2 cache usage), but you won't even notice an FPS drop, and it cuts out a good chunk of code and some tables.
Lastly, I added pinput_poll() to video_refresh().
Forgot to remove Interface::input_poll() from the C++ side, will have to do that later.
2011-06-26 - bsnes_v080-source.tar.bz2
This release adds low-level emulation of the Hitachi HG51B169 DSP, which was used in Mega Man X2 and Mega Man X3 as the Cx4 chip. It also fixes a regression in both the sound core and cheat engine.
You will now need the HG51B169 data ROM to play MMX2/MMX3. You can get that here. I will not be including it with bsnes.
Once again, Cx4 LLE could not have been possible without the help of Dr. Decapitator, Jonas Quinn, Overload and Segher. Be sure to thank them, please!
Changelog:
fixed S-SMP synchronization to S-CPU on CPUIO writes
controllers now have their own threads and classes
serial controller is now emulated as an actual controller, rather than as a coprocessor
added link coprocessor module for special chip research and homebrew
fixed cheat codes that target mask ROM addresses [Cydrak]
fixed compilation error with the latest GCC 4.6.0 beta releases
added flexibility to XML memory mapping file format
updated to mightymo's latest cheat pack (2011-06-20)
2011-06-24 - bsnes_v079r06.tar.bz2 (source only)
Added threading support: each controller port gets its own thread now. If they don't need one, then it auto-generates one running at 1hz.
It does add some more code to the CPU::step() function, so performance probably went down actually, by about 1%. Removing the input.tick() call didn't compensate as much as I'd hoped.
Hooked up Super Scope and Justifier support. The good news is that the Justifier alignment doesn't get fucked up anymore when you go off-screen. Never could fix that in the old version.
The bad news is that it takes a major speed hit for the time being. I need to figure out how to run the CPU and input threads out of order. Every time I try, the input gets thrown off by most of a scanline.
Right now, I'm forced to sync constantly to get the latching position really accurate. But worst case, I can cut the syncs down by skipping large chunks around the cursor position, +/-40 clock cycles. So it's only temporarily slow.
Lastly, killed the old Input class, merged Controllers class into it. I actually like Controllers as a name better, but it doesn't jive with video/audio/input, so oh well.
2011-06-24 - bsnes_v079r05.tar.bz2 (source only)
Fixed GCC-4.6 casting errors in ui/input/input.cpp.
Fixed some of the opcode mnemonics specified in the HG51B169 core (was unable to speed up the code)
Started on a new core input system: snes/controller. More on that here: http://board.byuu.org/viewtopic.php?f=16&t=1761
Have not yet attempted to add threading support to the controllers, so serial is still there as a coprocessor.
I'm going to move the Controllers {} class back to Input {} once all individual controllers have been ported over.
Note: Super Scope and Justifier do not have counter latching support yet, so you can't really use them. The gamepad, multitap and mouse all work great; and the SS/Justifier cursors work at least.
I also colored the SS cursor red, so that all three (SS, Justifier, chained secondary Justifier) all have unique R/G/B colors now. Should prevent confusion between the SS and one Justifier.
2011-06-20 - bsnes_v079r04.tar.bz2
Back from vacation. We were successful in emulating the Cx4 using LLE during my vacation. We finished on June 15th. And now that I'm back, I've rewritten the code and merged it into bsnes official. With that, the very last HLE emulation code in bsnes has now been purged.
I still have some more plans for bsnes v080, so I'm not going to bump the version number just yet. Plus I would like it if we could thoroughly test the new Cx4 LLE support to ensure it is bug-free. To that aim, if you have some time and would like to help test: please download bsnes v079.04 and cx4.bin. Place cx4.bin in the same folder as "Mega Man X 2 (U).sfc" and "Mega Man X 3 (U).sfc", and then do your best to play through the entire games with no cheat codes, and uncover all of the secrets that you can.
If you find any bugs, or if the console window prints "invalid opcode" at any time, please send me a note on my forums. Thanks in advance to anyone who can help test this.
http://bsnes.googlecode.com/files/bsnes_v079r04.tar.bz2http://byuu.org/snes/cx4/cx4.bin
The emulation is as minimal as possible. If I don't see an opcode or feature actually used, I don't implement it. The one exception being that I do support the vector override functionality. And there are also dummy handlers for ld ?,$2e + loop, so that the chip won't stall out. But things like "byte 4" on rdram/wrram, the two-bit destination selections for all but ld, etc are treated as invalid opcodes, since we aren't 100% sure if they are there and work as we hypothesize. I also only map in known registers into the 256-entry register list. This leaves 90% of the map empty.
The chip runs at 20MHz, and it will disable the ROM while running. DMA does transfer one byte at a time against the clock and also locks out the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only reads from ROM, and only writes to RAM. Unless someone verifies that they can do more, I'll leave it that way. I don't yet actually buffer the program ROM into the internal program RAM just yet, but that is on the to-do list. We aren't entirely sure how that works either, but my plan is to just lock the Cx4 CPU and load in 512-bytes.
There's still a few unknown registers in $7f40-5f that I don't do anything with yet. The secondary chip disable is going to be the weirdest one, since MMX3 only has one chip. I'd really rather not have to specify the ROM mapping as two separate chips on MMX2 and as one on MMX3 just to support this, so I don't know yet.
Save state support is of course there already.
Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
2011-06-09 - bsnes_v079r03.tar.bz2 (source only)
This fixes the S-SMP synchronization on CPUIO writes that was broken by improvements in v078.01. Terranigma will work now.
Also adds the 'link' coprocessor module that was added in v079.01, and improved in v079.02.
2011-06-08 - bsnes_v079r02.tar.bz2
Added "unsigned link_run();" which acts as its own thread synchronized against the S-CPU. Specify the frequency in the configuration file.
I intend to prototype the Cx4 LLE openly using the link module, and that required timing support, so there we go.
It's very basic, and it synchronizes the CPU to the coprocessors and vice versa after every call to link_run().
Meaning performance won't be super exceptional at full 21MHz or higher, but then this is for prototyping only.
I didn't want to expose cothreading, yielding, calls back into bsnes' core, calls to sync up the S-CPU, etc.
2011-06-06 - bsnes_v079r01.tar.bz2
This bundle includes source code, and a Windows 32-bit accuracy build with the console enabled.
If you want profiling or a Linux binary, you'll have to build it yourself, sorry.
Background information here.
Here is an example of using the new SNES coprocessor research module.
The example will use Hayazashi Nidan Morita Shougi 2 (J).sfc for ST-0018 research.
XML mapping example:
Code:
<?xml version="1.0" encoding="UTF-8"?>
Specifically, note the section.
When you use the link edition binary above, it will print out the XML mapping for any game loaded to the console.
You can copy this, and then add your own link section. Save it as .xml and bsnes will use it in the future.
Verify this by looking at the console output on the next load.
You can map any address you like, but internal MMIO will be overridden internally (eg don't hijack the DMA registers.)
In other words, $00-3f|80-bf:0000-1fff,2100-2183,4016-4017,4200-421f,4300-437f and $7e-7f:0000-ffff are off-limits. Anything else is fair game.
Source code example:
Code:
if(addr == 0x3804) {
st0018.w3804 = ((st0018.w3804 << 8) | data) & 0xffffff;
}
}
Windows compilation example:
Code:
g++ -O3 -fomit-frame-pointer -I. -c st0018.cpp -o obj/st0018.o
g++ -o st0018.dll -shared -Wl,--out-implib,libst0018.a obj/st0018.o
Linux compilation example:
Code:
g++- -fPIC -O3 -fomit-frame-pointer -I. -c st0018.cpp -o obj/st0018.o
g++ -s -o libst0018.so -shared -Wl,-soname,libst0018.so.1 obj/st0018.o
Note that C++ is not required.
2011-06-04 - bsnes_v079-source.tar.bz2
This release includes Nintendo Super System DIP switch emulation and improved PPU rendering accuracy, among other things.
Changelog:
added Nintendo Super System DIP switch emulation [requires XML setting maps]
emulated Super Game Boy $6001 VRAM offset selection port [ikari_01]
fixed randomness initialization of S-SMP port registers [fixes DBZ:Hyper Dimension and Ninja Warriors]
mosaic V-countdown caches BGOFS registers (fixes Super Turrican 2 effect) [reported by zal16]
non-mosaic BGOFS registers are always cached at H=60 (fixes NHL '94 and Super Mario World flickering)
fixed 2xSaI family of renderers on 64-bit systems
cleaned up SMP source code
phoenix: fixed a bug when closing bsnes while minimized
Please note that the mosaic BGOFS fix is only for the accuracy profile. Unfortunately the older scanline-based compatibility renderer's code is nearly unmaintainable at this point, so I haven't yet been able to backport the fixes.
Also, I have written a new cycle-accurate SMP core that does not use libco. The aim is to implement it into Snes9X v1.54. But it would of course be prudent to test the new core first. So if you'd like to test, you can download it here:
bsnes_v079-smp.7z
Note that the alternate SMP core uses the performance profile, so there may be slight issues caused by CPU timing.
2011-06-01 - bsnes_v078r07.tar.bz2 (Windows 32-bit accuracy binary included)
./sshots/turrican2.png
Would appreciate testing on any games with mosaic, especially Mode7 mosaic.
I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program.
This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging.
I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run().
I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now.
Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-05-08 - bsnes_v078r06.tar.bz2 (source only)
This adds ikari_01's emulation of the ICD2 (Super Game Boy) $6001 register.
It basically removes a really ugly hack where I was intercepting the DMA transfer destination address to determine while Game Boy tile row to transfer.
This should make implementing SGB emulation in other emulators easier, as said hooks were very emulator-specific.
2011-05-06 - bsnes_v078r05.tar.bz2 (32-bit compatibility binary included.)
This WIP adds Nintendo Super System emulation, at least of its DIP switches.
./sshots/bsnes_20110506.png
This is done via XML mapping, like so:
Code:
<?xml version="1.0" encoding="UTF-8"?>
ActRaiser
The value field is a 16-bit value. All selected options are ORed together to produce the final DIP switch values.
The number of options per setting is unlimited, but there are only sixteen settings allowed (you can't have more settings than you have switches, that's just stupid.)
In the example above, d0-d1 controls difficulty, and d2-d3 controls # of lives. d4-d15 appear to be unused, as far as I can tell.
Anyway! I could use some help with this. There's basically something like 10-15 or so NSS games, so we should be able to produce XML files for every NSS game, and distribute them all as a nice pack. I can host the XML pack on my downloads page.
Basically, what I'd like is for someone to go through each game and try and figure out the valid DIPs for each game. Note! that some games don't use DIP switch values at all, we can ignore those games. Also note that I have no idea why ZSNES only allows six DIPs, the DIP register is 16-bits wide and is located at $4100,$4101. It may be that d6-d15 is never used though. Not a lot of info on this out there.
You will of course need non-MAME-fucked ROMs to use on bsnes ;) GoodSNES seems to use Gamename (NSS) for these. Stay away from MAME ROM sites.
As far as making the XML rom/ram maps, yeah, that'll be a bit annoying for some. Bleh.
snes/cartridge/cartridge.cpp has a commented out line that'll print the XML map for the game if there isn't one.
You can copy that, add the nss section, and have at it.
Basically, the way to figure it out is to set one bit at a time, play the game, see what changes, name the settings and options, and continue for each game.
Please post any XML maps you are able to make, or advise of games you know not to have any DIP settings.
Thanks in advance to anyone that can help.
minor optimization to bsnes/Performance SMP core in cycle-mode
fixed 2xSaI family, hopefully for good this time (not in bundle.)
2011-05-04 - bsnes_v078r03.tar.bz2 (32-bit performance binary included.)
I would appreciate if you guys could test games and tell me if you notice any reductions in sound quality compared to a previous performance WIP.
I apparently wasted two days writing that SMP core for nothing.
I had a perfectly well-written and well-tested core in bsnes v045.
The old opcode.b files that were a cycle-based markup language.
So I took that core, and wrote new parsers to generate both opcode-based (one switch) and cycle-based (two switch) cores. Throw in a little #define magic around CYCLE_ACCURATE, and it is compile-time toggleable.
EWJ2's bug was due to not resetting the timer variables, and Bahamut Lagoon's was due to dividing timer frequencies by 3, but failing to remove the 0->1 transition phase (should have done the latter and divided by two.)
Anyway, all fixed up.
The good news is the opcode-based SMP core is faster than bsnes'.
The bad news is that the cycle switch table approach is slower than libco, which is not surprising. libco let the SMP run ahead of the CPU without having to enter and exit switch blocks repeatedly.
But anyway, that gives three options for Snes9X. Cycle+libco, cycle w/o libco, and opcode. Or all three.
2011-05-03 - bsnes_v078r02.tar.bz2 (source only)
New S-SMP core is feature-complete, but still buggy.
It's good enough for perfect audio in Zelda 3 and Super Mario World, but there are plenty of issues.
No audio in Bahamut Lagoon, deadlock in Earthworm Jim 2, etc.
With this core, bsnes/Performance runs about 3-5% faster than with the old one. That won't seem like much, because the S-SMP is the least demanding portion of the SNES.
blargg's SMP core netted me a 5-8% speedup the last time I tried it, so I'm sure there's still room to speed things up.
The core is opcode-based, but has dummy op_io() calls (they compile to nothing), so it is trivial to make it cycle-based if desired.
I'm not convinced that is necessary, but we shall see once we get the opcode bugs ironed out.
If anyone wants to help, that'd be great. Just compare the snes/smp/core opcode semantics to the snes/alt/smp/core semantics and look for typos.
I have already ran synthetic tests to validate all cycle counts for every opcode (sans conditional branches not taken), and to ensure that all 256 opcodes are defined.
Probably best/fastest to rig up both SMP cores and perform some sort of random execution looking for any differences.
2011-05-02 - bsnes_v078r01.tar.bz2 (source only)
No point in downloading this one, no differences to two profiles, and it actually breaks the third.
Started on a new SMP core for bsnes/Performance. I wanted to start clean, and only copied over the debugger+disassembler portions from the existing version.
I figured that if I took the existing one and tried trimming it down, that it'd end up with too much old baggage.
But so far, the opcodes are looking mostly the same anyway, only I'm using #defines and a switch table in place of the template function trickery.
I have enough written now that I can run Zelda 3 at least (although it gets stuck in a loop immediately after.)
No real point in comparing speed yet, because it'll definitely go down as it becomes more complete.
Not feeling it so far, but we'll see how things go. There's a few areas that a new SMP can speed things up:
cycle table steps the clock and synchronizes once per opcode
may be able to step the timers the same way, but for now I'm still doing that per cycle
*** doing the above will make op_io() a no-op
can most likely get away with turning the dummy reads into no-ops, doubt anything relies on them
there are a few small areas where word-reads can help, but only on little-endian architectures
no need for TEST register support, will reduce a bit of overhead
no bus synchronization for read cycles (eg no need to split read cycles into two parts)
Most of that can be set up for toggling via #defines, including most importantly the cycle-stepping.
2011-04-30 - bsnes_v078-source.tar.bz2
Finally, a new release. I have been very busy finishing up SNES box, cartridge and PCB scanning plus cataloguing the data, however this release still has some significant improvements.
Most notably would be randomization on startup. This will help match the behavior of real hardware and uninitialized memory + registers. It should help catch homebrew software that forgets to initialize things properly. Of course, I was not able to test the complete library, so it is possible that if I've randomized anything that should be constant, that this could cause a regression. You can disable this randomization for netplay or to work around any incompatibilities by editing bsnes.cfg and setting snes.random to false.
The GUI also received some updates. Widget sizes are now computed based on font sizes, giving it a perfectly native look (because it is native.) I've also added a hotkey remapping screen to the input settings. Not only can you remap inputs to controllers now, but those who did not know the hotkey bindings can now quickly see which ones exist and what they are mapped to.
Please enjoy.
Changelog:
memory and most registers are now randomly initialized on power-up
fixed auto joypad polling issue in Super Star Wars
fixed .nec and .rtc file extensions (they were missing the dot) [krom]
PPU/accuracy now clears overscan region on any frame when it is disabled
PPU/compatibility no longer auto-blends hires pixels (use NTSC filter for this)
added hotkey remapping dialog to input settings window
added a few new hotkeys, including quick-reset
phoenix API now auto-sizes widgets based on font sizes
file dialog once again remembers previously selected file when possible
updated mightymo's cheat code database to April 19th release
2011-04-27 - bsnes_v077r05.tar.bz2 (Windows 32-bit accuracy build included.)
Please test this one as much as you guys can. Especially with toggling NTSC/PAL TV mode, and using various filters, and running all games that are known to be difficult to emulate.
The randomization could very well cause issues in some games if I randomize anything that should be constant. I took an overly aggressive approach.
We can verify it's a random issue by setting bsnes.cfg's snes.random to false and see if that fixes the issue.
I want to leave snes.random enabled in v078, and I'd like to avoid any major breakage if possible.
Changelog:
fixed .nec and both .rtc file extensions (thanks krom)
randomized most S-PPU registers, should trip up some broken homebrew that does not initialize all registers
randomization is now seeded with time(0) rather than 'byuu'
SNES::interface.video_refresh() now always receives {256,512}x{240,480}
PPU/accuracy scanline 0 does not render the screen back color anymore, fixes strange coloring look on first scanline in PAL TV mode in non-overscan games
disabled hires blending in PPU/compatibility; all three cores act the same now
For seeding with time(0), this is basically to prevent any game from relying on any specific value. It will catch more uninitialized register access than a static seed. It has an added benefit of stopping people from 'fingerprinting' the RAM data to detect bsnes, although that's probably still possible because bsnes will have a lower SNR for WRAM. We need to study many SNES WRAM dumps and come up with a nicer random generator for it. At any rate, it will be substantially harder to detect now.
For the video refresh, this is basically to simplify filters. It's a pain in the ass dealing with all kinds of different sizes and odd resolutions, and it just serves to complicate everything. Right now I'm not actually clearing lines 225-240 when overscan is off, but that should not be too difficult, and it makes a future TV-lite simulation filter much easier to write.
There is one issue though, you can't detect overscan state anymore. Hires is true if width == 512, and interlace is true is height == 480, but overscan isn't exposed.
Hires is line-based, and always true on the accuracy renderer anyway.
Interlace and overscan are 'per-frame' things, you can toggle them but they don't take effect until the next frame anyway.
So I think I need to extend video_refresh to expose overscan, interlace, and field values. But I am hesitant to break BC on libsnes.
Maybe it's best to have snes_get_video_state() that returns a mask of those settings or something.
What I really need to do is write up documentation on the internal video architecture of bsnes.
setGeometry is called after append(layout) now. This fixes the window sizing on Qt.
removed enum Style {} code, as it's no longer necessary.
removed Filter, Shader path selection code from the file load dialog, since that is menu-driven now.
improved the file load dialog to remember last selected file when mode doesn't change (had to split a switch statement into two switches.)
added Hotkeys port onto input settings window, allowing one to dynamically see and remap GUI shortcuts
added power cycle / reset shortcuts
Still very minimal with the hotkeys, so I packed them all into one group for now. A few more I'd like to add, but I don't want to get ridiculous like with the Qt GUI.
Is there any official documentation on the heights of controls on Windows? I don't mind making them all the same height if that's how they are supposed to be.
2011-03-23 - bsnes_v077r03.tar.bz2 (Windows binary included.)
Fixed up the geometry calculation code. There is now minimumGeometry() [returns minimum size needed to display a layout, treats MaximumSize as MinimumSize], and minimumLayoutGeometry() [like minimumGeometry(), but it will return MaximumSize if a single container item has that attribute. Used mostly internally for layout sizing.]
It looks great on Windows, but it looks visually off on Qt. Not exactly sure what's up there. When I make a test application, everything looks great. Going to have to clone a bsnes window that's having a problem (eg bsnes main debugger checkbox window), and see what's up.
Anyway, yeah. It looks great on Windows. Please compare to v077 official and let me know what you think. I no longer have to force LineEdit and Button to equal heights, the layout code automatically Vcenters on HorizontalLayout containers (planning to make a setAlignment function later of course.)
Also updated the phoenix documentation on the website to reflect new stuff.
2011-03-22 - bsnes_v077r02.tar.bz2
Wouldn't recommend using this, but it has bsnes ported to the new auto-size calculating phoenix API.
Known issues:
minimumWidth/Height on layouts isn't working right, windows that use it are usually too small
Windows gives 0,0 size for empty text string sizes, which messes up a lot of default sizes for LineEdit controls
2011-03-20 - bsnes_v077r01.tar.bz2
Changelog:
fixed auto joypad polling bug (fixes Super Star Wars start button input)
added pseudo-random class; so far it is RAM only [WRAM, APURAM, VRAM, OAM, CGRAM]
added new system configuration options to bsnes.cfg
The pseudo-random class is optional. For right now, I am defaulting it to enabled. bsnes.cfg::snes.random = true.
You can of course turn it off if you want. This will break Death Brade and Unnamed Euro Racer, no questions about it.
So I don't know if I want to leave this on or off by default. Leaving it on will thwart emulator detection code and help to keep code that relies on uninitialized memory from working, but leaving it off will increase compatibility.
Interesting, huh? More accuracy typically increases compatibility, but it has the potential at a certain point to decrease it as well.
Death Brade will, beyond a shadow of a doubt, break on certain SNES units in the wild. Matching its pattern better will of course help, but it's the same situation as Super Bonk.
So yeah, we'll see how things go before deciding on what to do with v078 official.
Anyway, the randomness is a basic LFSR based on CRC32 (courtesy of blargg), seed is 'byuu', set on power-on. I may also allow time(0) as a seed. The seed is saved in the save state information. So once you have a state, the randomness is predictable and repeatable.
2011-03-16 - bsnes_v077-source.tar.bz2
Changelog:
video filters and shaders now populate inside main menu; no longer have to select them as files
fixed 2xSaI, Super 2xSaI and Super Eagle on 32-bit platforms; still buggy on 64-bit Windows
fixed linear mirroring issues (fixes Mega Man X dash bug)
fixed RAM memory mapping bug in Sufami Turbo games
home folder is now %APPDATA%/bsnes or ~/.config/bsnes
added paths.cfg file, which will allow you to specify custom paths for any file types
save states and cheat files for multi-slot games are based on slot names instead of BIOS names
fixed compilation warning on OS X with nall::decimal
fixed calculation bug in nall::fp
Makefile now has options variable, example: make options=debugger
configuration files and cheat database can now reside in the same folder as the binary itself
updated to 2011-03-11 release of mightymo's cheat database
2011-03-15 - bsnes_v076r07.tar.bz2
This should be the final WIP, left r06 up since that one has a binary.
Rather than make the libsnes API incompatible with previous versions, I just implemented path as return { basename, hint };
So you will still use the set basename function already there as before. So either DSP/MSU1/Serial all go in the ROM folder, or they all go somewhere else. You can be fancy and detect the gametype and override the basename as you like, if you really want.
Bumped the API to 1.3, and added const char snes_library_id(void); it will return "bsnes v076.07" at the moment. The internal string is static, but don't try caching it or modifying it anyway. You'll have to split the name and version yourself if you want them separately. API is backward-compatible to 1.0 still.
Also improved string::assign and string::append to take a variadic number of arguments. To make this happen, I had to make to_string return const char so that infinite recursion did not happen.
I had a lot of code like this:
Code:
cheat.append(code);
cheat.append("+");
cheat.append(desc);
Ugly. I also hate std::string syntax:
Code:
cheat << code << "+" << desc;
I may just remove that entirely, not sure yet. Left shift != string append.
So now there is:
Code:
cheat.assign(code, "+", desc); //cheat = { code, "+", desc }; also works nicely
cheat.append(code, "+", desc);
path code finished for ui/, just need to expose for ui-libsnes/ now
filters and shaders use radio items now, so you know which is active
smooth video was placed inside video mode (list is getting too long)
.bsnes -> .config/bsnes in make install
pixelshaders -> snesshader, added Makefile with make install target
snesfilter, added Makefile with make install and make clean targets
maybe other stuff
Testing would be good, planning to release v077 after I add the ui-libsnes extension for path deduction.
Note that it's not strictly needed, unless you want NEC-DSP/MSU1/Serial to work.
2011-03-13 - bsnes_v076r05.tar.bz2
Changelog:
QMenu::setVisible() does nothing, have to use QMenu::menuAction::setVisible()
improved path system, especially for ST games (states will be /path/to/slotA+notdir(slotB).ext, saves are per-game and per-path)
paths are now valid when you load just the BS-X/ST/SGB BIOSes with no carts inserted; maybe useful for BS-X I guess
removed video filter and pixel shader code from video settings dialog
added Settings->Video Filter and Settings->Video Shader menu lists
fixed the SaI family of filters in lores-mode only; although I don't really know how or why the change fixed them, the code is too vague
The menu list for the video filters and shaders are populated from either base/filters and base/shaders, or user/.config/bsnes/filters and user/.config/bsnes/shaders. It tries the first, and if it does not find anything it tries the second, just like the configuration files.
That meant doing away with multiple folders for the shaders, so now the shaders have a suffix to indicate what driver uses them, eg "Curvature.OpenGL.shader" and "Sepia.Direct3D.shader" -- probably nicer to use GLSL/HLSL, but using the driver name lets me sub in the currently loaded video driver with no special casing. So the filter if you have eg OpenGL loaded is ".OpenGL.shader"; and for SDL you get ".SDL.shader", which will obviously not be there as the non-GL-based SDL driver doesn't support shaders.
If there are no filters or no shaders available, the menu options do not show up. The lists are not radio items with active item ticked states just yet, but they will be.
more paths work, definitely need to clean up parameter names and enum typenames now
I had to cheat just a bit on the ST SRAM. For now, I am specifying the RAM size in the XML file.
The base XML isn't supposed to know about the slots though. What I need to do is write an ST header parser to get actual RAM sizes, and then from there generate an ST-specific XML file (like I do for the Game Boy) to specify this info. Would also be nice for some BS-X info.
Added NECDSP, MSU1 and Serial paths. This eliminates SNES::Cartridge::basename.
The core now calls Interface::path() to get the appropriate file-system path. It's a minor but useful abstraction that allows each implementation to handle how it wants to resolve paths for these files. The bad news is this breaks the libsnes API, but only for these three types. Basically the next version will remove the set basename function, and add a get path function instead. You will get a numeric parameter to indicate the type (NECDSP, MSU1, Serial, ...), and possibly a string with some helper information (NECDSP gives you the full program name, MSU1 gives you ".msu" or "-track#.pcm", and Serial gives you nothing.) You can then use the SNES ROM basename, or your own information entirely, to make the path that you want. Whatever you return is whatever the core will end up trying to open.
Ultimately, this allows people to put all their NEC DSP images in the same folder, if they so choose.
I also changed Sufami Turbo saves from .srm to .sts, so that they are distinguishable from SNES saves. Just like BS-X and Game Boy saves already were. And with that, I've added separate paths for BSP/BSS/STS/SAV. I'll probably have to call Game Boy RTC files "gbrtc" or something, but leave the extension as ".rtc" on the file system. Technically I can do the same for .bss and .sts, not sure if I should or not. BS-X PSRAM is weird either way. No standard filename between emulators for that, as far as I know.
I really need to clean up the path code. It's one giant function that handles four or five different path types. Need to break off functionality into smaller functions, and then make a sub-function for each type. Need better names, NECDSP isn't a cartridge slot. I need an ID to specify "I want a filename for both ST slots at the same time (game1+game2.extension)", etc. The string parameter isn't solely a type, and I need better handling of suffix. Probably should merge that in and prepend the "." character onto what is now type. Eg "srm" -> ".srm".
2011-03-03 - bsnes_v076r03.tar.bz2 (Windows 32-bit binary included.)
Please test this one guys, I'd like to release an update this weekend :D
I want to add a better message for when BIOS files do not exist. I also want to add manual paths for DSP/MSU1/BSS/BSP/SAV files.
Also, the debugger is extremely slow on Windows, but I don't know why. Probably phoenix related, but the MinGW profiler crashes. So I don't really know how I'm going to fix that. Help would be appreciated.
Changelog:
paths.cfg work completed
save states/archives and cheat files for multi-slot games are more intelligent now
For paths.cfg, there are three types of entries. Each have different special prefixes.
Folder paths: sfc, bs, st, gb, filter, shader
By default, bsnes will remember the last path you loaded a file of said type from. It will be prefixed with "recent/" in the file.
Specify an explicit hard-coded path to override this.
BIOS paths: satellaviewBios, sufamiTurboBios, superGameBoyBios
Remembers an explicit hard-coded path to the BIOS you selected last.
I was thinking that a nice feature would be for the "Load Special" windows to pop open the slot A load dialog if a BIOS was selected.
Select a game from this popup and it loads directly, cancel it to get the regular window to override the BIOS.
Save paths: srm, rtc, bsa, bst, cht, log
Paths to write various files that the emulator generates.
Note: srm groups bsp, bss and sav for now. Was being lazy.
There are four special prefixes for these:
"base/" -- gets replaced with the executable path
"user/" -- gets replaced with the same folder where bsnes.cfg goes (%APPDATA%/bsnes or ~/.config/bsnes) -- good for hiding files
"./" -- gets replaced with the current ROM path
"../" -- gets replaced with the folder above the current ROM path
If you want to go up two folders or more, then use a hard-coded path. If that's not good enough, kill yourself because God hates you.
If I'm forgetting any savable data files, please let me know.
The save state/archive and cheat file path finding update works like this: most of the time, you want the states and cheats to be named after the SNES ROM. But for BS-X, Sufami Turbo and Game Boy, you want it to be named after the slot cart. For instance, playing Mega Man II and then Contra 3, you don't want both to use Super Game Boy (US).bst. The one edge case here is dual Sufami Turbo mode. I still default to saving cheats and states as slot A's filename. I'll probably have to create a concatenation of both names, but for now just be careful with that.
2011-03-01 - bsnes_v076r02.tar.bz2
Changelog:
fixed a crashing bug when you toggle a cheat code and then load a save state
added paths.cfg
bsnes now remembers the most recent path per file-type, like bsnes/Qt used to do
re-added -s to Linux linker flags
fixed crash with libsnes/SGB XML parsing
Okay, so the way paths work is pretty cool, but still a work in progress. Every load type (SFC, BS, ST, GB, filter, shader) has its own path string. This string keeps track of the last path you've loaded a file from. The path is prefixed with a ":" to indicate that it is not a manual path, but rather a recent path, and that subsequent loads should update it with a new recent path. Specify a path without the ":" and it will always load from that path, and never update the path from subsequent path loads.
The support is currently only there for initial load paths and remembering the BSX/ST/SGB BIOS file paths. A lot more work will be needed for the rest.
Also, this is complicating my "don't reload the window if the path and type is the same" code, which is what's needed to remember the last selected file in the list. Man that's some annoying code to support :P
fixed linear mirroring issue in memory map (fixes dash in Mega Man X)
home path for Windows is now %APPDATA%/bsnes (not %APPDATA%/.bsnes)
home path for OS X and Linux is now ~/.config/bsnes (not ~/.bsnes)
bsnes-geometry.cfg is now geometry.cfg; and it stores width,height
I do not yet restore width, height; because the GTK+ and Qt APIs treat window resize as implying setMinimumSize
added bsnes/ui/path; which I have some significant plans for
fixed a bug in realpath (specified path is not always a folder, so we should not always append / as with userpath)
bsnes.cfg, geometry.cfg and cheats.xml may now optionally exist in the same folder as the binary itself
ruby only imports the nall namespace after including system headers (should fix OS X 'decimal' issue)
nall::fp now uses atof (fixes nall::fp("0.05"))
I split the CheatDatabase to a separate cheat-database.cpp file; it was pretty ugly packed into cheat-editor.cpp
Makefile now has "options := " line; where you can add "debugger" if you like, and in the future maybe more options
--- also works via command-line: make options=debugger
2011-02-25 - bsnes_v076-source.tar.bz2
Most notable in this release is that sound support has been added to my own Super Game Boy emulation. The GUI toolkit, phoenix, has also received a complete rewrite; with the most visible change there being that windows are now resizable.
Changelog:
added sound emulation to Game Boy core
fixed Super Game Boy save state support
added HexEdit widget to Windows and Qt targets; debugger can now be compiled on all platforms
entering fullscreen now auto-hides mouse; and mouse capture is toggled otherwise by F12 key
fullscreen command and geometry caching works much better on GTK+ and Qt targets
phoenix rewritten from scratch; now supports resizable layout containers
phoenix/Windows no longer relies on buggy SetParent API to reparent widgets
2011-02-24 - bsnes_v075r16.tar.bz2 (Windows 32-bit compatibility binary included)
This has my latest API enhancements, but there are some known issues:
resize on Windows seems to not repaint the buttons properly in rare cases. I may just need to revert to flickering resize.
GTK+ reports the wrong menu height, off by two pixels, prior to the window being realized (made visible)
--- this results in the main window moving up two pixels after each run of bsnes
The menu height bug was actually there previously, it was just that Qt and GTK+ were computing the frame margins incorrectly (ignoring the menu bar) before.
On the bright side, ui/settings/input.cpp has been improved by way of the new multi-layout support. The window is no longer forced to an awkward 640 pixels wide, as the mouse axes/buttons can overlap now. The code is also simpler since I am using the Layout::setVisible command to toggle groups on and off instead of doing it for each and every control.
2011-02-22 - bsnes_v075r15.tar.bz2
phoenix/GTK+ rewrite completed. All three targets should now be 100% operational with full resize support.
2011-02-19 - bsnes_v075r14.tar.bz2 (Windows binary is included.)
Adds the new phoenix/Windows. Testing would once again be appreciated, as this is basically a rewrite of the entire core of the GUI.
Double-clicking listbox items works, at least :D
2011-02-16 - bsnes_v075r13.tar.bz2
Found the source of lag on cartridge load. ListView::modify() was not locking Qt messages, so it was causing a CheatEditor::refresh (copies 16MB of memory each call) for all 128 cheat items.
Final issue now is that nested submenus (menus inside of menus) are not applying Window::setMenuFont yet.
2011-02-15 - bsnes_v075r12.tar.bz2
phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues:
1: font sizes of menu items are wrong, I can fix this easily enough
2: there's some sort of multi-second lag when loading games, not sure what's happening there yet
The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+.
The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh.
I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this:
Code:
HorizontalSlider::HorizontalSlider() : state(new State), base_from_member<pHorizontalSlider&>(new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {}
But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-09 - bsnes_v075r11.tar.bz2 (Windows 32-bit compatibility binary included)
Rewrote the way menus are attached, they act like layouts/widgets now.
All three phoenix targets once again work with both radio menu items and radio widgets. Both GTK+ and Qt have built-in group controls right inside the widgets, so I don't have to keep my own groups around anymore. They do act screwy at widget creation though, have to jump through some hoops to get it to work right. All I can say is, definitely set all child widgets to the parent before trying to check any of them.
My long-term goal for the main window is to honor the fullscreen video setting as a generic setting, and let the window scale auto-fit the best possible size that matches your scale preference into the output window, centered just like fullscreen. For now, I've just set it to a fixed window size until I finish working on phoenix. The scale X settings will just be to snap the window to an exact size in case you don't want any black borders, they won't be radio items and the bsnes-geometry.cfg file will save width/height information as well.
Simplified the sizing requirements for creating layouts and updated all bsnes windows to support the new system. Layouts also expose their minimum width/height values, which I use to create perfectly sized windows on all three platforms. This will fix cut-off heights on the last Windows WIP. Qt is being annoying though and forcing a minimum window size of 300,100 despite me telling it to use a smaller window size. Always have to fight with Qt, I swear to god.
To get the Windows debugger looking sharp, I will need to add a Geometry Font::geometry(const nall::string&) function. Easy to calculate on Windows with DrawTextEx, not so easy on other targets. But get that value, add +~10px margins for client edges, and then use layout.minimumWidth/Height() + text string geometry.
2011-02-07 - bsnes_v075r10.tar.bz2 (Windows 32-bit compatibility binary included)
All targets can now handle dynamically changing the header text of listbox widgets, but I wouldn't recommend trying it with items in your list.
phoenix/Windows and phoenix/Qt are mostly fully operational now. All platforms support dynamic layout resizing. I tried WM_GETMINMAXINFO (thanks, OV2), but it was acting kind of choppy on resize, and it would get confused and go crazy if you snapped one direction to the minimum height but not another, so for now I'm leaving it off.
phoenix/GTK+ will be missing some functionality in regards to window geometry. The other two have a more coherent strategy now: geometry() is the client area, and setGeometry moves the client area to where you ask for. This makes truly centering your client area trivial. frameGeometry() includes the borders, menu and status. There is no setFrameGeometry(), not sure if I really even want that, but it could be useful so who knows. All targets also support non-resizable windows.
X11 is of course horrendously poor with frame sizes, Qt and GTK+ don't even pretend to simulate them, so they say the frame is 0x0 pixels in size until your widget is fully realized and visible to the end user. So for now, to get window positioning right, I have to wait until the window appears and then reposition the window again, causing a slight jump. My plan is to build some persistent caching support directly into phoenix. From here, I can just have the window snap the very first time you run your very first phoenix app. I'll then determine the frame size information, and use that to create future windows. Once they spawn, I'll recheck and update the frame size info in case it has changed (eg user changed themes.) Saving settings into .config/phoenix will allow me to avoid having to snap the window every time on first startup. If the config file is missing or unwritable, too bad, happens every time then.
I'm thinking about renaming onResize to onSize, and getting rid of Window::create(). Rather make it spawn like every other control in its constructor.
2011-02-06 - bsnes_v075r09.tar.bz2
Ported phoenix/Windows and phoenix/GTK+ over to the new system. There are some problems that need to be addressed:
Windows ComboBox height setting needs widget creation height to properly scale itself (make Widget::setGeometry virtual and override ComboBox::setGeometry)
Windows Canvas is completely broken
GTK+ Canvas is slow as shit compared to Qt Canvas, probably nothing I can do about it, have to do a very costly conversion because GTK+ is stupid and uses BGR like Nintendo
GTK+ listboxes are fucking insanely complicated to set up. Currently I just split the second-half of creation to the setHeaderText call, but when you don't call that, things explode
--- I'm probably going to have to completely destroy and recreate listboxes when changing the header text / column count
Qt resize code is still impossible to get right, it's not letting me size a window > 2/3rds of the screen size (it's in their docs)
--- I swear, Qt is the most painful API in the world to move/size windows with
now that Window is separate, it really needs geometry() and frameGeometry() as the two are quite different
I need a way to toggle window resizability for fixed layouts, Qt is once again going to be a nightmare as it lacks a way to do this other than fixed layouts
GTK+ currently explodes on bsnes, millions of console messages, wonderful
plenty more I'm forgetting
One bit of really cool/good news though: I made Fixed/Horizontal/Vertical layouts external to phoenix itself. The code is included for all targets so that it's always there and compiled into one object, but the great news is that you can easily write your own layout widgets and they'll work on all toolkits instantly.
That resize issue with bsnes was so simple it's annoying: my FixedLayout container was repositioning on geometry updates. Made it only do it once at creation like it should.
bsnes now has a fancy resize, grow the window and get black borders, shrink it and the video shrinks with it. I plan to make it fancier with constraint settings (center, scale, stretch). Basically I want to turn the fullscreen setting into a general setting that also applies to windowed scaling. I will probably turn the video scale X sizes into regular items instead of radio boxes, so you can easily reset to a fixed size whenever you want. Update bsnes to remember width,height geometry as well and it should be quite nice.
2011-02-05 - bsnes_v075r08.tar.bz2
Eleven hours of work. Window is now a base type (inherits from Object, not Widget), same for Layout. FixedLayout still inherits from Layout. Added HorizontalLayout and VerticalLayout types, that can append each other to themselves to create box layouts. Layout margins are supported, spacing is specified inline (I find this a much better way to fine-grain spacing than Qt's single setSpacing function), and alignment is handled strictly via padding widgets (insert a zero-sized label and it will automatically grow to consume all extra space.)
Overall, my box packing model is slightly less powerful than Qt's, but it is a good deal simpler and and easier to use in 90% of cases. The one limitation I hit was with my input settings window, I'm not currently able to embed two different layouts and toggle one on and the other off to show only either { mouse x-axis, y-axis } or { mouse left, middle, right }, so they instead just space out differently and I had to grow the input window width a bit to compensate.
Resizing works great, pretty cool seeing that this is the first time I've ever written my own resizer. I had to fight with Qt for several hours to the point of potentially developing an aneurysm, but I finally got it to properly handle geometry and sizing stuff. Some weird issue with the bsnes viewport widget, I tell it to resize and for some reason it doesn't. Cheap hack, I just make it constantly resize every video refresh and it eventually takes. Wish I knew what was up with that.
All of bsnes now uses dynamic layouts sans the main window, so you can resize them however you like.
This is still all Qt-only, I'm afraid. The other two ports are in-progress.
2011-02-04 - bsnes_v075r07.tar.bz2
This has the phoenix changes applied. Instead of widgets attaching directly to windows, you now attach them to layouts, which can then be attached to windows. Layouts are widgets themselves, so adding layouts to layouts is trivial. It also allows for multi-widget show/hide, etc.
Right now there is only FixedLayout, but of course the plan is to support a BoxLayout, that lets you add HorizontalLayout and VerticalLayout containers to it, thus enabling auto-resize and simpler form layout.
So far only phoenix/Qt is 100% moved over. phoenix/GTK+ has about 1/3rd ported, and phoenix/Windows only has one control ported over as a proof-of-concept.
On the user side, bsnes, bgameboy, snespurify and curse have been moved to this new layout system. All of bsnes works great with it, as far as I can tell. Fullscreen, debugger, etc are good.
Testing for regressions would be nice.
2011-02-02 - bsnes_v075r06.tar.bz2
Removed the floating-point volume adjustments from the wave channel and the left/right speaker mixers. Also, against my better judgment I'm backing out of left/right computation when they are both turned off. This basically makes non-stereo games run faster, but will make stereo games appear to run slower. I don't like it when end-users experience mystery slowdowns.
Anyway, it appears that the audio calculation is really fucking demanding. Knocks FPS from 800 down to 300. I thought it might be libco, so I took it out and it only went up to 305fps o.O
There is also some sort of problem with bsnes/Super Game Boy audio. The latency is really great when you first start, but it seems to drift apart over time until it is well over 500ms, and then it either pops or fades back to very low, sub-50ms latency again. The way I handle mixing is that the coprocessor audio samples go into a resampler to the native SNES rate, and fed to an output buffer. SNES audio samples go there untouched. When there is a sample in each, I add them together and average the result (I still don't understand why we divide by two since these are signed integers), and output it immediately. It's just-in-time sampling, so as long as DSP v Coprocessor do not drift very far, it should have very low latency. And I make the CPU sync DSP and Coprocessor once per scanline, which is something like 15 samples or so.
2011-02-02 - bsnes_v075r05.tar.bz2
Added Game Boy sound emulation, all four channels.
It's really, really, really bad. Plenty of bugs, I don't even know what the fuck a high-pass filter is so that isn't there. Hermite resampling from 4MHz down to 44KHz. But it's tolerable.
I don't understand what sweep is for at all, and I'm sure I have that insane recursive reload behavior wrong.
This is pretty much my own design. I referenced blargg's gb snd emu, blargg's older gb apu ref, Cydrak's APU core, that lousy gbdev wiki article, the completely and utterly worthless pandocs, and received nothing but bad and wrong information that just wasted my time from #gbdev.
But I managed to pull it off. It's also painfully slow, like 250fps on my machine slow. Countless optimizations are possible.
Anyway, I'd love some help with bug-fixing :D
But I'm not really too concerned with absolute perfection anyway, so no big deal. I'm sure it'll get fixed up over time.
2011-02-01 - bsnes_v075r04.tar.bz2
Changelog:
hooked up everything necessary for Game Boy sound emulation ...
bgameboy and bsnes/SGB input 4MHz frequency, and output 44.1KHz frequency (produces soft static for now, to verify it is working)
rewrote all of gameboy/apu, it now has a 4MHz worker thread, and separate classes/folders for each channel+master, and serializes
So it's basically all I can do without actual emulation code or human-readable documentation/example code.
2011-01-31 - bsnes_v075r03.tar.bz2
Changelog:
added full HexEditor widget to phoenix/Qt (has dynamic scrollbar like phoenix/GTK, but does not yet support page up/down scrolling)
optimized debugger to look great with either phoenix/GTK or phoenix/Qt
fixed phoenix/Qt fullscreen mode (had to allow resizing of the layout, and resize the container)
fixed phoenix/Qt Window::setBackgroundColor() bug that was making statusbar invisible
entering fullscreen now captures mouse, leaving fullscreen releases it - so by default, no cursor in fullscreen mode now
F12 key was assigned the task of toggling mouse capture, Tools->Capture Mouse was removed
above change allows toggling mouse capture in fullscreen if you like
It wasn't my idea, but toggling the mouse capture in fullscreen also hiding the mouse cursor is what I call genius design. Two birds with one stone, and very intuitive.
Also, the default GUI on Linux for bsnes and bgameboy is now Qt, instead of GTK+. I did this because Qt's fullscreen is far more stable, and I fixed up the remaining bugs anyway.
Qt is also better overall at remembering window geometries on program exit, but it does have one quirk with the load cartridge dialog slowly shifting down. I would love some help with that.
You can of course use whichever GUI toolkit you prefer, they are both first-class citizens now and will hopefully remain that way.
I may not like Qt as a cross-platform API, but it really is quite effective on its home-turf, X11.
2011-01-30 - bsnes_v075r02.tar.bz2
Changelog:
added ui-libsnes directory back into source archive; make archive-all includes it now
added basic HexEditor widget to phoenix/Windows
I still need a HexEditor class for phoenix/Qt, and the Windows one lacks a vertical scrollbar. But it does allow the bsnes/Windows debugger to be built now. You will need to use the goto text box to type in an address to edit on Windows. The scrollbar really isn't that useful here anyway, scrolling through 16MB using a 200-pixel-high scrollbar is pretty terrible.
The bigger problem is that I don't have functions to determine the width/height of text strings, so the sizes are all screwed up. Since Windows fonts are so damn big, it is causing lots of ugly wrapping. And then there's the annoyance that read-only controls on Windows show up with a grayed out background ... ugh. It looks pretty terrible, so lots of work will need to go into refining it.
2011-01-28 - bsnes_v075r01.tar.bz2
Changelog:
fixed Super Game Boy save state support
both SNES and GameBoy only initialize serialize size on cartridge load once now, just like I've already done with memory mapping
added nall/public_cast.hpp for fun ... don't worry, I'm never actually going to use it in production code :D
Game Boy remaining issues:
Contra 3: first boss graphics are messed up
Makai Toushi SaGa: title screen graphics are glitchy during scroll-in
Taito Variety Pack: Bubble Bobble locks up
- Taito Variety Pack: Sagaia locks up
Game Boy: no sound emulation
- Super Game Boy: save states crash the CPU upon load
2011-01-25 - bsnes_v075-source.tar.bz2
This release brings improved Super Game Boy emulation, the final SHA256 hashes for the DSP-(1,1B,2,3,4) and ST-(0010,0011) coprocessors, user interface improvements, and major internal code restructuring.
Changelog:
completely rewrote memory sub-system to support 1-byte granularity in XML mapping
removed Memory inheritance and MMIO class completely, any address can be mapped to any function now
SuperFX: removed SuperFXBus : Bus, now implemented manually
SA-1: removed SA1Bus : Bus, now implemented manually
entire bus mapping is now static, happens once on cartridge load
as a result, read/write handlers now handle MMC mapping; slower average case, far faster worst case
namespace memory is no more, RAM arrays are stored inside the chips they are owned by now
GameBoy: improved CPU HALT emulation, fixes Zelda: Link's Awakening scrolling
GameBoy: added serial emulation (cannot connect to another GB yet), fixes Shin Megami Tensei - Devichil
GameBoy: improved LCD STAT emulation, fixes Sagaia
ui: added fullscreen support (F11 key), video settings allows for three scale settings
ui: fixed brightness, contrast, gamma, audio volume, input frequency values on program startup
ui: since Qt is dead, config file becomes bsnes.cfg once again
Super Game Boy: you can now load the BIOS without a game inserted to see a pretty white box
ui-gameboy: can be built without SNES components now
libsnes: now a UI target, compile with 'make ui=ui-libsnes'
source: removed launcher/, as the Qt port is now gone
source: Makefile restructuring to better support new ui targets
source: lots of other internal code cleanup work
Many thanks to those who helped beta test for this release, we were able to squash some important bugs.
2011-01-23 - bsnes_v074r11.tar.bz2
Changelog:
debugger compiles on all three profiles
libsnes compiles on all three platforms (no API changes to libsnes)
sa1.cpp : namespace memory removed (SA-1 specific functions merged inline to SA1::bus_read,write)
GameBoy: added serial link support with interrupts and proper 8192hz timing, but obviously it acts as if no other GB is connected to it
GameBoy: added STAT OAM interrupt, and better STAT d1,d0 mode values
UI: since Qt is dead, I've renamed the config files back to bsnes.cfg and bsnes-geometry.cfg
SA1: IRAM was not syncing to CPU on SA-1 side
PPU/Accuracy and PPU/Performance needed Sprite oam renamed to Sprite sprite; so that I could add uint8 oam[544]
--- makes more sense anyway, OAM = object attribute memory, obj or sprite are better names for Sprite rendering class
more cleanup
I think I'm pretty much finished with the code cleanup now ... the big "would be really nice" thing for v075 would be Game Boy sound emulation, but I don't know how to do that so it probably won't happen. I suppose I'll spend a few hours testing games today or tomorrow and then post v075.
2011-01-23 - bsnes_v074r10.tar.bz2
Major WIP, countless changes. I really went to town on cleaning up the source today with all kinds of new ideas.
I'll post the ones I remember, use diff -ru to get the rest.
What I like the most is my new within template:
Code:
template<unsigned lo, unsigned hi>
alwaysinline bool within(unsigned addr) {
static const unsigned mask = ~(hi ^ lo);
return (addr & mask) == lo;
}
Before, you would see code like this:
Code:
if((addr & 0xe0e000) == 0x206000) { //$20-3f:6000-7fff
The comment is basically necessary, and you have to trust that the mask is right, or do the math yourself.
Now, it looks like this:
Code:
if(within<0x20, 0x3f, 0x6000, 0x7fff>(addr)) {
That's the same as within<0x206000, 0x3f7fff>, I just made an SNES-variant to more closely simulate my XML mapping style: 20-3f:6000-7fff.
Now obviously this has limitations, it only works in base-2 and it can't manage some tricky edge cases like (addr & 0x408000) == 0x008000 for 00-3f|80-bf:8000-ffff. But for the most part, I'll be using this where I can. The Game Boy is fully ported over to it (via the MBCs), but the SNES only has the BS-X town cartridge moved over so far. SuperFX and SA-1 at the very least could benefit.
Next up, since the memory map is now static, there's really no reason to remap the entire thing at power-on and reset. So it is now set up at cartridge load and that's it. I moved the CPU/PPU/WRAM mapping out of memory.cpp and into their respective processors. A bit of duplication only because there are multiple processor cores for the different profiles, but I'm not worried about that. This is also going to be necessary to fix the debugger.
Next, Coprocessor::enable() actually does what I initially intended it to now: it is called once to turn a chip on after cartridge load. It's not called on power cycle anymore. This should help fix power-cycle on my serial simulation code, and was needed to map the bus exactly one time. Although most stuff is mapped through XML, some chips still need some manual hooks for monitoring and such (eg S-DD1.)
Next, I've started killing off memory::, it was initially an over-reaction to the question of where to put APURAM (in the SMP or DSP?)
The idea was to have this namespace that contained all memory for everything. But it was very annoying and tedious, and various chips ignored the convention anyway like ST-0011 RAM, which couldn't work anyway since it is natively uint16 and not uint8. Cx4 will need 24-bit RAM eventually, too. There's 8->24-bit functions in there now, because the HLE code is hideous.
So far, all the cartridge.cpp memory:: types have been destroyed. memory::cartrom, memory::cartram become cartridge.rom and cartridge.ram. memory::cartrtc was moved into the SRTC and SPC7110 classes directly. memory::bsxflash was moved into BSXFlash. memory::bsxram and memory::bsxpram were moved into BSXCartridge (the town cartridge). memory::stAB were moved into a new area, snes/chip/sufamiturbo. The snes/chip moniker really doesn't work so well, since it also has base units, and the serial communications stuff which is through the controller port, but oh well, now it also has the base structure for the Sufami Turbo cartridge too. So now we have sufamiturbo.slotA.rom, sufamiturbo.slotB.ram, etc.
Next, the ST-0010/ST-0011 actually save the data RAM to disk. This wasn't at all compatible with my old system, and I didn't want to keep adding memory types to check inside the main UI cartridge RAM loading and saving routines.
So I built a NonVolatileRAM vector inside SNES::Cartridge, and any chip that has memory it wants to save and load from disk can append onto it : data, size, id ("srm", "rtc", "nec", etc) and slot (0 = cartridge, 1 = slot A, 2 = slot B)
To load and save memory, we just do a simple: foreach(memory, SNES::cartridge.nvram) load/saveMemory(memory).
As a result, you can now keep your save games in F1 Race of Champions II and Hayazashi Nidan Morita Shougi.
Technically I think Metal Combat should work this way as well, having the RAM being part of the chip itself, but for now that chip just writes directly into cartridge.ram, so it also technically saves to disk for now.
To avoid a potential conflict with a manipulated memory map, BS-X SRAM and PSRAM are now .bss and .bsp, and not .srm and .psr.
Honestly I don't like .srm as an extension either, but it doesn't bother me enough to break save RAM compatibility with other emulators, so don't worry about that changing.
I finally killed off MappedRAM initializing size to ~0 (-1U). A size of zero means there is no memory there just the same. This was an old holdover for handling MMIO mapping, if I recall correctly. Something about a size of zero on MMIO-Memory objects causing it to wrap the address, so ~0 would let it map direct addresses ... or something. Whatever, that's not needed at all anymore.
BSXBase becomes BSXSatellaview, and I've defaulted the device to being attached since it won't affect non-BSX games anyway. Eventually the GUI needs to make that an option. BSXCart becomes BSXCartridge. BSXFlash remains unchanged.
I probably need to make Coprocessor::disable() functions now to free up memory on unload, but it shouldn't hurt anything the way it is.
libsnes is most definitely broken to all hell and back now, and the debugger is still shot. I suppose we'll need some tricky code to work with the old ID system, and we'll need to add some more IDs for the new memory types.
2011-01-21 - bsnes_v074r09.tar.bz2
This WIP fixes up the last bit from the old memory mapping system, the BS-X Satellaview town cartridge now has a static memory mapper that is dynamically decoded based on register settings. Tested with BS Town + BS Zelda, and I can get in-game just fine. The mapping code is actually a lot more readable this way, too.
2011-01-21 - bsnes_v074r08.tar.bz2
The nall::function binding for the memory map apparently breaks when the debugger is enabled, as PPU:: becomes PPUdebugger::, etc; and C++ isn't smart enough to upconvert for us.
Not sure how I am going to work around that yet ...
Changelog:
improved GameBoy::CPU::Halt emulation, fixes Legend of Zelda intro water+world-map scrolling at the same time
added GameBoy::APU skeleton, and hooked up MMIO read/write for all registers
modified nall integer->string functions
I really, really have absolutely no idea how to pull off Game Boy sound emulation. The documentation doesn't explain it at all, and blargg's GbSndEmu isn't anywhere near as easy to understand as his SNES DSP emulator was. It has so very many abstractions. The documents only tell you register names, which doesn't really help at all.
As for nall::string changes: there's no more padding template parameter for any of these. Going more for sensible real-world uses rather than uniformity.
hex(n) -> writes 0000nnnn
binary(n) -> writes 0000nnnn
decimal(n) -> writes nnnn
ldecimal(n) -> writes 'nnnn ' (decimal value is left-aligned)
rdecimal(n) -> writes ' nnnn' (decimal value is right-aligned)
integer(n) -> writes +nnnn or -nnnn (adding + on positive to ensure length consistency)
linteger(n) -> writes '-nnnn ' (sign is part of the length)
rinteger(n) -> writes ' -nnnn' (sign is part of the length)
fp(n) -> writes nn.nn
This is mostly because decimal<3, ' '>(n) was unwieldy looking. Now we can do rdecimal<3>(n) to mean the same thing, and we can also left-align now too.
The old integer was particularly ugly: integer<10>(-5) -> '-000000005'
The integer and decimal functions also clamp now. With printf:%3u,1000, you would get 1000.
While it's nice not to truncate, if you are trying to build a formatted output, it's very bad to let this happen.
Unfortunately how to clamp is always a problem, drop the high or the low numbers? Right now it depends on whether you use the l or r forms.
This isn't 100% finished yet, hex, binary and fp still do not clamp output lengths.
2011-01-18 - bsnes_v074r07.tar.bz2 (Windows 32-bit compatibility binary included.)
Fullscreen works on all ports, but Qt is in general pretty wonky at the moment. Don't really care right now.
F11 toggles fullscreen, there is no menu or status in fullscreen, and it auto-scales to the highest even multiple that it can.
It copies all other settings (filter, shader, aspect correction, video region, vsync, async) from your windowed mode settings.
You cannot enable the menu or status bars, because those are a major pain in the ass to support with both GTK+ and Qt returning nonsense geometries.
Combine with each platform treating whether or not to handle menus and/or statuses as part of the geometry or not, and it's a recipe for pain.
It is pseudo-fullscreen for now, but if we have some spiffy code in the future to set a true fullscreen that works on Linux (and hopefully OS X), I'll add a true-FS option to ruby later.
I am not going to hide the mouse cursor at this time, because right now ruby is in charge of that for mouse capture and it's tricky to make phoenix also capable of controlling that.
I am not supporting media center users who want to start in fullscreen, and I am not worrying about idiots who can't figure out how to exit fullscreen mode.
I am not going out of my way to support multi-monitor setups, Qt had special handling for it that phoenix does not have.
2011-01-17 - bsnes_v074r06.tar.bz2 (Windows 32-bit compatibility binary included.)
This WIP uses the 16MB+64MB memory tables for 1:1 mapping of the S-CPU bus.
Minimum RAM requirement goes up to 128MB, dare I be bold here and recommend you have 256MB.
I also hooked up the basic bindings for making pseudo-fullscreen windows in phoenix/Windows and phoenix/GTK+, but both have some serious issues.
GTK+ won't resize my form container, even though it's the same code I used successfully in bsnes v039 and prior with hiro
Windows scale selection breaks the faux-fullscreen effects
I am intending to write off the menu/status bars and just auto-size the video to fill the screen, nice and simple
I really don't want to mess around with this for another two weeks like every other time I try and do this, if someone could lend a hand that'd be fantastic.
2011-01-16 - bsnes_v074r05.tar.bz2
Oh good, that turned out to be a lot easier than I expected.
Almost all of the work was already done yesterday in porting the SA-1 over to a static map.
New results:
Code:
CPU SFX SA1
v074.01 180 94 111
v074.03 168 81 93
v074.04 ... 91 ...
v074.05 168 91 109
-6.5% -3% -2%
2-3% on special chips, although a shame, is almost a write-off.
So now that there's only one bus, we can try some crazier ideas (16m-entry tables and such) to try and boost non-SFX/SA1 games.
There's also some new room to boost SFX/SA1 speeds even more via heavier inlining.
2011-01-16 - bsnes_v074r04.tar.bz2
SuperFXBus was inheriting from Bus, in other words using a copy of the same memory mapping subsystem.
I've removed that and made it a simple mask, since only ROM+RAM are mapped there. Result:
Code:
CPU SFX SA1
v074.01 180 94 111
v074.03 168 81 93
v074.04 ... 91 ...
So the SuperFX speed loss has been mostly removed. I am going to attempt the same on the SA-1 now, but it's the SA-1 that took more than half of my time the other day. It's much, much more complex. There's also two Bus inheritors: the VBR bus and the main SA-1 CPU bus.
By removing both, I am free to grow the size of the main CPU bus without increasing memory usage three-fold.
2011-01-15 - bsnes_v074r03.tar.bz2
You guys are going to hate the hell out of this one. It's twenty hours of non-stop work, no exaggeration at all. Started at 4AM, just wrapped up now at 8PM.
I rewrote the entire memory subsystem.
Old system:
65536 pages that map 256 bytes each
Mapping a new page overwrites old page
Granularity capped at 256 bytes minimum, requiring ST-001x to map 60:0000-00ff instead of 60:0000,0001
Classes inherit from MMIO and Memory, forcing only one mappable function per class, and fixed names
MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity
Can dynamically change the map at run-time, MMC register settings perform dynamic remapping
New system:
XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that shapes almost everything on the SNES very well
Internally, 2048 pages that map 8192 bytes each
Pages are vectors, scans O(n) from last to first (O(log n) would not help, n is never > 3)
Can multi-cast writes, but not reads [for the obvious reason of: which read do you return?]
Can map reads and writes separately
Granularity of one for entire 24-bit address range, no need for MMIO - whatever is in XML is exactly what you get
Read/Write tables bind function callbacks, so I can have any number of functions with any names from any classes with no inheritance (no more uPD7725DR, uPD7725SR helpers, etc)
Less memory usage overall due to less tables [ I tried 16 million tables and it used 2GB of RAM >_o ]
Cannot dynamically change the map at run-time, MMC read/write functions perform address translation [worse average case speed, better worst case speed]
Now the hate me part, functors can't beat virtual functions for speed. There are speed penalties involved:
-4.5% on average games
-11% on SuperFX games (SFX has its own bus)
-15% on SA-1 games (SA-1 has two buses)
Of course the two that need the speed the most get the biggest hits.
I'm afraid there's really not a lot of wiggle room to boost speed back up.
I suppose one bright spot is that we can much more easily try out entirely new mapping systems now, since the dynamic portions have been eliminated.
Also, I am too tired. I hooked up every special chip but BSXCart. That one has cached MMC registers that I need to set up.
2011-01-13 - bsnes_v074r02.tar.bz2
Changelog:
updated/fixed st0011.bin SHA256 sum
removed launcher/
building ui-gameboy only builds the Game Boy core, not the SNES core
binary name output is bgameboy for ui-gameboy
make install/make uninstall work as expected with the extra data files
2011-01-13 - bsnes_v074r01.tar.bz2
Changelog:
fixed libsnes to compile again, the GB RTC constant is there but doesn't do anything just yet (no serialize support in GameBoy core)
libsnes: added SNESMEMORY(WRAM,APURAM,VRAM,OAM,CGRAM) -- really only for the first one, it allows libsnes users to implement their own cheat search
you can now load the SGB BIOS without a game!! please be sure to enjoy the blinking cartridge icon emulation :D
necdsp (uPD7725,96050) - simplified code a bit: removed persistent regs.idb, simplified jumps, merged exec() with main loop, etc.
nall::function - fixed an initialization bug when copy-constructing objects
nall::vector - use calloc instead of malloc to help safeguard against uninitialized class data (potentially hides errors, but better than crashing in production)
Forgot to nuke the launcher until upload finished, will do that next time.
2011-01-11 - bsnes_v074.tar.bz2
This release adds full low-level emulation of the NEC uPD96050 coprocessor, used by the ST-0010 (F1 Race of Champions II) and the ST-0011 (Hayazashi Nidan Morita Shougi). The former was already playable with HLE, but lacked timing emulation. The latter has never been playable through emulation before now. But as with SD Gundam GX before, you really weren't missing much.
Please see my donations page, and send a small token of thanks to Dr. Decapitator's Paypal address if you don't mind. The NEC uPD96050 proved to be much more difficult than anticipated, and he had to dump the chips multiple times each, spending many days on this.
He is currently working on extraction of the Cx4 (Mega Man X2, Mega Man X3), which initial scans have shown to be an Hitachi HG51B169. Also remaining is the ST-0018, which is used by the only remaining unplayable game: Hayazashi Nidan Morita Shougi 2.
Also new in this release is my own Game Boy emulator. It is being used to provide native Super Game Boy support, built directly into bsnes. This core is released under the GPLv2, but I am willing to grant a more permissive license for other SNES emulators, if anyone is interested.
Of course I cannot compete with the quality of gambatte, and certainly not from only a weeks' worth of work. Currently, there is no Game Boy-side sound output and there are quite a few bugs remaining in its emulation core. I would appreciate any help on this, the Game Boy is not my forte. So yes, we are taking a step back today, so that we may take two steps forward in the future. See my previous posts for more on the advantages my native Game Boy emulation core brings to the project.
As I am in a very good mood, I have posted two pre-compiled binaries this time: the first is a 32-bit Windows binary built with the faster performance profile; and the second is a 64-bit Windows binary built with accuracy profile.
Lastly, the debugger is still Linux-only, but it is now stable enough to be considered usable. Check it out if you like, compile with -DDEBUGGER to enable it.
2011-01-10 - bsnes_v073r07.tar.bz2
I give up for now. This WIP doesn't really improve uPD any, but it does have major fixes to the debugger.
Debugger is still Linux-only for want of a HexEditor widget, but the Linux one is now usable.
Before it'd trace and search for breakpoint at sub-1fps. Fixed it to not break out of core for simple things and it'll run at near-fullspeed for BPs, half-speed for tracing to file (lots of I/O.)
EDIT: rather obvious, but:
Code:
000f a = $00da;
0010 b += drnf;
0011 rp = a;
0012 sol = [rp];
0013 pc.l = sol;
pc.l = sol = datarom[a=00da] is static and unchanging, no matter what op is fed to DR.
So JP BRCH=0 must be doing something other than just PC=SO.
But even by using all variables and states at that opcode, I can find no way to make it jump where we want, $1c -> $c1. It's possible it jumps somewhere else first that then reads from the table to find out where to jump though. Doesn't look like the $96 it reads from ROM is right, that code there looks like line noise ... lots of useless, impossible to hit branch checks.
As for the data ROM itself, $000-0ff (as 16-bit words) is a DIV table.
Formula: value = 32767/offset (thanks Jonas Quinn)
So A=$da, rp=A, ro=32767/$da or 218. 32767/218=150, or $96.
I can't possibly imagine why the hell the game would perform a constant division here.
2011-01-10 - bsnes_v073r06.tar.bz2
Okay, I need help with Hayazashi Nidan Morita Shougi (J).
Above WIP will automatically map in the ST-001x chips, no need for an XML file.
F1 Race of Champions II (J) is fully playable, at least. It's forced to 15MHz like the ST-0011 for now.
The core (snes/chip/necdsp/core) is somewhat unstable at the moment, some debugging hooks commented out and some hacks / ideas floating around in there. Disassembler can't handle long jumps yet.
Code:
a1728c31df22b93e4bdae73718ba27a2 st0010.bin
682241e1370c957af676332630177f71 st0011.bin
a74594aff68fab966842414e199ac501 st0010-program.bin
5a604bb9a25e647a80d23d36520dd442 st0010-data.bin
370c36279a8510ad89965ae719366056 st0011-program.bin
de8971c1b85b9f58364cfc02d7d1b1e4 st0011-data.bin
Code:
55c697e864562445621cdf8a7bf6e84ae91361e393d382a3704e9aa55559041e st0010.bin
448e0deb0f580833ea878f4894a56124da18453d2d78e821388b6545909ba00a st0011.bin
2011-01-08 - bsnesv073r04r.tar.bz2
Yeah, see? I repatched the upd7725 standalone module, and now it works just fine. F1 ROC II is fully playable now. The fuck is going on? ;;
2011-01-08 - bsnes_v073r05.tar.bz2
Added uPD96050 emulation, but it's not working right now. I'm totally stumped.
The ST-0010 player cars aren't moving right, and it crashes sometimes on exit like it's going out of bounds.
I had decided to try and avoid duplicating the 20KB uPD7725 core, so I made a new folder:
snes/chip/necdsp
snes/chip/necdsp/upd7725
snes/chip/necdsp/upd96050
The latter two derive from the former, and they specify the PC, RP and DP sizes, which allocates appropriate memory.
I use simple runtime-masked registers (to avoid template hell on every uPDcore function), and then I derive from that to complete each actual DSP. The uPD7725 seems to work great, but the uPD96050 is fucked and I don't know why :(
Help would be appreciated, it must be something simple because I am certain the cars were working before.
Kinda wish I didn't scrap the old code now :(
I kept wip04 up, I'm going to try repeating my earlier changes with a separate core and see if I can get it working again.
Okay, this WIP will do this for you automatically, but you can also use this XML:
Code:
<?xml version='1.0' encoding='UTF-8'?>
The st0010.bin file is here: st0010.bin
And obviously, you can only use this with F1 ROC II, probably any region.
I'll hook up saving/loading the RAM when we get the chip working again.
Damnit, so close too. I wanted to post about this tonight :(
2011-01-08 - bsnes_v073r04.tar.bz2
No uPD96050 emulation here just yet, be patient ;)
Just something I wanted to do first ... I've merged the bgameboy GUI into the bsnes project, as it's only ~3KB and it means I don't have to keep manually editing and copying two projects around. You can set ui := ui-gameboy to build bgameboy as a standalone, and ui := ui to build the bsnes you are used to. I will be polishing it to allow changing the binary output name, not building the SNES portions when not needed, etc in time.
So that'll end bgameboy standalone releases, at least for now. If it ever gets important enough to split back out again I can, but I prefer it this way. bgameboy was never meant to be mainstream anyway, just a component for bsnes.
2011-01-07 - bsnes_v073r03.tar.bz2
Changelog:
much tighter SGB integration, but this is still a work-in-progress
--- memory::gb(rom,ram,rtc) is gone, uses GameBoy:: memory structures directly (a big gain, no need to copy memory to save and load)
--- UI-based cartridge loading works with GameBoy:: directly as well - libsnes will need to be updated internally to reflect this
--- games can save and load (even before bgameboy can, hah)
--- save states hooked up, but they crash the DMG. I don't know why, as if it was hard enough saving states with libco, try doing it for an emulator inside an emulator >_<
last remnants of old SGB stuff removed, XML converted to
looks like the XML list idea is looking pretty useless for SNES::Cartridge now that bgameboy handles its own XML mapping
Makefile removes -Isnes, all files adjusted from to <snes/name.hpp> [relic from asnes split]
You can now play Super Game Boy games with the core bsnes library.
Remarkably, bsnes/gameboy compresses to a mere 15KB, so the source archive has barely grown at all.
Similar results for the binary, it's maybe 100KB bigger at best.
I don't know why the fuck libgambatte was producing 5MB DLLs on Windows 64-bit (I removed the filters), probably a bug in MinGW.
So that we can also find results with the github search and do not have to search on another site. Source: https://gitlab.com/higan/bsnes-history-kit/-/blob/master/sources/tukuyomi/misc/bsnes_changelog.txt
2011-12-31 - bsnes_v084r08.tar.bz2 (Windows binary included.) Okay, everything can now load XML again, including board layouts for all three systems. New is the ability to load external Game Boy layouts (not really that useful, but it's there.) I'd like to aim for a v085 release soon. I've included a binary, so I'd appreciate testing. I had to redo all of the XML mappings for every system (I like consistency), so basically the following things need to be tested:
2011-12-30 - bsnes_v084r07.tar.bz2 Added the new super-fast XML parser. So far, the shaders, cheat files, and cheat database have been updated to allow XML mode once again. Which is sure to please Screwtape =) So it's down to just the cartridge mapping files now, which are always a major pain. I still think BML is better for parsing simplicity, memory usage, disk size, lack of red tape and speed (but horrendously bad for ease of creating files manually), but since the base API is identical, there's no reason not to support both. Especially since the pixel shaders have kind of taken on a life of their own.
2011-12-26 - bsnes_v084r06.tar.bz2 Changelog:
2011-12-17 - bsnes_v084r05.tar.bz2 Spent a good two hours trying things to no avail. I was trying to allow the CPU to run ahead, and sync on accesses to $4016/4017/4201/4213, but that doesn't work because the controllers have access to strobe IObit at will. The codebase is really starting to get difficult to work with. I am guessing because the days of massive development are long over, and the code is starting to age. Jonas' fix works 98% of the time, but there's still a few missed shots here and there. So that's not going to work either. So ... I give up. I've disabled the speed hack, so that it works 100% of the time. Did the same for the Super Scope: it may not have the same problem, but I like consistency and don't feel like taking the chance. This doesn't affect the mouse, since the mouse does not latch the counters to indicate its X/Y position. Speed hit is 92->82fps (accuracy profile), but only for Super Scope and Justifier games. But ... at least it works now. Slow and working is better than fast and broken. I appreciate the help in researching the issue, Jonas and krom. Also pulled in phoenix/Makefile, which simplifies ui/Makefile. Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on Debian.
2011-12-11 - bsnes_v084r04.tar.bz2 Fixed the Ys 5 input bug in the auto joypad polling code. Can't guarantee it's hardware-accurate (I have no way to extensively test it), but I can guarantee it is closer to being correct now. Also uses updated version of phoenix. The justifier input is indeed all fucked up now. Seems like it stops updating input after firing for a few frames. I really don't want to debug that code anymore ... anyone want to make $10 by fixing it? :P
2011-12-03 - bsnes_v084r03.tar.bz2 snesfilter_20111202.tar.bz2 Internally, all color is processed with 30-bit precision. The filters also operate at 30-bit depth. There's a new config file setting, video.depth, which defaults to 24. This causes the final output to downsample to 24-bit, as most will require. If you set it to 30-bit, the downsampling will not occur, and bsnes will ask ruby for a 30-bit surface. If you don't have one available, you're going to get bad colors. Or maybe even a crash with OpenGL. I don't yet have detection code to make sure you have an appropriate visual in place. 30-bit mode will really only work if you are running Linux, running Xorg at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD FireGL card with the official drivers, and have a 30-bit capable monitor. Lots of planning and work for very little gain here, but it's nice that it's finally finished. Oh, I had to change the contrast/brightness formulas a tiny bit, but they still work and look nice.
2011-11-16 - bsnes_v084r01.tar.bz2 I rewrote the S-SMP processor core (implementation of the 256 opcodes), utilizing my new 6502-like syntax. It matches what bass v05r01 uses. Took 10 hours. Due to being able to group the "mov reg,mem" opcodes together with "adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from 55.7KB to 42.5KB for identical accuracy and speed. I also dropped the trick I was using to pass register variables as template arguments, and instead just use a switch table to pass them as function arguments. Makes the table a lot easier to read. Passes all of my S-SMP tests, and all of blargg's arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't test further. This does have the potential to cause some regressions if I've messed anything up, and none of the above tests caught it, so as always, testing would be appreciated. Anyway, yeah. By writing the actual processor with this new mnemonic set, it confirms the parallels I've made. My guess is that Sony really did clone the 6502, but was worried about legal implications or something and changed the mnemonics last-minute. (Note to self: need to re-enable snes.random before v085 official.)
2011-11-07 - bsnes_v084-source.tar.bz2 This release adds preliminary Game Boy Color emulation. Due to lack of technical information, this is undoubtedly the least stable module I provide at this time; but improvements should continue as it is developed. This release also polishes the NES emulation and user interface code. Changelog: added preliminary Game Boy Color emulation NES: added MMC6, VRC1, VRC2, VRC3 emulation NES: fixed MMC5 banking and added split-screen support [Cydrak] NES: pass all of blargg's ppu_vbl_nmi tests, pass more sprite tests NES: palette is now generated algorithmically [Bisqwit] SNES: fixed SA-1 IRQ regression caused by code refactoring Game Boy: rewrote audio channel mixing code; sound output is greatly improved as a result Game Boy: uses DMG boot ROM instead of SGB boot ROM Game Boy: fixed potential bug when loading save states phoenix: fixed ListView focus issue [X-Fi6] phoenix: fixed dialog message parsing [X-Fi6] ui: video output is truly 24-bit now; SNES luma=0 edge case emulated ui: audio frequency, latency, resampler are now user configurable ui: gamma ramp is dynamically adjustable ui: all filters ported to 24-bit mode (speed hit to HQ2x) ui: added turbo button mappings for all generic controllers ui: fixed audio volume on unmute via menu [Ver Greeneyes] ui: shrink window option does nothing when no cartridge is loaded ui: re-added compositor disable, driver verification from v082
2011-11-03 - bsnes_v083r10.tar.bz2 Changelog:
2011-10-31 - bsnes_v083r09.tar.bz2 Specifically asked not to be bugged about L/R turbo, sigh :( Added frequency, latency, resampler selection to the audio settings panel (I really only wanted it there for resampler selection ... having three options matches the driver selection style though, so whatever.) The linear/hermite sampler will double the framerate when running Game Boy games, and sounds the same. Same framerate and sound quality on SNES. But it will cause buzzing in many NES titles. Also re-added the composition { never, fullscreen, always } modes. I think that option is clutter, but it's just impossible to get good audio+video on Windows 7 without it ... Lastly, HQ2x was ported over, but not very well. I just convert source pixels from RGB888 to RGB555, and output pixels in the opposite direction. Need someone good to port the diff() and blend functions over to RGB888 in a way that's not terribly slow.
2011-10-29 - bsnes_v083r08.tar.bz2 Fixed SA-1 IRQ regression for Super Mario RPG Added turbo B,A to NES+GB; B,A,X,Y to SNES (please don't ask for turbo L,R; you never use those keys rapidly.) Re-added video color adjustments, which are now done in full 8-bit colorspace for more precision Gamma ramp option is gone. It's now the gamma option, which now only affects the lower-half of the colors. A value of 1.0 gives you the original, washed out colors. 1.75 is what the gamma ramp checkbox used to do (roughly). The new default is 1.5, which still prevents color washout, but isn't as overly dark as before. I wanted to make the core/interface stuff abstract the complexity of setting up a new C++ class, but it really didn't make anything easier. It was all one-line stubs to internal functions, and there was just too many platform-specific things that needed to be captured, so I did away with that. Made a base class for the ui/interface stuff to get rid of a lot of switch(mode()) stuff, still a work in progress.
2011-10-28 - bsnes_v083r07.tar.bz2 Game Boy: audio should sound a lot better, eg Zelda: DX first opening scene Game Boy Color: now uses cothread Processor::frequency to dynamically clock GB-CPU to 8MHz. Proper OAM DMA and timer speed. Fixes SMT: DC - WB audio. Added the break; statements to phoenix/windows/platform message loop Added audio latency/frequency to config file only
2011-10-27 - bsnes_v083r06.tar.bz2 All cores: Video classes have internal->{RGB30,24,16,15} palette generation support All cores: video output is now RGB24, all filters except HQ2x were updated to reflect this (HQ2x will be very hard) NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF) [Cydrak] NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak] Game Boy + Game Boy Color: fixed a potential freezing bug when loading save states (re-create cothreads on state load; was implied when using SGB mode.) Game Boy Color: fixed freezing bug with Zelda: DX opening (SVBK is readable.) SNES: luminance of zero is no longer pure black, as on real hardware. This is possible thanks to using RGB888 output now.
2011-10-25 - bsnes_v083r05.tar.bz2 NES: passes ppu_sprite_overflow tests 01, 02, 05. Game Boy: uses DMG BIOS (the one with the slow title scroll) or SGB BIOS, based upon how you load the game Game Boy Color: http://byuu.org/images/bsnes_20111025a.png http://byuu.org/images/bsnes_20111025b.png http://byuu.org/images/bsnes_20111025c.png http://byuu.org/images/bsnes_20111025d.png Everything except the IR port is emulated. I don't have any plans to allow linking two instances of bsnes. And that's frankly never going to happen over netplay anyway, due to latency requirements of the serial/IR ports. The new DMA stuff is possibly incorrect, my test games don't seem to use it. Zelda: DX usually resets or crashes on the intro right before the beach scene. I'm not sure why. Skip the intro and the game plays fine. This is the best I can do when the most up-to-date GB/C reference document is over ten years old and half-assed (pandocs.) I could really use some help from anyone who understands the system. Probably the worst part of my emulation at the moment is the interrupt system. Lots of things real hardware doesn't allow (DMA outside HRAM, CGB DMA to invalid addresses, etc) isn't blocked yet. LCD renderer is still scanline-based, which is just terrible. Doesn't seem to be any good docs on cycle-level operation. I only know that it's incredibly pathological and variable.
2011-10-24 - bsnes_v083r03.tar.bz2 Lots of phoenix issues fixed, especially for Windows and GTK+. NES emulation passes all ten ppu_vbl_nmi tests from blargg. Sprite timing is nowhere near accurate yet (always consumes four clocks per sprite), but oh well.
2011-10-17 - bsnes_v083r02.tar.bz2 It seems impossible to pass blargg's NES ppu_vbl_nmi test 03 and 07 at the same time. Wrote up a description of the problem here: http://nesdev.parodius.com/bbs/viewtopi ... 5156#85156
2011-10-16 - bsnes_v083r01.tar.bz2 This adds Bisqwit's NES palette generation code: http://nesdev.parodius.com/bbs/viewtopi ... 5060#85060 I set the saturation to 2.0 to closer match the existing "bright" palette, although it still has a greater contrast range (some colors are darker.) The gamma ramp option works now. Like SNES, best to also set gamma to 0.8 afterward. Once I think of a good way to expose the saturation/hue settings, I'll do so. I've also merged in the updated nall. Adds Cygwin uname check, and replaces linear_vector with vector in lstring and the GUI.
2011-10-14 - bsnes_v083-source.tar.bz2 This release adds preliminary Nintendo / Famicom emulation. It's only a week or two old, so a lot of work still needs to be done before it can compete with the most popular NES emulators. It's important to clarify: bsnes is primarily an SNES emulator. That will always be its forte and my core focus. I have added Game Boy support previously for Super Game Boy emulation, and I've added NES support mostly for something fun to work on to break up the monotony of working on one system for seven years now. Obviously, I'd like the emulation to be accurate and highly compatible, but I simply cannot afford to invest the same amount of time and money into any other systems. Still, either way the NES and GB emulation serve as fun side-diversions, and allow for a unified emulator interface with all of bsnes' unique features applied to all systems. My personal favorite feature is mightymo's extended built-in cheat code database that now also includes NES and Game Boy codes. And it even works in Super Game Boy mode now, too! I'm also not worried about speed at all: so long as NES/GB are faster than SNES/compatibility, it's fine by me. Note that due to the NES audio running at 1.78MHz, and Game Boy audio at 4MHz stereo, a more sophisticated audio resampler was needed: Ryphecha (Mednafen author) has graciously written a first-rate resampler: it is a band-limited Kaiser-windowed polyphase sinc resampler. It is combined with two highpass filters to remove DC bias. The filter itself is SSE optimized, but even still, approximately 50% of CPU usage for NES/GB emulation goes to the audio filtering alone. However, you now have the best sound possible for NES and Game Boy emulation as a result. The GUI has also been heavily re-structured to accommodate multiple emulators from the same interface. As such, it's quite likely a few bugs are still lurking here and there. Please report them and I'll iron them out for the next release. Changelog:
2011-10-11 - bsnes_v082r34.tar.bz2 (source only) Added MMC2, MMC4, VRC4, VRC7 (no audio.) Split NES audio code up into individual modules. Fixed libsnes to compile: Themaister, can you please test to make sure it works? I don't have a libsnes client on my work PC to test it. Added about / license information to bottom of advanced settings screen for now (better than nothing, I guess.) Blocked PPU reads/writes while rendering for now, easier than coming up with a bus address locking thing :/ I can't seem to fix MMC5 graphics during the intro to Uchuu Keibitai. Without that, trying to implement vertical-split screen mode doesn't make sense. So as far as special audio chips go ...
2011-10-07 - bsnes_v082r32.tar.bz2 (source only) Added delay to MMC1 register writes, to fix Bill & Ted's Godawful Adventure. Fixed up MMC5 RAM+fill mode, and added EXRAM mode support (8x8 tiles/attributes.) Just Breed is fully playable now. MMC5 is a total pain in the ass, the documentation on it is just terrible. I basically just tried seven hundred variations until something worked. I still need to add MMC5 vertical split screen (for one single game's attract screen, ugh), and the extra sound channels. Would like to rework the NES APU first. Since the pulse channels are identical sans sweep, it'd be nice to just inherit those and mask out the sweep register bit writes. So that probably won't make it into the first release, at least. Still, overall I think it'll be an impressive showing of complex mappers for a first release: MMC3, MMC5, VRC6 and 5B. The latter two with full audio. The only other really, really hard bit is the VRC7 audio, supposedly.
2011-10-05 - bsnes_v082r31.tar.bz2 (source only) Enable Overscan->Mask Overscan [best I'm doing] Video settings -> Overscan mask: (horizontal, vertical: 0-16 on each side) [only works on NES+SNES] BPS patching works for NES+SNES+GB; note that long-term I want BPS to only patch headerless PRG+CHR files, but we'll need a database / completed board mapping system first. MMC1 splits the board/chip markups a bit better. My attempts to emulate the extra CHR bits per hardware fail repeatedly. Docs do not explain how it works at all. Emulated enough of the MMC5 to play Castlevania 3. The MMC5 is easily the most complicated mapper the NES has to offer, and of course, has the most pitifully vague and difficult documentation of any mapper around. It seems the only way anyone is able to emulate this chip is empirically. Everyone else apparently hooks the MMC5 right into the PPU core, which I of course cannot do. So I had to come up with my own (probably wrong) way to synchronize the PPU simply by observing CHR bus accesses. I must say, I over-estimated how well fleshed out the NES hardware documentation was. Shit hits the fan right after MMC3. It's miles beyond the GB scene, but I find myself wanting for someone with the technical writing ability of anomie. I can't find anything at all on how we're supposed to support the $2007 port reads/writes without it extra-clocking the PPU's bus, which could throw off mapper timing. Absolutely nothing at all on the subject anywhere, something everybody is required to do for all cycle-based emulators and ... nada. Anyway, I'd like to refine the MMC5 a bit, getting Just Breed playable even without sound would be really nice (it's a fun game.) Then we need to get libsnes building again (ugh, getting worn out in backporting changes to it.) Once v083 is public, we can start discussing a new API for multiple emulators.
2011-10-04 - bsnes_v082r30.tar.bz2 (source only) cheats.xml -> cheats.bml, includes NES+SNES+GB codes now. Absolutely awesome, thanks to mightymo and tukuyomi. I also added Sunsoft-FME7/5B (with sound) emulation. Really only useful for playing the Japanese release of Gimmick! Fun game, but balls to the wall hard. Been a while since a WIP-release thread made it into the 30s. Anyway, you guys can probably guess when I'm hoping to release. So ... test accordingly please =)
2011-10-03 - bsnes_v082r29.tar.bz2 (source only) I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-01 - bsnes_v082r28.tar.bz2 (source only) Was mostly working on BML. Still working on the spec. Added NES-BNROM, NES-GNROM/NES-MHROM boards. I don't even know why. The latter games do not work very well without Zapper support.
2011-09-30 - bsnes_v082r27.tar.bz2 (source only) Finished porting over all mappers to board/chip disambiguations. Had to nearly rewrite the MMC1 code to do it, but all variants should be supported. iNES1 is too stupid to express them all, so you'll need a board markup if you want to play the >8KB PRG RAM games. For whatever reason, they call VRC6's memory WRAM, and MMC1's PRG RAM. I am calling them all PRG RAM, since it's the same damn thing. Board spec is not going to be stable until I have a hell of a lot more mappers implemented, so be wary of that. Anyway, at this time, all games can be loaded sans iNES header, if you have the board markup. I'd also like to have a board database for all commercial titles. I'm treating *.fc as PRG-ROM(+CHR-ROM). Will work on loading the split files later possibly.
2011-09-28 - bsnes_v082r25.tar.bz2 (source only) Ryphecha fixed Gun Nac, it was some sort of problem with blank sprite address fetching messing with the MMC3 I've started on an XML parser for iNES-free loading, but it's pretty barebones right now. Only NROM-256 loads, and you have to make it a compile-time thing (so other games work for now.) Updated nall with nullptr stuff. nall/detect is now nall/intrinsic and has both #defines + static constants that can be used to detect the platform (allows for run-time platform checks where practical.) ruby has a Makefile now, that makes using it in other projects a lot easier I need to rework my XML parser, it's not really all that suitable for this, and NES is going to need probably 50x the XML parsing code of the SNES. I want to be able to quickly test if a required element exists or not, and grab its data. I also want to design it around start/end offset pairs, so that there's not so much malloc overhead.
2011-09-27 - bsnes_v082r24.tar.bz2 (source + Windows 64-bit binary) Upgraded to GCC 4.6.1. Removed nall/foreach and nall/concept, upgraded iterator support on all of my containers, and replaced everything with range-for. Fixed up Qt geometry a good bit, should at least create windows now without bouncing around. Added some initial nullptr / constexpr changes. Some other minor cleanups ... removing foreach() took about 6-8 hours alone. Turns out GCC has a 0bNNN extension for binary. I'm not big on being locked to specific compilers, but the syntax is so much more elegant than binary("100101010"); so we will see.
2011-09-26 - bsnes_v082r23.tar.bz2 (source only) Ryphecha fixed the FF1 glitch, added two highpass filters to NES audio output (still working on a lowpass), and fixed VRC6 audio issues. I reduced the complexity of all eight supported mapping modes, and standardized them; and added in an overscan filter (not in archive) for chopping off all the NES edge garbage (8 pixels on the left and right, 16 on the top and bottom.) It's extreme, but anything less shows junk. I may make this part of the menu option, just clip
2011-09-25 - bsnes_v082r22.tar.bz2 (source only) Mappers are now optionally threaded. Fixed up MMC3 emulation, SMB3 and MM3-6 are all fully playable. However, many unusual variants of this chip are not supported still. Added UNROM+UOROM for Contra and MM1, allowing all six MM games to play now. Added VRC6 with sound emulation, because I wanted to get audio mixing in place. Chose VRC6 because it has Esper Dream 2, which is an absolutely amazing game that everyone should play :D The game didn't use sawtooth, and I didn't test any other VRC6 games, so hopefully that is emulated passably well enough. Anyway, I think we have enough of the mappers down now to start thinking about a stable API for them. iNES is basically right out, I have no intention of the core emulator supporting it. We can write an iNES->XML translator for compatibility from the UI, but the core is going to want cleaner information. It's really just a question of how low-level we want to get: describe only what is NEEDED for known configurations, or allow for more flexibility? A) VRC6 would have an attribute like "swap_address_lines=true/false" to swap A0/A1 wiring, as ED2 needs but AD does not. B) we would specify how the pins were connected: "A0->A1, A1->A0, A12-15->A2-5"
bsnes_v082r21.tar.bz2 (source only) 2-6% speed hit in SNES core for outputting 19-bit (rounded to 32-bit ... sigh) video, so that luma non-linearity can eventually be emulated properly. Now using sinc audio resampler, massive speed hit of course to NES+GB only, but it's required to get rid of aliasing (buzzing) present in many, many games otherwise. Fixed fast forward and none/blur select. Finally fixed texture clearing for changing pixel shaders and video filters. Some realllly basic NES MMC3, extremely broken so don't bug me about it. Other stuff, probably.
2011-09-23 - bsnes_v082r20.tar.bz2 (source only) NES now has save state support. NES A/B buttons were indeed swapped, so that's fixed now. nall/dsp now puts resamplers into separate classes, so that each can have their own state information. opengl.hpp uses GL_RGBA internal format and doesn't regenerate textures on resize. No speedup, no fix to junk on resize, so I will be very unhappy if this breaks things for anyone. GLSL shaders use as you guys wanted.
ui-snes was removed.
2011-09-21 - bsnes_v082r19.tar.bz2 (source only) This will be the last release with the ui-snes folder (it's broken now anyway.) Re-added cheat code database searching + add window. It hashes NES+SNES+GB images now and will look them up in the database. Re-added filter support, all filters now output at RGB555. Stacking is possible, but I don't currently allow it. Removed mouse capture + test options from tools menu. Removed smooth video output from settings menu. There are now two built-in "shaders": "None" (point filtering) and "Blur" (linear filtering). OpenGL shaders can now use (or "linear") to specify their filtering mode.
Individual emulator versions are gone, and names are hidden from the GUI: you just see bsnes v082.19 now. A new release bumps all core versions.
I cannot for the life of me get the video to clear properly when toggling the shaders. Say you set pixellate2x filter, then turn on curvature shader, then turn off the filter, you get junk at the bottom right.
I have tried clearing and flipping the OpenGL surface 64x in a row ... I don't know where the hell it's getting the data from. If anyone can make a small patch to fix that, I'd greatly appreciate it.
2011-09-20 - bsnes_v082r18.tar.bz2 (source only) There we go, the GUI is nearly feature-complete once again. All cores now output their native video format (NES={emphasis}{palette}, SNES=BGR555, GameBoy={ bright, normal, darker, darkest }), and are transformed to RGB555 data that is passed to the video renderer. The video renderer then uses its internal palette to apply brightness/contrast/gamma/ramp adjustments and outputs in RGB888 color space. This does add in another rendering pass, unfortunately, but it's a necessary one for universal support. The plan is to adapt all filters to take RGB555 input, and output RGB555 data as well. By doing this, it will be possible to stack filters. However, it's a bit complicated: I need to plan how the stacking should occur (eg we never want to apply scanlines before HQ2x, etc.) Added input frequency adjustments for all three systems. I can easily get perfect video/audio sync on all three now, hooray. Long-term, it seems like we only really need one, and we can do a video/audio delta to get an adjusted value. But for now, this gets the job done. Added audio volume adjust. I left out the balance for now, since it's obviously impossible to balance the NES' single channel audio (I can duplicate the channel, and do twice the filtering work, but ... why?) I replaced NTSC/PAL TV mode selection with an "Enable Overscan" checkbox. On, you get 240 lines on NES+SNES. Off, you get 224 lines on NES+SNES. Also added aspect correction box back. I don't do that gross PAL distortion shit anymore, sorry PAL people. I just scale up the 54/47*(240/224) aspect correction for overscan off mode. All memory is loaded and saved now, for all three systems (hooray, now you can actually play Zelda 1&2.) Added all of the old bsnes hotkeys, with the exception of capture screenshot. May add again later. May come up with something a bit different for extra features. Re-added the NSS DIP switch setting window. Since geometry is saved, I didn't want to auto-hide rows, so now you'll see all eight possible DIPs, and the ones not used are grayed out. Ultimately, nobody will notice since we only have DIPs for ActRaiser NSS, and nobody's probably even using the XML file for that anyway. Whatever, it's nice to have anyway. Took FitzRoy's advice and single-item combo boxes on the input selection are disabled, so the user doesn't waste time checking them. I wanted to leave text so that you know there's not a problem. Qt disabled radio box items look almost exactly like enabled ones. Fixed lots of issues in phoenix and extended it a bit. But I was still having trouble with radio box grouping, so I said fuck it and made the panels show/hide based instead of append/remove based. That's all for stuff off the checklist, I did a bunch of other things I don't recall. So yeah, I'd say the GUI is 100% usable now. This is my opinion on how multi-platform GUIs should be done =) Oh, I figure I should mention, but the NES core is GPLv3, and all future SNES+GB releases will be as well. It's a move against Microsoft's Metro store.
2011-09-19 - bsnes_v082r17.tar.bz2 (source only) Adds BS-X/Slotted/SufamiTurbo/SGB cartridge loading. Calling it Satellaview as I'm more partial to that at the moment. FileBrowser now remembers your folders per filter type like before, and will keep your place in the list if you don't switch away. I wanted there to be ONE slot loader, so the loader will show a grayed out secondary slot on non-ST loading, but it's more consistent to only have one window instead of two for geometry placement. Removed help menu. Will try and work it in somewhere unobtrusive later on I suppose. Added timed messages and the usual "no cart loaded / paused" messages and such. Multi-cart loading stuff took ENTIRELY too long.
2011-09-18 - bsnes_v082r16.tar.bz2 (source only) Binary output is once again called bsnes. No versioning on the title without a system cartridge loaded. Still saving config files to .config/batch for now. Finally fixed NES APU frame IRQ clearing on $4015 reads. Added mouse button/axis binding through buttons on the input capture window. Added advanced settings window with driver selection and focus policy settings. Will show your default driver properly if none are selected now, unlike old bsnes. That exposed a small bug where phoenix isn't removing widgets on Layout::remove, worked around it for now by hiding the panels. Damn, sick of working on phoenix. Added all missing input controllers, which can all now be mapped, and bound them to the main menu, and added NES support for selecting "no connected controller." Added mouse capture and the requisite tools menu option for it. Added WindowManager class that keeps track of both position and size now (eg full geometry), so now you can resize your windows and save the settings, unlike old bsnes. WindowManager has more stringent geometry checks. The client area (not the window border) can't be below 0,0 or above the width/height of three 30" monitors. If you have 4+ 30" monitors, then fuck you :P settings.cfg is now also saved, captures all currently available settings. Right now, there's only one path for the file browser to remember. I will probably make this per-system later. FileBrowser has been made a bit more friendly. The bottom left tells you what type of files the list is filtered by (so you see "*.sfc" for SNES), and the bottom right has an open button that can enter folders or load files. Added video shader support. Fixed nall/dsp variadic-channel support, was only outputting the left channel. Things left to do: Add multi-cart loading { BSX, BSX slotted, ST, SGB } Add video filter support (very tricky, only SNES output 16-bit video for them.) Add video color adjustment support (same problem as above.) Add audio input frequency adjustments, volume adjustments, and balancing adjustments. Add video aspect correction and NTSC/PAL TV selection. Add preferred region selection (needed for NES (W) games, SGB BIOS.) [NES still needs to emulate PAL, period.] Add SNES expansion port device selection { BSX, None } Save and load emulated system memory (SRAM files, etc.) Add smart status bar text for main window (show messages on events, advise when paused, etc.) Add a whole lot more hotkeys (pause, state load/save, etc.) Add a proper about window. Tempted to just drop the whole about window entirely. A whole Help menu for one vanity item is pretty stupid. Add NSS DIP switch window (ugh.)
2011-09-17 - bsnes_v082r15.tar.bz2 (source only) 7.5 hours of power coding. Das Keyboard definitely helped (but didn't eliminate) RSI, neato. Okay, the NES resampler was using 315 / 88.8 by mistake, so the output rate was wrong, causing way more video/audio stuttering than necessary. STILL forgot the NES APU frame IRQ clear thing on $4015 reads, blah. Why do I always remember things right after uploading the WIPs? Recreated the input manager with a new design, works much nicer than the old one, a whole lot less duplicated code. Recreated the input settings window to work with the new multi-system emulation. All input settings are saved to their own configuration file, input.cfg. Going to batch folder for now. Okay, so the new input settings window ... basically there are now three drop-downs, and I'm not even trying to label them anymore. They are primary, secondary, tertiary selectors for the listed group below. Examples: "NES -> Controller Port 1 -> Gamepad" "SNES -> Controller Port 2 -> Super Scope" "User Interface -> Hotkeys -> Save States" I am aware that "Clear" gets disabled when assigning. I will work on that later, being lazy for now and disabling the entire window. Have to add the mouse binders back, too. Escape and modifiers are both mappable as individual keys now. If you want to clear, click the damn clear button :P Oh, and all input goes to all windows for now. That'll be fixed too when input focus stuff is re-added.
2011-09-16 - bsnes_v082r14.tar.bz2 (source only) Emulates DMC channel (sound effect when Link gets hit in Zelda 1, for instance), fixes up bugs in rectangle/sweep and triangle channels, adds DMC/frame APU IRQs, adds proper stalling for DMC ROM reads (should even be cycle accurate, but has one extra cycle when triggered during OAM DMA, I think), but forgets the frame IRQ acknowledge clear on $4015 read (will fix next WIP.) All sound courtesy of Ryphecha. Made template configuration settings window (empty for now.) Simplified SNES cheat.cpp code. Some other stuff. Further developed RSI.
2011-09-15 - bsnes_v082r13.tar.bz2 (source only) I've updated the {System}::Interface classes to encapsulate all common functionality, so they are C++ equivalents of libsnes now. The idea being, use the interface class and you'll never have to reach into core objects (unless you really want to.) Not guaranteeing as stable an API as I do with libsnes for that, though. C++ doesn't make for nice dynamic libraries, anyway. Added back the state manager, and it now works for both SNES and Game Boy. NES save states aren't in yet. Anyway, this should give you a pretty good feel for what the combined UI is going to be like: same as before, everything works the same. Only difference is the dynamic system menu and cartridge menu with more load options. The settings window will be mostly the same as well, but will obviously have options that only apply to some systems.
2011-09-14 - bsnes_v082r12.tar.bz2 (source only) Merged Ryphecha's APU emulation, so NES has sound output now. We are still missing the DMC memory fetch, so there will be missing sound effects here and there.
2011-09-14 - bsnes_v082r11.tar.bz2 (source only) Emulates grayscale and color emphasis modes, improves sprite timing and PPU bus fetching behavior with the PPU disabled.
2011-09-14 - bsnes_v082r10.tar.bz2 (source only) Emulated the Game Genie for the NES and Game Boy, and wrote a new cheat editor that doesn't reach into specific emulation cores so that it would work. Before you ask: yes, long-term I'd like Super Game Boy mode to accept Game Boy codes. But that's not high on the priority list. Renamed the mappers toward board names, LZ...->BandaiFCG, LS161...->AOROM, added CNROM emulation (Adventure Island, Gradius, etc.) Added the tools menu load/save state stuff, but note that the NES doesn't have save state support yet (waiting for the interface to stabilize a bit more first.) Note: this will be the last release to have the ui-gameboy folder, it's been deleted locally from my end, as the new multi-GUI does all that it does and more now.
2011-09-12 - bsnes_v082r09.tar.bz2 Skip this build if you can, it's CPU+PPU timing improvements that should not visibly affect anything. Cheat codes and save states are going to work 100% the same between every system. I'll leave the database for NES/GB up to mightymo, if he is interested. They can even be in the same cheats.xml file, it doesn't really matter. That's why XML is so nice, it can store any form of cheat code for any system, no problem.
2011-09-10 - bsnes_v082r07.tar.bz2 (source only) Wrote a cycle-based PPU renderer, ~95% hardware accurate for BGs, not so much for sprites yet. Mednafen has been helping out a lot.
2011-09-10 - bsnes_v082r06.tar.bz2 (source only) Emulated MMC1, currently defaults to B2 configuration. Fixed a whole bunch of timing things, render things, nametable mirroring things, etc. Zelda and Mega Man II are fully playable, but they have odd vertical scrolling issues that make it a not so fun experience. Not sure what the problem is there, yet. The Y scroll register writes seem to be wonky ... I don't know. Keeping the Cartridge menu always visible now, so it's faster to load carts, but I am still hiding the non-loaded system menus.
2011-09-09 - bsnes_v082r05.tar.bz2 (source + Windows binary) Okay, I fixed up many outstanding phoenix issues.
2011-09-03 - bsnes_v082r02.tar.bz2 (source only) Has Jonas Quinn's many Game Boy APU fixes, and two more from blargg's notes that I added. It also has the new dynamic phoenix. So yeah, it'll crash on bsnes/Qt exit. If anyone can fix it properly and wants the money, I'll pay them $20 for the trouble =) As for auto-saving SRAM, last time I tried it was destroying the frame rate on solid state drives that would choke the whole program using synchronous writes. Even if I make it an option, which will be a bit of a hassle, most people won't know to turn it on until it's too late.
2011-08-22 - bsnes_v082r01.tar.bz2 (Windows binary + source) Changelog:
2011-08-20 - bsnes_v082 This release features many substantial Game Boy emulation improvements (all courtesy of Jonas Quinn), a new audio DSP class, and BPS patching support. Changelog:
2011-08-19 - bsnes_v081r04.tar.bz2 (source only) Changelog:
2011-08-17 - bsnes_v081r03.tar.bz2 (Windows binary + source) Changelog:
2011-08-14 - bsnes_v081r02.tar.bz2 (source only) This release adds nall/dsp, which is a new framework for audio DSP effects. It currently supports the usual fractional hermite resampling and volume adjustments from ruby; but it also adds balance, and arbitrary precision input and output (still limited to two channels, and still signed audio [just subtract 1<<(bits-1) from an unsigned value.]) Internally, all samples are converted to doubles in the range of -1.0 to +1.0, to allow for far greater precision with the hermite resampler and volume/balance/etc adjustments. As a result of this, all of the extra resampling/volume code from ruby::audio has been removed. bsnes pulls in a copy of nall::dsp to handle that stuff now. The overall framework is meant to be far more flexible in the future. I'd love to add more resampling algorithms (especially an averaging one for Game Boy emulation), and more special effects (echo, reverb, bass, treble, equalization, etc.) Thing is, I just don't know a damn thing about audio, so I'm not sure how to implement them. Would love some help here. I don't want to just plug in other peoples' libraries, I want to learn how to do these things and implement them into nall, so that I can learn about audio processing, and have my own neat little audio library. Finally fixed SNES::Interface::audio_sample to take int16_t parameters, since SNES audio is signed. libsnes stays the same for backward-compatibility.
2011-08-13 - bsnes_v081r01.tar.bz2 (source only) Changelog:
2011-08-12 - bsnes_v081-source.tar.bz2 Changelog:
2011-08-08 - bsnes_v080r08.tar.bz2 (Windows binary + source) Fixed all of the above phoenix issues, and improved the auto-disabling of buttons on the input setting and state manager windows. Also manually initiailized lastConfigure for Valgrind in GTK+. Windows and GTK+ ports look a lot nicer now.
2011-08-08 - bsnes_v080r07.tar.bz2 (Windows binary + source) Please test this one as much as you guys can, I'd like to release a new build soon. Changelog:
2011-08-07 - bsnes_v080r06.tar.bz2 (source only) Ran out of time, so this is incomplete, but ... Windows will disable the compositor in fullscreen mode, and enable it when switching back to windowed mode. Should help with Vsync issues, but of course only in fullscreen mode. I've also merged the four settings windows back into a panel with a list view (since I have no tab control widget.) The input settings window is a bit incomplete, need to break assignment on window close, hide the capture buttons on first showing, etc. Will probably try and finish that up tonight.
2011-08-06 - bsnes_v080r05.tar.bz2 (source only) Includes updated versions of nall and phoenix, which mostly improves the GTK+ version. However, it appears to be crashing at the moment after loading a game. Unfortunately it works when gdb is used, so I can't easily debug it :/ You can now build with make phoenix=gtk if you want the GTK+ version on Linux (the Qt version is leagues better even on Gnome, please use it if at all possible.) There's also settings.startFullScreen, config-file only, to allow for front-end use. Forgot to add the reset/power hotkeys. I also fixed compilation of ui-gameboy on GCC 4.6. I hope that's the last switch(enum) error, those are damn annoying. Can't wait to switch to GCC 4.6 on Windows.
2011-07-24 - bsnes_v080r04.tar.bz2 (source only) Adds nall/inflate.hpp and nall/unzip.hpp. Updates nall/resource.hpp to encode and decode using ZIP/deflate files, rather than a much simpler (and less powerful) LZSS implementation. Cuts the bsnes-logo.hpp file from 270KB to 130KB, and the binary overhead from 80KB to 35KB (better than PNG! Hah.)
2011-07-22 - bsnes_v080r03.tar.bz2 (Windows 32-bit accuracy binary included) Wow, nothing in 19 days. Anyway, I wanted to get Nick's logo back in on the about screen. Adds 80kb to both the binary and source archive, but eh. Gotta have some style. Nothing else new. Probably won't be much news until the ST-0018 ROM is extracted. ./sshots/bsnes_20110722.png Oh, and phoenix/Canvas sucks with GTK+, that'll be fixed eventually. Hopefully prior to v081.
2011-07-03 - bsnes_v080r02.tar.bz2 Changelog:
2011-06-27 - bsnes_v080r01.tar.bz2 (source only) There was one unfortunate aspect of the S-DD1 module: you had to give it the DMA length and a target buffer, and it would do the entire decompression at once. Real hardware would work by streaming the data byte by byte. So with that, I went ahead and rewrote the code to handle byte-based streaming. This WIP is an important milestone for me personally. Up until now, bsnes has always had code that was directly copy-pasted from other authors. With all of the DSP and Cx4 chips rewritten in LLE, and the SPC7110 algorithm already ported over from C, and archive decompression code removed for a long time, the S-DD1 was the only module left like this. It's obviously not that big of a deal. The code is basically still a copy of the original. S-DD1 decomp from Andreas Naive, SPC7110 decomp from neviksti, and S-DSP from blargg. And the rest of the emulator is of course only possible because of code and research before it, although everything else has no resemblance at all to code before it. The main advantage, really, is absolute code consistency. I always use the same variant of K&R, for instance. I dunno, I guess I just never really liked the "Build-a-Bear Workshop" style of emulators, like is so prominent in the Genesis scene: "My new Genesis emu (uses Starscream/Musashi 68K core, Marat Fayzullin's Z80 core, YM2612 core from Game_Music_Emu, VDP core from Gens, SVP core from picodrive)", sorry, but you wrote a front-end, not an emulator :/ I also updated the SPC7110 decompression module: I merged the class inside the SPC7110 class (not sure why it was separate before), and replaced the morton lookup tables with for-loops. The morton tables were added to be a tiny bit faster when I was more interested in speed than code clarity. It may be a tiny bit slower (or faster due to less L2 cache usage), but you won't even notice an FPS drop, and it cuts out a good chunk of code and some tables. Lastly, I added pinput_poll() to video_refresh(). Forgot to remove Interface::input_poll() from the C++ side, will have to do that later.
2011-06-26 - bsnes_v080-source.tar.bz2 This release adds low-level emulation of the Hitachi HG51B169 DSP, which was used in Mega Man X2 and Mega Man X3 as the Cx4 chip. It also fixes a regression in both the sound core and cheat engine. You will now need the HG51B169 data ROM to play MMX2/MMX3. You can get that here. I will not be including it with bsnes. Once again, Cx4 LLE could not have been possible without the help of Dr. Decapitator, Jonas Quinn, Overload and Segher. Be sure to thank them, please! Changelog:
updated to mightymo's latest cheat pack (2011-06-20)
2011-06-24 - bsnes_v079r06.tar.bz2 (source only) Added threading support: each controller port gets its own thread now. If they don't need one, then it auto-generates one running at 1hz. It does add some more code to the CPU::step() function, so performance probably went down actually, by about 1%. Removing the input.tick() call didn't compensate as much as I'd hoped. Hooked up Super Scope and Justifier support. The good news is that the Justifier alignment doesn't get fucked up anymore when you go off-screen. Never could fix that in the old version. The bad news is that it takes a major speed hit for the time being. I need to figure out how to run the CPU and input threads out of order. Every time I try, the input gets thrown off by most of a scanline. Right now, I'm forced to sync constantly to get the latching position really accurate. But worst case, I can cut the syncs down by skipping large chunks around the cursor position, +/-40 clock cycles. So it's only temporarily slow. Lastly, killed the old Input class, merged Controllers class into it. I actually like Controllers as a name better, but it doesn't jive with video/audio/input, so oh well.
2011-06-24 - bsnes_v079r05.tar.bz2 (source only) Fixed GCC-4.6 casting errors in ui/input/input.cpp. Fixed some of the opcode mnemonics specified in the HG51B169 core (was unable to speed up the code) Started on a new core input system: snes/controller. More on that here: http://board.byuu.org/viewtopic.php?f=16&t=1761 Have not yet attempted to add threading support to the controllers, so serial is still there as a coprocessor. I'm going to move the Controllers {} class back to Input {} once all individual controllers have been ported over. Note: Super Scope and Justifier do not have counter latching support yet, so you can't really use them. The gamepad, multitap and mouse all work great; and the SS/Justifier cursors work at least. I also colored the SS cursor red, so that all three (SS, Justifier, chained secondary Justifier) all have unique R/G/B colors now. Should prevent confusion between the SS and one Justifier.
2011-06-20 - bsnes_v079r04.tar.bz2 Back from vacation. We were successful in emulating the Cx4 using LLE during my vacation. We finished on June 15th. And now that I'm back, I've rewritten the code and merged it into bsnes official. With that, the very last HLE emulation code in bsnes has now been purged. I still have some more plans for bsnes v080, so I'm not going to bump the version number just yet. Plus I would like it if we could thoroughly test the new Cx4 LLE support to ensure it is bug-free. To that aim, if you have some time and would like to help test: please download bsnes v079.04 and cx4.bin. Place cx4.bin in the same folder as "Mega Man X 2 (U).sfc" and "Mega Man X 3 (U).sfc", and then do your best to play through the entire games with no cheat codes, and uncover all of the secrets that you can. If you find any bugs, or if the console window prints "invalid opcode" at any time, please send me a note on my forums. Thanks in advance to anyone who can help test this. http://bsnes.googlecode.com/files/bsnes_v079r04.tar.bz2 http://byuu.org/snes/cx4/cx4.bin
The emulation is as minimal as possible. If I don't see an opcode or feature actually used, I don't implement it. The one exception being that I do support the vector override functionality. And there are also dummy handlers for ld ?,$2e + loop, so that the chip won't stall out. But things like "byte 4" on rdram/wrram, the two-bit destination selections for all but ld, etc are treated as invalid opcodes, since we aren't 100% sure if they are there and work as we hypothesize. I also only map in known registers into the 256-entry register list. This leaves 90% of the map empty. The chip runs at 20MHz, and it will disable the ROM while running. DMA does transfer one byte at a time against the clock and also locks out the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only reads from ROM, and only writes to RAM. Unless someone verifies that they can do more, I'll leave it that way. I don't yet actually buffer the program ROM into the internal program RAM just yet, but that is on the to-do list. We aren't entirely sure how that works either, but my plan is to just lock the Cx4 CPU and load in 512-bytes. There's still a few unknown registers in $7f40-5f that I don't do anything with yet. The secondary chip disable is going to be the weirdest one, since MMX3 only has one chip. I'd really rather not have to specify the ROM mapping as two separate chips on MMX2 and as one on MMX3 just to support this, so I don't know yet. Save state support is of course there already. Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
2011-06-09 - bsnes_v079r03.tar.bz2 (source only) This fixes the S-SMP synchronization on CPUIO writes that was broken by improvements in v078.01. Terranigma will work now. Also adds the 'link' coprocessor module that was added in v079.01, and improved in v079.02.
2011-06-08 - bsnes_v079r02.tar.bz2 Added "unsigned link_run();" which acts as its own thread synchronized against the S-CPU. Specify the frequency in the configuration file. I intend to prototype the Cx4 LLE openly using the link module, and that required timing support, so there we go. It's very basic, and it synchronizes the CPU to the coprocessors and vice versa after every call to link_run(). Meaning performance won't be super exceptional at full 21MHz or higher, but then this is for prototyping only. I didn't want to expose cothreading, yielding, calls back into bsnes' core, calls to sync up the S-CPU, etc.
2011-06-06 - bsnes_v079r01.tar.bz2 This bundle includes source code, and a Windows 32-bit accuracy build with the console enabled. If you want profiling or a Linux binary, you'll have to build it yourself, sorry. Background information here. Here is an example of using the new SNES coprocessor research module. The example will use Hayazashi Nidan Morita Shougi 2 (J).sfc for ST-0018 research. XML mapping example: Code: <?xml version="1.0" encoding="UTF-8"?>
Specifically, note the section. When you use the link edition binary above, it will print out the XML mapping for any game loaded to the console. You can copy this, and then add your own link section. Save it as.xml and bsnes will use it in the future.
Verify this by looking at the console output on the next load.
You can map any address you like, but internal MMIO will be overridden internally (eg don't hijack the DMA registers.)
In other words, $00-3f|80-bf:0000-1fff,2100-2183,4016-4017,4200-421f,4300-437f and $7e-7f:0000-ffff are off-limits. Anything else is fair game.
Source code example:
Code:
if defined(_WIN32)
define dllexport __declspec(dllexport)
else
define dllexport
endif
include
include
extern "C" { void link_power(); void link_reset(); unsigned link_run(); uint8_t link_read(unsigned addr); void link_write(unsigned addr, uint8_t data); }
struct ST0018 { uint8_t r3800; uint8_t r3804; unsigned w3804; } st0018;
dllexport void link_power() { link_reset(); }
dllexport void link_reset() { st0018.r3800 = 0x00; st0018.r3804 = 0x85; st0018.w3804 = 0x000000; }
dllexport unsigned link_run() { return 21477272u; }
dllexport uint8_t link_read(unsigned addr) { printf("* Read %.6x\n", addr); addr &= 0xffff;
if(addr == 0x3800) return st0018.r3800; if(addr == 0x3804) return st0018.r3804;
return 0x00; }
dllexport void link_write(unsigned addr, uint8_t data) { printf("* Write %.6x = %.2x\n", addr, data); addr &= 0xffff;
if(addr == 0x3804) { st0018.w3804 = ((st0018.w3804 << 8) | data) & 0xffffff; } } Windows compilation example: Code: g++ -O3 -fomit-frame-pointer -I. -c st0018.cpp -o obj/st0018.o g++ -o st0018.dll -shared -Wl,--out-implib,libst0018.a obj/st0018.o Linux compilation example: Code: g++- -fPIC -O3 -fomit-frame-pointer -I. -c st0018.cpp -o obj/st0018.o g++ -s -o libst0018.so -shared -Wl,-soname,libst0018.so.1 obj/st0018.o Note that C++ is not required.
2011-06-04 - bsnes_v079-source.tar.bz2 This release includes Nintendo Super System DIP switch emulation and improved PPU rendering accuracy, among other things. Changelog:
2011-06-01 - bsnes_v078r07.tar.bz2 (Windows 32-bit accuracy binary included) ./sshots/turrican2.png Would appreciate testing on any games with mosaic, especially Mode7 mosaic. I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-05-08 - bsnes_v078r06.tar.bz2 (source only) This adds ikari_01's emulation of the ICD2 (Super Game Boy) $6001 register. It basically removes a really ugly hack where I was intercepting the DMA transfer destination address to determine while Game Boy tile row to transfer. This should make implementing SGB emulation in other emulators easier, as said hooks were very emulator-specific.
2011-05-06 - bsnes_v078r05.tar.bz2 (32-bit compatibility binary included.) This WIP adds Nintendo Super System emulation, at least of its DIP switches. ./sshots/bsnes_20110506.png This is done via XML mapping, like so: Code: <?xml version="1.0" encoding="UTF-8"?>
The value field is a 16-bit value. All selected options are ORed together to produce the final DIP switch values. The number of options per setting is unlimited, but there are only sixteen settings allowed (you can't have more settings than you have switches, that's just stupid.) In the example above, d0-d1 controls difficulty, and d2-d3 controls # of lives. d4-d15 appear to be unused, as far as I can tell. Anyway! I could use some help with this. There's basically something like 10-15 or so NSS games, so we should be able to produce XML files for every NSS game, and distribute them all as a nice pack. I can host the XML pack on my downloads page. Basically, what I'd like is for someone to go through each game and try and figure out the valid DIPs for each game. Note! that some games don't use DIP switch values at all, we can ignore those games. Also note that I have no idea why ZSNES only allows six DIPs, the DIP register is 16-bits wide and is located at $4100,$4101. It may be that d6-d15 is never used though. Not a lot of info on this out there. You will of course need non-MAME-fucked ROMs to use on bsnes ;) GoodSNES seems to use Gamename (NSS) for these. Stay away from MAME ROM sites. As far as making the XML rom/ram maps, yeah, that'll be a bit annoying for some. Bleh. snes/cartridge/cartridge.cpp has a commented out line that'll print the XML map for the game if there isn't one. You can copy that, add the nss section, and have at it. Basically, the way to figure it out is to set one bit at a time, play the game, see what changes, name the settings and options, and continue for each game. Please post any XML maps you are able to make, or advise of games you know not to have any DIP settings. Thanks in advance to anyone that can help.
2011-05-05 - bsnes_v078r04.tar.bz2 (source only) Changelog:
2011-05-04 - bsnes_v078r03.tar.bz2 (32-bit performance binary included.) I would appreciate if you guys could test games and tell me if you notice any reductions in sound quality compared to a previous performance WIP. I apparently wasted two days writing that SMP core for nothing. I had a perfectly well-written and well-tested core in bsnes v045. The old opcode.b files that were a cycle-based markup language. So I took that core, and wrote new parsers to generate both opcode-based (one switch) and cycle-based (two switch) cores. Throw in a little #define magic around CYCLE_ACCURATE, and it is compile-time toggleable. EWJ2's bug was due to not resetting the timer variables, and Bahamut Lagoon's was due to dividing timer frequencies by 3, but failing to remove the 0->1 transition phase (should have done the latter and divided by two.) Anyway, all fixed up. The good news is the opcode-based SMP core is faster than bsnes'. The bad news is that the cycle switch table approach is slower than libco, which is not surprising. libco let the SMP run ahead of the CPU without having to enter and exit switch blocks repeatedly. But anyway, that gives three options for Snes9X. Cycle+libco, cycle w/o libco, and opcode. Or all three.
2011-05-03 - bsnes_v078r02.tar.bz2 (source only) New S-SMP core is feature-complete, but still buggy. It's good enough for perfect audio in Zelda 3 and Super Mario World, but there are plenty of issues. No audio in Bahamut Lagoon, deadlock in Earthworm Jim 2, etc. With this core, bsnes/Performance runs about 3-5% faster than with the old one. That won't seem like much, because the S-SMP is the least demanding portion of the SNES. blargg's SMP core netted me a 5-8% speedup the last time I tried it, so I'm sure there's still room to speed things up. The core is opcode-based, but has dummy op_io() calls (they compile to nothing), so it is trivial to make it cycle-based if desired. I'm not convinced that is necessary, but we shall see once we get the opcode bugs ironed out. If anyone wants to help, that'd be great. Just compare the snes/smp/core opcode semantics to the snes/alt/smp/core semantics and look for typos. I have already ran synthetic tests to validate all cycle counts for every opcode (sans conditional branches not taken), and to ensure that all 256 opcodes are defined. Probably best/fastest to rig up both SMP cores and perform some sort of random execution looking for any differences.
2011-05-02 - bsnes_v078r01.tar.bz2 (source only) No point in downloading this one, no differences to two profiles, and it actually breaks the third. Started on a new SMP core for bsnes/Performance. I wanted to start clean, and only copied over the debugger+disassembler portions from the existing version. I figured that if I took the existing one and tried trimming it down, that it'd end up with too much old baggage. But so far, the opcodes are looking mostly the same anyway, only I'm using #defines and a switch table in place of the template function trickery. I have enough written now that I can run Zelda 3 at least (although it gets stuck in a loop immediately after.) No real point in comparing speed yet, because it'll definitely go down as it becomes more complete. Not feeling it so far, but we'll see how things go. There's a few areas that a new SMP can speed things up:
2011-04-30 - bsnes_v078-source.tar.bz2 Finally, a new release. I have been very busy finishing up SNES box, cartridge and PCB scanning plus cataloguing the data, however this release still has some significant improvements. Most notably would be randomization on startup. This will help match the behavior of real hardware and uninitialized memory + registers. It should help catch homebrew software that forgets to initialize things properly. Of course, I was not able to test the complete library, so it is possible that if I've randomized anything that should be constant, that this could cause a regression. You can disable this randomization for netplay or to work around any incompatibilities by editing bsnes.cfg and setting snes.random to false. The GUI also received some updates. Widget sizes are now computed based on font sizes, giving it a perfectly native look (because it is native.) I've also added a hotkey remapping screen to the input settings. Not only can you remap inputs to controllers now, but those who did not know the hotkey bindings can now quickly see which ones exist and what they are mapped to. Please enjoy. Changelog:
2011-04-27 - bsnes_v077r05.tar.bz2 (Windows 32-bit accuracy build included.) Please test this one as much as you guys can. Especially with toggling NTSC/PAL TV mode, and using various filters, and running all games that are known to be difficult to emulate. The randomization could very well cause issues in some games if I randomize anything that should be constant. I took an overly aggressive approach. We can verify it's a random issue by setting bsnes.cfg's snes.random to false and see if that fixes the issue. I want to leave snes.random enabled in v078, and I'd like to avoid any major breakage if possible. Changelog:
2011-03-24 - bsnes_v077r04.tar.bz2 (Windows binary included.) Changelog:
2011-03-23 - bsnes_v077r03.tar.bz2 (Windows binary included.) Fixed up the geometry calculation code. There is now minimumGeometry() [returns minimum size needed to display a layout, treats MaximumSize as MinimumSize], and minimumLayoutGeometry() [like minimumGeometry(), but it will return MaximumSize if a single container item has that attribute. Used mostly internally for layout sizing.] It looks great on Windows, but it looks visually off on Qt. Not exactly sure what's up there. When I make a test application, everything looks great. Going to have to clone a bsnes window that's having a problem (eg bsnes main debugger checkbox window), and see what's up. Anyway, yeah. It looks great on Windows. Please compare to v077 official and let me know what you think. I no longer have to force LineEdit and Button to equal heights, the layout code automatically Vcenters on HorizontalLayout containers (planning to make a setAlignment function later of course.) Also updated the phoenix documentation on the website to reflect new stuff.
2011-03-22 - bsnes_v077r02.tar.bz2 Wouldn't recommend using this, but it has bsnes ported to the new auto-size calculating phoenix API. Known issues:
2011-03-20 - bsnes_v077r01.tar.bz2 Changelog:
2011-03-16 - bsnes_v077-source.tar.bz2 Changelog:
2011-03-15 - bsnes_v076r07.tar.bz2 This should be the final WIP, left r06 up since that one has a binary. Rather than make the libsnes API incompatible with previous versions, I just implemented path as return { basename, hint }; So you will still use the set basename function already there as before. So either DSP/MSU1/Serial all go in the ROM folder, or they all go somewhere else. You can be fancy and detect the gametype and override the basename as you like, if you really want. Bumped the API to 1.3, and added const char snes_library_id(void); it will return "bsnes v076.07" at the moment. The internal string is static, but don't try caching it or modifying it anyway. You'll have to split the name and version yourself if you want them separately. API is backward-compatible to 1.0 still. Also improved string::assign and string::append to take a variadic number of arguments. To make this happen, I had to make to_string return const char so that infinite recursion did not happen. I had a lot of code like this: Code: cheat.append(code); cheat.append("+"); cheat.append(desc); Ugly. I also hate std::string syntax: Code: cheat << code << "+" << desc; I may just remove that entirely, not sure yet. Left shift != string append. So now there is: Code: cheat.assign(code, "+", desc); //cheat = { code, "+", desc }; also works nicely cheat.append(code, "+", desc);
2011-03-15 - bsnes_v076r06.tar.bz2 (Windows 32-bit binary included.) Changelog:
2011-03-13 - bsnes_v076r05.tar.bz2 Changelog:
2011-03-06 - bsnes_v076r04.tar.bz2 (source only.) Changelog:
2011-03-03 - bsnes_v076r03.tar.bz2 (Windows 32-bit binary included.) Please test this one guys, I'd like to release an update this weekend :D I want to add a better message for when BIOS files do not exist. I also want to add manual paths for DSP/MSU1/BSS/BSP/SAV files. Also, the debugger is extremely slow on Windows, but I don't know why. Probably phoenix related, but the MinGW profiler crashes. So I don't really know how I'm going to fix that. Help would be appreciated. Changelog:
2011-03-01 - bsnes_v076r02.tar.bz2 Changelog:
2011-02-27 - bsnes_v076r01.tar.bz2 (source only.) Changelog:
2011-02-25 - bsnes_v076-source.tar.bz2 Most notable in this release is that sound support has been added to my own Super Game Boy emulation. The GUI toolkit, phoenix, has also received a complete rewrite; with the most visible change there being that windows are now resizable. Changelog:
2011-02-24 - bsnes_v075r16.tar.bz2 (Windows 32-bit compatibility binary included) This has my latest API enhancements, but there are some known issues:
2011-02-22 - bsnes_v075r15.tar.bz2 phoenix/GTK+ rewrite completed. All three targets should now be 100% operational with full resize support.
2011-02-19 - bsnes_v075r14.tar.bz2 (Windows binary is included.) Adds the new phoenix/Windows. Testing would once again be appreciated, as this is basically a rewrite of the entire core of the GUI. Double-clicking listbox items works, at least :D
2011-02-16 - bsnes_v075r13.tar.bz2 Found the source of lag on cartridge load. ListView::modify() was not locking Qt messages, so it was causing a CheatEditor::refresh (copies 16MB of memory each call) for all 128 cheat items. Final issue now is that nested submenus (menus inside of menus) are not applying Window::setMenuFont yet.
2011-02-15 - bsnes_v075r12.tar.bz2 phoenix has been completely rewritten from scratch, and bsnes/ui + bsnes/ui-gameboy have been updated to use the new API. Debugger works too. Currently, only phoenix/Qt is completed, and there are two known issues: 1: font sizes of menu items are wrong, I can fix this easily enough 2: there's some sort of multi-second lag when loading games, not sure what's happening there yet The new phoenix isn't exactly complete yet, still making some key changes, and then I'll start on phoenix/Windows and phoenix/GTK+. The most noticeable difference is that you don't have to give all of the header paths and PHOENIX_PLATFORM defines when compiling individual GUI object files. It's only needed for phoenix.cpp itself. The overall structure of the phoenix source folder is much saner as well for sync.sh. I'm really surprised things are working as well as they are for a two-day power rewrite of an entire phoenix target. The other targets won't be as bad insofar as the core stuff is completed this time. And thank god for that, I was about ready to kill myself after writing dozens of lines like this: Code: HorizontalSlider::HorizontalSlider() : state(new State), base_from_member<pHorizontalSlider&>(new pHorizontalSlider(*this)), Widget(base_from_member<pHorizontalSlider&>::value), p(base_from_member<pHorizontalSlider&>::value) {} But each platform does have some new, unique problems. phoenix/GTK+ was acting screwy prior to the rewrite, and will most likely still have issues. Even more important, one of the major points of this rewrite was having the new phoenix/core cache widget settings/data, so that I can destroy and recreate widgets rather than relying on SetParent. This means that simple copying of the old phoenix/Windows won't work, and this new method is significantly more involved.
2011-02-09 - bsnes_v075r11.tar.bz2 (Windows 32-bit compatibility binary included) Rewrote the way menus are attached, they act like layouts/widgets now. All three phoenix targets once again work with both radio menu items and radio widgets. Both GTK+ and Qt have built-in group controls right inside the widgets, so I don't have to keep my own groups around anymore. They do act screwy at widget creation though, have to jump through some hoops to get it to work right. All I can say is, definitely set all child widgets to the parent before trying to check any of them. My long-term goal for the main window is to honor the fullscreen video setting as a generic setting, and let the window scale auto-fit the best possible size that matches your scale preference into the output window, centered just like fullscreen. For now, I've just set it to a fixed window size until I finish working on phoenix. The scale X settings will just be to snap the window to an exact size in case you don't want any black borders, they won't be radio items and the bsnes-geometry.cfg file will save width/height information as well. Simplified the sizing requirements for creating layouts and updated all bsnes windows to support the new system. Layouts also expose their minimum width/height values, which I use to create perfectly sized windows on all three platforms. This will fix cut-off heights on the last Windows WIP. Qt is being annoying though and forcing a minimum window size of 300,100 despite me telling it to use a smaller window size. Always have to fight with Qt, I swear to god. To get the Windows debugger looking sharp, I will need to add a Geometry Font::geometry(const nall::string&) function. Easy to calculate on Windows with DrawTextEx, not so easy on other targets. But get that value, add +~10px margins for client edges, and then use layout.minimumWidth/Height() + text string geometry.
2011-02-07 - bsnes_v075r10.tar.bz2 (Windows 32-bit compatibility binary included) All targets can now handle dynamically changing the header text of listbox widgets, but I wouldn't recommend trying it with items in your list. phoenix/Windows and phoenix/Qt are mostly fully operational now. All platforms support dynamic layout resizing. I tried WM_GETMINMAXINFO (thanks, OV2), but it was acting kind of choppy on resize, and it would get confused and go crazy if you snapped one direction to the minimum height but not another, so for now I'm leaving it off. phoenix/GTK+ will be missing some functionality in regards to window geometry. The other two have a more coherent strategy now: geometry() is the client area, and setGeometry moves the client area to where you ask for. This makes truly centering your client area trivial. frameGeometry() includes the borders, menu and status. There is no setFrameGeometry(), not sure if I really even want that, but it could be useful so who knows. All targets also support non-resizable windows. X11 is of course horrendously poor with frame sizes, Qt and GTK+ don't even pretend to simulate them, so they say the frame is 0x0 pixels in size until your widget is fully realized and visible to the end user. So for now, to get window positioning right, I have to wait until the window appears and then reposition the window again, causing a slight jump. My plan is to build some persistent caching support directly into phoenix. From here, I can just have the window snap the very first time you run your very first phoenix app. I'll then determine the frame size information, and use that to create future windows. Once they spawn, I'll recheck and update the frame size info in case it has changed (eg user changed themes.) Saving settings into .config/phoenix will allow me to avoid having to snap the window every time on first startup. If the config file is missing or unwritable, too bad, happens every time then. I'm thinking about renaming onResize to onSize, and getting rid of Window::create(). Rather make it spawn like every other control in its constructor.
2011-02-06 - bsnes_v075r09.tar.bz2 Ported phoenix/Windows and phoenix/GTK+ over to the new system. There are some problems that need to be addressed:
2011-02-05 - bsnes_v075r08.tar.bz2 Eleven hours of work. Window is now a base type (inherits from Object, not Widget), same for Layout. FixedLayout still inherits from Layout. Added HorizontalLayout and VerticalLayout types, that can append each other to themselves to create box layouts. Layout margins are supported, spacing is specified inline (I find this a much better way to fine-grain spacing than Qt's single setSpacing function), and alignment is handled strictly via padding widgets (insert a zero-sized label and it will automatically grow to consume all extra space.) Overall, my box packing model is slightly less powerful than Qt's, but it is a good deal simpler and and easier to use in 90% of cases. The one limitation I hit was with my input settings window, I'm not currently able to embed two different layouts and toggle one on and the other off to show only either { mouse x-axis, y-axis } or { mouse left, middle, right }, so they instead just space out differently and I had to grow the input window width a bit to compensate. Resizing works great, pretty cool seeing that this is the first time I've ever written my own resizer. I had to fight with Qt for several hours to the point of potentially developing an aneurysm, but I finally got it to properly handle geometry and sizing stuff. Some weird issue with the bsnes viewport widget, I tell it to resize and for some reason it doesn't. Cheap hack, I just make it constantly resize every video refresh and it eventually takes. Wish I knew what was up with that. All of bsnes now uses dynamic layouts sans the main window, so you can resize them however you like. This is still all Qt-only, I'm afraid. The other two ports are in-progress.
2011-02-04 - bsnes_v075r07.tar.bz2 This has the phoenix changes applied. Instead of widgets attaching directly to windows, you now attach them to layouts, which can then be attached to windows. Layouts are widgets themselves, so adding layouts to layouts is trivial. It also allows for multi-widget show/hide, etc. Right now there is only FixedLayout, but of course the plan is to support a BoxLayout, that lets you add HorizontalLayout and VerticalLayout containers to it, thus enabling auto-resize and simpler form layout. So far only phoenix/Qt is 100% moved over. phoenix/GTK+ has about 1/3rd ported, and phoenix/Windows only has one control ported over as a proof-of-concept. On the user side, bsnes, bgameboy, snespurify and curse have been moved to this new layout system. All of bsnes works great with it, as far as I can tell. Fullscreen, debugger, etc are good. Testing for regressions would be nice.
2011-02-02 - bsnes_v075r06.tar.bz2 Removed the floating-point volume adjustments from the wave channel and the left/right speaker mixers. Also, against my better judgment I'm backing out of left/right computation when they are both turned off. This basically makes non-stereo games run faster, but will make stereo games appear to run slower. I don't like it when end-users experience mystery slowdowns. Anyway, it appears that the audio calculation is really fucking demanding. Knocks FPS from 800 down to 300. I thought it might be libco, so I took it out and it only went up to 305fps o.O There is also some sort of problem with bsnes/Super Game Boy audio. The latency is really great when you first start, but it seems to drift apart over time until it is well over 500ms, and then it either pops or fades back to very low, sub-50ms latency again. The way I handle mixing is that the coprocessor audio samples go into a resampler to the native SNES rate, and fed to an output buffer. SNES audio samples go there untouched. When there is a sample in each, I add them together and average the result (I still don't understand why we divide by two since these are signed integers), and output it immediately. It's just-in-time sampling, so as long as DSP v Coprocessor do not drift very far, it should have very low latency. And I make the CPU sync DSP and Coprocessor once per scanline, which is something like 15 samples or so.
2011-02-02 - bsnes_v075r05.tar.bz2 Added Game Boy sound emulation, all four channels. It's really, really, really bad. Plenty of bugs, I don't even know what the fuck a high-pass filter is so that isn't there. Hermite resampling from 4MHz down to 44KHz. But it's tolerable. I don't understand what sweep is for at all, and I'm sure I have that insane recursive reload behavior wrong. This is pretty much my own design. I referenced blargg's gb snd emu, blargg's older gb apu ref, Cydrak's APU core, that lousy gbdev wiki article, the completely and utterly worthless pandocs, and received nothing but bad and wrong information that just wasted my time from #gbdev. But I managed to pull it off. It's also painfully slow, like 250fps on my machine slow. Countless optimizations are possible. Anyway, I'd love some help with bug-fixing :D But I'm not really too concerned with absolute perfection anyway, so no big deal. I'm sure it'll get fixed up over time.
2011-02-01 - bsnes_v075r04.tar.bz2 Changelog:
2011-01-31 - bsnes_v075r03.tar.bz2 Changelog:
2011-01-30 - bsnes_v075r02.tar.bz2 Changelog:
2011-01-28 - bsnes_v075r01.tar.bz2 Changelog:
- Taito Variety Pack: Sagaia locks up- Super Game Boy: save states crash the CPU upon load2011-01-25 - bsnes_v075-source.tar.bz2 This release brings improved Super Game Boy emulation, the final SHA256 hashes for the DSP-(1,1B,2,3,4) and ST-(0010,0011) coprocessors, user interface improvements, and major internal code restructuring. Changelog:
2011-01-23 - bsnes_v074r11.tar.bz2 Changelog:
2011-01-23 - bsnes_v074r10.tar.bz2 Major WIP, countless changes. I really went to town on cleaning up the source today with all kinds of new ideas. I'll post the ones I remember, use diff -ru to get the rest. What I like the most is my new within template: Code: template<unsigned lo, unsigned hi> alwaysinline bool within(unsigned addr) { static const unsigned mask = ~(hi ^ lo); return (addr & mask) == lo; } Before, you would see code like this: Code: if((addr & 0xe0e000) == 0x206000) { //$20-3f:6000-7fff The comment is basically necessary, and you have to trust that the mask is right, or do the math yourself. Now, it looks like this: Code: if(within<0x20, 0x3f, 0x6000, 0x7fff>(addr)) { That's the same as within<0x206000, 0x3f7fff>, I just made an SNES-variant to more closely simulate my XML mapping style: 20-3f:6000-7fff. Now obviously this has limitations, it only works in base-2 and it can't manage some tricky edge cases like (addr & 0x408000) == 0x008000 for 00-3f|80-bf:8000-ffff. But for the most part, I'll be using this where I can. The Game Boy is fully ported over to it (via the MBCs), but the SNES only has the BS-X town cartridge moved over so far. SuperFX and SA-1 at the very least could benefit. Next up, since the memory map is now static, there's really no reason to remap the entire thing at power-on and reset. So it is now set up at cartridge load and that's it. I moved the CPU/PPU/WRAM mapping out of memory.cpp and into their respective processors. A bit of duplication only because there are multiple processor cores for the different profiles, but I'm not worried about that. This is also going to be necessary to fix the debugger. Next, Coprocessor::enable() actually does what I initially intended it to now: it is called once to turn a chip on after cartridge load. It's not called on power cycle anymore. This should help fix power-cycle on my serial simulation code, and was needed to map the bus exactly one time. Although most stuff is mapped through XML, some chips still need some manual hooks for monitoring and such (eg S-DD1.) Next, I've started killing off memory::, it was initially an over-reaction to the question of where to put APURAM (in the SMP or DSP?) The idea was to have this namespace that contained all memory for everything. But it was very annoying and tedious, and various chips ignored the convention anyway like ST-0011 RAM, which couldn't work anyway since it is natively uint16 and not uint8. Cx4 will need 24-bit RAM eventually, too. There's 8->24-bit functions in there now, because the HLE code is hideous. So far, all the cartridge.cpp memory:: types have been destroyed. memory::cartrom, memory::cartram become cartridge.rom and cartridge.ram. memory::cartrtc was moved into the SRTC and SPC7110 classes directly. memory::bsxflash was moved into BSXFlash. memory::bsxram and memory::bsxpram were moved into BSXCartridge (the town cartridge). memory::stAB were moved into a new area, snes/chip/sufamiturbo. The snes/chip moniker really doesn't work so well, since it also has base units, and the serial communications stuff which is through the controller port, but oh well, now it also has the base structure for the Sufami Turbo cartridge too. So now we have sufamiturbo.slotA.rom, sufamiturbo.slotB.ram, etc. Next, the ST-0010/ST-0011 actually save the data RAM to disk. This wasn't at all compatible with my old system, and I didn't want to keep adding memory types to check inside the main UI cartridge RAM loading and saving routines. So I built a NonVolatileRAM vector inside SNES::Cartridge, and any chip that has memory it wants to save and load from disk can append onto it : data, size, id ("srm", "rtc", "nec", etc) and slot (0 = cartridge, 1 = slot A, 2 = slot B) To load and save memory, we just do a simple: foreach(memory, SNES::cartridge.nvram) load/saveMemory(memory). As a result, you can now keep your save games in F1 Race of Champions II and Hayazashi Nidan Morita Shougi. Technically I think Metal Combat should work this way as well, having the RAM being part of the chip itself, but for now that chip just writes directly into cartridge.ram, so it also technically saves to disk for now. To avoid a potential conflict with a manipulated memory map, BS-X SRAM and PSRAM are now .bss and .bsp, and not .srm and .psr. Honestly I don't like .srm as an extension either, but it doesn't bother me enough to break save RAM compatibility with other emulators, so don't worry about that changing. I finally killed off MappedRAM initializing size to ~0 (-1U). A size of zero means there is no memory there just the same. This was an old holdover for handling MMIO mapping, if I recall correctly. Something about a size of zero on MMIO-Memory objects causing it to wrap the address, so ~0 would let it map direct addresses ... or something. Whatever, that's not needed at all anymore. BSXBase becomes BSXSatellaview, and I've defaulted the device to being attached since it won't affect non-BSX games anyway. Eventually the GUI needs to make that an option. BSXCart becomes BSXCartridge. BSXFlash remains unchanged. I probably need to make Coprocessor::disable() functions now to free up memory on unload, but it shouldn't hurt anything the way it is. libsnes is most definitely broken to all hell and back now, and the debugger is still shot. I suppose we'll need some tricky code to work with the old ID system, and we'll need to add some more IDs for the new memory types.
2011-01-21 - bsnes_v074r09.tar.bz2 This WIP fixes up the last bit from the old memory mapping system, the BS-X Satellaview town cartridge now has a static memory mapper that is dynamically decoded based on register settings. Tested with BS Town + BS Zelda, and I can get in-game just fine. The mapping code is actually a lot more readable this way, too.
2011-01-21 - bsnes_v074r08.tar.bz2 The nall::function binding for the memory map apparently breaks when the debugger is enabled, as PPU:: becomes PPUdebugger::, etc; and C++ isn't smart enough to upconvert for us. Not sure how I am going to work around that yet ... Changelog:
2011-01-18 - bsnes_v074r07.tar.bz2 (Windows 32-bit compatibility binary included.) Fullscreen works on all ports, but Qt is in general pretty wonky at the moment. Don't really care right now. F11 toggles fullscreen, there is no menu or status in fullscreen, and it auto-scales to the highest even multiple that it can. It copies all other settings (filter, shader, aspect correction, video region, vsync, async) from your windowed mode settings. You cannot enable the menu or status bars, because those are a major pain in the ass to support with both GTK+ and Qt returning nonsense geometries. Combine with each platform treating whether or not to handle menus and/or statuses as part of the geometry or not, and it's a recipe for pain. It is pseudo-fullscreen for now, but if we have some spiffy code in the future to set a true fullscreen that works on Linux (and hopefully OS X), I'll add a true-FS option to ruby later. I am not going to hide the mouse cursor at this time, because right now ruby is in charge of that for mouse capture and it's tricky to make phoenix also capable of controlling that. I am not supporting media center users who want to start in fullscreen, and I am not worrying about idiots who can't figure out how to exit fullscreen mode. I am not going out of my way to support multi-monitor setups, Qt had special handling for it that phoenix does not have.
2011-01-17 - bsnes_v074r06.tar.bz2 (Windows 32-bit compatibility binary included.) This WIP uses the 16MB+64MB memory tables for 1:1 mapping of the S-CPU bus. Minimum RAM requirement goes up to 128MB, dare I be bold here and recommend you have 256MB. I also hooked up the basic bindings for making pseudo-fullscreen windows in phoenix/Windows and phoenix/GTK+, but both have some serious issues.
2011-01-16 - bsnes_v074r05.tar.bz2 Oh good, that turned out to be a lot easier than I expected. Almost all of the work was already done yesterday in porting the SA-1 over to a static map. New results: Code: CPU SFX SA1 v074.01 180 94 111 v074.03 168 81 93 v074.04 ... 91 ... v074.05 168 91 109 -6.5% -3% -2% 2-3% on special chips, although a shame, is almost a write-off. So now that there's only one bus, we can try some crazier ideas (16m-entry tables and such) to try and boost non-SFX/SA1 games. There's also some new room to boost SFX/SA1 speeds even more via heavier inlining.
2011-01-16 - bsnes_v074r04.tar.bz2 SuperFXBus was inheriting from Bus, in other words using a copy of the same memory mapping subsystem. I've removed that and made it a simple mask, since only ROM+RAM are mapped there. Result: Code: CPU SFX SA1 v074.01 180 94 111 v074.03 168 81 93 v074.04 ... 91 ... So the SuperFX speed loss has been mostly removed. I am going to attempt the same on the SA-1 now, but it's the SA-1 that took more than half of my time the other day. It's much, much more complex. There's also two Bus inheritors: the VBR bus and the main SA-1 CPU bus. By removing both, I am free to grow the size of the main CPU bus without increasing memory usage three-fold.
2011-01-15 - bsnes_v074r03.tar.bz2 You guys are going to hate the hell out of this one. It's twenty hours of non-stop work, no exaggeration at all. Started at 4AM, just wrapped up now at 8PM. I rewrote the entire memory subsystem. Old system: 65536 pages that map 256 bytes each Mapping a new page overwrites old page Granularity capped at 256 bytes minimum, requiring ST-001x to map 60:0000-00ff instead of 60:0000,0001 Classes inherit from MMIO and Memory, forcing only one mappable function per class, and fixed names MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity Can dynamically change the map at run-time, MMC register settings perform dynamic remapping New system: XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that shapes almost everything on the SNES very well Internally, 2048 pages that map 8192 bytes each Pages are vectors, scans O(n) from last to first (O(log n) would not help, n is never > 3) Can multi-cast writes, but not reads [for the obvious reason of: which read do you return?] Can map reads and writes separately Granularity of one for entire 24-bit address range, no need for MMIO - whatever is in XML is exactly what you get Read/Write tables bind function callbacks, so I can have any number of functions with any names from any classes with no inheritance (no more uPD7725DR, uPD7725SR helpers, etc) Less memory usage overall due to less tables [ I tried 16 million tables and it used 2GB of RAM >_o ] Cannot dynamically change the map at run-time, MMC read/write functions perform address translation [worse average case speed, better worst case speed] Now the hate me part, functors can't beat virtual functions for speed. There are speed penalties involved: -4.5% on average games -11% on SuperFX games (SFX has its own bus) -15% on SA-1 games (SA-1 has two buses) Of course the two that need the speed the most get the biggest hits. I'm afraid there's really not a lot of wiggle room to boost speed back up. I suppose one bright spot is that we can much more easily try out entirely new mapping systems now, since the dynamic portions have been eliminated. Also, I am too tired. I hooked up every special chip but BSXCart. That one has cached MMC registers that I need to set up.
2011-01-13 - bsnes_v074r02.tar.bz2 Changelog:
2011-01-13 - bsnes_v074r01.tar.bz2 Changelog:
2011-01-11 - bsnes_v074.tar.bz2 This release adds full low-level emulation of the NEC uPD96050 coprocessor, used by the ST-0010 (F1 Race of Champions II) and the ST-0011 (Hayazashi Nidan Morita Shougi). The former was already playable with HLE, but lacked timing emulation. The latter has never been playable through emulation before now. But as with SD Gundam GX before, you really weren't missing much. Please see my donations page, and send a small token of thanks to Dr. Decapitator's Paypal address if you don't mind. The NEC uPD96050 proved to be much more difficult than anticipated, and he had to dump the chips multiple times each, spending many days on this. He is currently working on extraction of the Cx4 (Mega Man X2, Mega Man X3), which initial scans have shown to be an Hitachi HG51B169. Also remaining is the ST-0018, which is used by the only remaining unplayable game: Hayazashi Nidan Morita Shougi 2. Also new in this release is my own Game Boy emulator. It is being used to provide native Super Game Boy support, built directly into bsnes. This core is released under the GPLv2, but I am willing to grant a more permissive license for other SNES emulators, if anyone is interested. Of course I cannot compete with the quality of gambatte, and certainly not from only a weeks' worth of work. Currently, there is no Game Boy-side sound output and there are quite a few bugs remaining in its emulation core. I would appreciate any help on this, the Game Boy is not my forte. So yes, we are taking a step back today, so that we may take two steps forward in the future. See my previous posts for more on the advantages my native Game Boy emulation core brings to the project. As I am in a very good mood, I have posted two pre-compiled binaries this time: the first is a 32-bit Windows binary built with the faster performance profile; and the second is a 64-bit Windows binary built with accuracy profile. Lastly, the debugger is still Linux-only, but it is now stable enough to be considered usable. Check it out if you like, compile with -DDEBUGGER to enable it.
2011-01-10 - bsnes_v073r07.tar.bz2 I give up for now. This WIP doesn't really improve uPD any, but it does have major fixes to the debugger. Debugger is still Linux-only for want of a HexEditor widget, but the Linux one is now usable. Before it'd trace and search for breakpoint at sub-1fps. Fixed it to not break out of core for simple things and it'll run at near-fullspeed for BPs, half-speed for tracing to file (lots of I/O.) EDIT: rather obvious, but: Code: 000f a = $00da; 0010 b += drnf; 0011 rp = a; 0012 sol = [rp]; 0013 pc.l = sol; pc.l = sol = datarom[a=00da] is static and unchanging, no matter what op is fed to DR. So JP BRCH=0 must be doing something other than just PC=SO. But even by using all variables and states at that opcode, I can find no way to make it jump where we want, $1c -> $c1. It's possible it jumps somewhere else first that then reads from the table to find out where to jump though. Doesn't look like the $96 it reads from ROM is right, that code there looks like line noise ... lots of useless, impossible to hit branch checks. As for the data ROM itself, $000-0ff (as 16-bit words) is a DIV table. Formula: value = 32767/offset (thanks Jonas Quinn) So A=$da, rp=A, ro=32767/$da or 218. 32767/218=150, or $96. I can't possibly imagine why the hell the game would perform a constant division here.
2011-01-10 - bsnes_v073r06.tar.bz2 Okay, I need help with Hayazashi Nidan Morita Shougi (J). Above WIP will automatically map in the ST-001x chips, no need for an XML file. F1 Race of Champions II (J) is fully playable, at least. It's forced to 15MHz like the ST-0011 for now. The core (snes/chip/necdsp/core) is somewhat unstable at the moment, some debugging hooks commented out and some hacks / ideas floating around in there. Disassembler can't handle long jumps yet. Code: a1728c31df22b93e4bdae73718ba27a2 st0010.bin 682241e1370c957af676332630177f71 st0011.bin a74594aff68fab966842414e199ac501 st0010-program.bin 5a604bb9a25e647a80d23d36520dd442 st0010-data.bin 370c36279a8510ad89965ae719366056 st0011-program.bin de8971c1b85b9f58364cfc02d7d1b1e4 st0011-data.bin Code: 55c697e864562445621cdf8a7bf6e84ae91361e393d382a3704e9aa55559041e st0010.bin 448e0deb0f580833ea878f4894a56124da18453d2d78e821388b6545909ba00a st0011.bin
2011-01-08 - bsnesv073r04r.tar.bz2 Yeah, see? I repatched the upd7725 standalone module, and now it works just fine. F1 ROC II is fully playable now. The fuck is going on? ;;
2011-01-08 - bsnes_v073r05.tar.bz2 Added uPD96050 emulation, but it's not working right now. I'm totally stumped. The ST-0010 player cars aren't moving right, and it crashes sometimes on exit like it's going out of bounds. I had decided to try and avoid duplicating the 20KB uPD7725 core, so I made a new folder: snes/chip/necdsp snes/chip/necdsp/upd7725 snes/chip/necdsp/upd96050 The latter two derive from the former, and they specify the PC, RP and DP sizes, which allocates appropriate memory. I use simple runtime-masked registers (to avoid template hell on every uPDcore function), and then I derive from that to complete each actual DSP. The uPD7725 seems to work great, but the uPD96050 is fucked and I don't know why :( Help would be appreciated, it must be something simple because I am certain the cars were working before. Kinda wish I didn't scrap the old code now :( I kept wip04 up, I'm going to try repeating my earlier changes with a separate core and see if I can get it working again. Okay, this WIP will do this for you automatically, but you can also use this XML: Code: <?xml version='1.0' encoding='UTF-8'?>
The st0010.bin file is here: st0010.bin And obviously, you can only use this with F1 ROC II, probably any region. I'll hook up saving/loading the RAM when we get the chip working again. Damnit, so close too. I wanted to post about this tonight :(
2011-01-08 - bsnes_v073r04.tar.bz2 No uPD96050 emulation here just yet, be patient ;) Just something I wanted to do first ... I've merged the bgameboy GUI into the bsnes project, as it's only ~3KB and it means I don't have to keep manually editing and copying two projects around. You can set ui := ui-gameboy to build bgameboy as a standalone, and ui := ui to build the bsnes you are used to. I will be polishing it to allow changing the binary output name, not building the SNES portions when not needed, etc in time. So that'll end bgameboy standalone releases, at least for now. If it ever gets important enough to split back out again I can, but I prefer it this way. bgameboy was never meant to be mainstream anyway, just a component for bsnes.
2011-01-07 - bsnes_v073r03.tar.bz2 Changelog:
2011-01-06 - bsnes_v073r02.tar.bz2 (Windows 32-bit compatibility binary included.) Changelog: