Front End

version 0.5.9 (today 2007-01-01 20:24)

 

Version 0.5.9

 

* Include new Tab PERSONAL

** Rom played count

** Rom played last time

** Rom rating

** Rom bookmark status

* Improve config updates. Please resave you genesis/megadrive config!

* Improvements in ROMDB

** Now all platforms supported by ecc will be accepted

** Limit length of filename for non breaking divs.

** Update statistics (platfom, categories)

>> Get it HERE

SNES emulator

2007-01-01 - bsnes v0.019 released

 

I'm releasing bsnes v0.019 today. This version contains Bandai Sufami Turbo support, new IRQ emulation code, and some various bugfixes.

 

Unfortunately, this release is not entirely cause for celebration. Due to fatal errors in Microsoft's "enterprise class" c++ compiler package, I am no longer able to compile bsnes with profile guided optimizations. I have tested v0.018 with and without these optimizations, and the difference is a 40% speedup when PGO is used, even more significant than I had previously believed. However, bsnes has now become too complex for Visual C++ to handle. Unfortunately, there is nothing I can do about this, except wait for Microsoft to fix their compiler.

 

(Warning: this paragraph contains personal opinions, skip it if you can't handle that) As if this wasn't enough, I'm now doing my best to wean my dependence from Microsoft's line of operating systems, as I'm particularly concerned about the black box nature of Vista and its DRM control mechanisms. This isn't a road I wish to begin traveling down, and thusly have no interest in upgrading to future versions of Windows. Therefore, as of late, I've been writing a UI wrapper that will allow me to code applications that are truly platform independent. The biggest goal for this library is to design a GUI for bsnes that runs virtually identically on both Windows and Linux/BSD. This is mostly complete, however there were many tricks I used in bsnes using the win32 API that I simply cannot do with GTK+ on Linux/BSD, such as the memory editor window subclassing. I will be porting bsnes to use this new UI wrapper, and in turn this will lessen the attractiveness / functionality of the bsnes UI to a certain degree.

 

Perhaps the most devastating news is that I am still contemplating the idea of designing a dot-based PPU renderer for bsnes. As if the loss of PGO wasn't bad enough, this will likely eat away an unimaginable level of performance as well. I can only estimate the speed loss being between 100-500%. Yes, it will be that bad. And despite weeks of planning, I cannot think of a way to allow a scanline-based and dot-based renderer to coexist as selectable options, given their massive differences in implementation.

 

And let's not even joke about SA-1 or SuperFX support ... those processors are each four to eight times more powerful than the SNES' main CPU.

 

All of these speed losses will basically make bsnes mostly irrelevant as an alternative to ZSNES, SNES9x et al. Although I believe I really came close to a viable alternative with v0.018, I know that I cannot both create a mainstream emulator, as well as keep with my original goal to emulate the SNES as accurately as possible.

 

The past few months have been very tough for me; trying to decide which of the above two goals to pursue. I've still not absolutely made up my mind. But for now, I've been sitting on a mostly untouched version of bsnes for the last few months, and have decided to release it to the public, profile guided optimizations be damned.

 

I'm once again asking for help, if anyone can figure out why bsnes won't compile with PGO support, please let me know. I'd very much like to get one last PGO build of bsnes released before starting on a dot-based PPU renderer. But given the usual response I get from these requests for help, I'd suggest no one getting their hopes up that bsnes will ever be as fast as it once was again.

 

The new version can be downloaded at the usual place. I'm leaving v0.018 up, as it may very well be the last stable, fast version of bsnes ever released.

Source / Download

NES emulator

Beta 2 is available for downloading. A few things: the binary wasn't tuned for any CPU, like i586. Plus, use the default blitter (256x240 output), due to sync problems. News regards CPU and shell fixes. I hope you enjoy it and give me proper feedback... and no, the subtitle is correct, tear. ;;

 

** NOTICE ** This is a beta version, might be unstable.

 

What's new for version 5.00 BETA 2 (01/02/2007)

-----------------------------------------------

- Fixed opcodes: $01[ORA1](7/6), $04[NOP3](4/3).

- Fixed an obscure addressing mode timing bug.

- Fixed support for trained games.

- Fixed the sound flag in the config file.

- Disabled debug messages, my bad.

- Fixed warning/status messages.

- Mapped F1 key to toggle FPS display.

- Fixed PRG page masking.

- Added ROM loading error messages.

- Other things I don't remember...

>> Get it HERE.

Saturn emulator. Here is the translated changelog. Sorry it doesn't make a lot of sense.

* CD playback command of CD block was corrected. It reaching the point where hero legend moves, it increases.

* The timer 1 processing of SCU was corrected. It reaching the point where [vuachiyaruhaidoraido] moves, it increases.

* The drawing command processing of VDP1 was corrected.

* The color transaction of operation of VDP1 was corrected. It reaching the point where the sound test of the dark saber is indicated securely, it increases.

* V blank OUT timing of VDP1 was corrected. It tried to consider the pattern name designated mistake of the cycle pattern of VDP2. The [sureiyazu] [ro] it is and it reaches the point where the aggressive picture and the title picture of [bachiyaron] are indicated securely and increases.

* The color transaction of operation of VDP2 was corrected.

* The windowing of VDP2 was corrected.

* The dynamic recompiling processing of SH2 was corrected. The J league professional soccer team probably will be made! It reaching the point where 2 moves, it increases.

* Option of memory access weight ON/OFF of cash through address was provided. When memory access weight is turned to ON, is to be,*

* The pallet of the choices of meeting viewing becomes normal, (it depends on the dot clock). It reaches the point where also effective sound of [bachiyahuaita] 2 is played back.

* The option which designates HSynch period as the actual clock was provided.

* After the SSF starting until the window becomes large, when CTRL is pushed, it tried to change the use ON/OFF of BIOS temporarily.

* Version of the state saving data changed. Once, front version and the interchangeability is taken but depending upon the data perhaps you cannot read. Especially, because BIOS is not the data modified the BIOS emulating program, there is a possibility where you cannot read.

Source / Download