BizHawk emulator

http://tasvideos.org/BizHawk.html
BizHawk is a multi-platform emulator on C#, that focuses on core accuracy and power user tools (debugger will follow shortly) while still being an easy to use emulator for casual gaming. So far it represents pretty accurate NES emulation and a seemly list of mappers. Besides, it now uses bsnes and gambatte cores for the corresponding platforms. Cores on both C# and C++ are supported. C# was chosen for the development speed (more work in less time, much was done since the first release in March) and benefits over cpp in creating the logics.

Architecture points

• Complete separation of client & core (cores are in a dll that the client uses)
• Cores build off a core interface that gives them a unified api for the client to use
• Each component in a core is a reusable object, that can be reused through multiple cores
• Focus on archictecture and readability, long term maintainability is the highest priority
• Second priority is accuracy

BizHawk still needs more developers, because these tasks are unlikely with the current crew:

• Linux & Mac support (some work started though, Mono used)
• Accuracy improvement (particularly the APU. The whole thing would benefit from a rewrite. Might be on C++ as it isn't reused on other platforms)
• Speed improvement (no speed hacks, like in FCEUX)
• FDS and perhipherals like the zapper

Feature suggestions are also welcome. See what's already considered.

Prereq installer
Windows Binary Downloads
Home dev thread

Byuu had done this already, see Higan (The new BSNES DLL sets)

Well, higan is is technically the collection of emulators I wrote; but there is also Cydrak's Nintendo DS emulator.
So it'd be best to say that higan represents emulators built around a certain abstracted model.
They're not technically the best emulators, but they're all at least decent. Obviously bsnes stands out the most.

{bnes + bsnes + bgbc + bgba + dasShiny} unified to a standard API interface = higan (core)
higan (core) + ethos (GUI) = the releases I distribute on Google Code
A little confusing because I call the official GUI higan for release purposes (the GUI gets rewritten every six months usually, so no sense renaming the whole project all the time.)

BizHawk is analogous to (in alphabetical order): Mednafen, OpenEmu, RetroArch, etc.
Their goals are to combine the best emulators for each system, with the caveat that the best has to be open source and amenable to library inclusion.

The closest comparison would be that both ethos and BizHawk are frontends to the higan/bsnes emulator core.

Confusing, but eight years of development and features tends to make things rather Byzantine.

The really nice thing about emulator bundles are that they offer unique GUI experiences. Right now, bsnes can be used with higan, BizHawk, lsnes, BSNES (OS X), Mednafen, OpenEmu or RetroArch

Byuu's is written in C++, and isn't written by feos. Hasn't been done already.

It passes many accuracy tests perfectly, but it's very very slow. It can't reach 60FPS on my Core 2 Duo.
It also has buggy DMC, and can't play Fire Hawk.

BizHawk 1.3.0 released!
http://tasvideos.org/Bizhawk/ReleaseHis ... Bizhawk130
https://code.google.com/p/bizhawk/downl ... -1.3.0.zip

Multiclient

New input config dialog
Ability to map meny console buttons such as reset and power as controller keys
Fix cases where Statusbar pause icon didn't appear when paused
Tracelogger - fix bug that was pausing some NES games
Move virtualpads from TAStudio to its own tool dialog
Move all remaining .dll files to dll folder
Fix - Force stop a\v capture on loading a new rom \ core, to avoid crashes.
Fix - Fixes weird input behavior in frame advance when using things like joypad.set()
Input/Hotkeys - Support mapping to Ctrl/Alt/Shift
Make the rom open filter remember its last option used in this bizhawk session
Fix crash on Joypad unplug
Tracelogger: copy to clipboard
AV dump - support resizing everything to a single resolution.

Lua

Fix savestate.loadslot()
Implement client.screenshot(), client.setscreenshotosd(), client.screenshottoclipboard()
Fix Lua scripts to use their folder as the default folder for that script
Fix movie.setrerecordcounting()

Movies

Fix recording from savestate
Fix loading of sync depending GB menu items.
Sync dependent movie header items now force the emulator settings when the movie is loaded
When switching from record to play, write movie to disk
Add Save Movie hotkey and menu item

TAStudio

Only go to Movie 'Finished' mode if Tastudio is not engaged.
Make sure Movie log and savestates are updated correctly so that tastudio still works correctly when you play through the end of the movie in read-only mode.
Fix Rewind To Frame
Fix - Minor tweaks to make tasstudio not run out of memory so easily
Fixed ListView double-click to run forward to the selected frame.
Fixed the ListView highlighting for the current frame.

NESHawk

20% Faster!
FDS Emulation
PAL Support
Implmented Power Cycle (Hard reset) emulation, including in movie recording
Implemented mappers 19, 20, 28, 36, 103, 171, 249, 250
Fix Robocop 3 scroll glitches
Mapper "TENGEN-800008". support Tetris (Tengen)
Add identifier for TENGEN-800030. fixes bootgod identified dumps of various tengen (U) games
VRC 2 - fix Contra (J), Ganbare Goemon 2 (J)
Fix Nametable Viewer in some games
Fix Dragon Ball - Dai Maou Jukkatsu, Rokudenashi Blues, Dragon Ball Z - Kyoushuu! Saiya Jin, SD Gundam Gaiden, Magical Taruruuto Kun 1, 2
Namco163 Audio
MMC5 - add ExRAM memory domain
Gxrom board - fix possible crash on 64K prg carts
Add 256K prg option for ACCLAIM-MC-ACC. fixes "Simpsons, The: Bart vs. The World" and "Simpsons, The: Bartman Meets Radioactive Man"
Fix Mapper 27 based on new understandings from fceumm - fixes World Hero
Change memory initialization pattern, fixes Huang Di.
NESPPU view: implement ctrl+C copy on mouseover
Fix Mappers 74 and 192

How about future support for (C)NROM-368 Mapperless Rom Format (as implented in NESICIDE!)

I should have a chance to make an NROM-368 test ROM tonight.

This is Shiru's AlterEgo game rebuilt within NESICIDE with the NROM-368 mapper (and adjusted linker config to move the image to the lower ROM space). It works in NESICIDE.

I am seeing two conflicting definitions for NROM-368 on the wiki.

Under the "Format" section, the PRG rom is 48K, with bytes starting at $800 mapped to [$4800:$ffff].

Under the "Hardware" section, the PRG rom is 64K, with bytes starting at $0 mapped to [$8000:$ffff] and bytes starting at $10800 mapped to [$4800:$7fff].

Which is correct? If it's the first one, what is its corresponding hardware arrangement? a 16K chip "PRG0" mapped to [$4800:7fff] with a special decoder, and a $32K chip "PRG1" mapped to [$8000:$ffff] in the conventional NROM manner?

I made a recent, easier to read ASM6 template:



To explain:
$4000-$47FF is unused for many reasons, such as I/O Registers

$4800-$7FFF is expanded space for the ROM
$8000-$FFFF is the original, unexpanded ROM range!

To make it short, there is actually $4800-$FFFF (in address range) worth of used ROM. This is what the Wiki is trying to say!

The mapper can be implemented as either 16K+32K or a single 64K chip, just as SMROM is functionally identical to SGROM except for using two PRG ROM chips.

Ok, and then i can detect which to use from the ines prg size? Very well.

Edit: Implemented on bizhawk in svn. I really wish people would use something like UNIF with board "NROM-368" (or whatever) instead of piling more piles onto iNES 1.0, though. Backwards compatibility is of no concern as any emulator that doesn't specifically understand the 368 layout will not run any 368 rom successfully.

Either way would have PRG ROM size equal to 3 * 16384 bytes, just as both SMROM and SGROM have PRG ROM size equal to 16 * 16384 bytes.

As for backward compatibility, any emulator that doesn't understand a new mapper will fail to run ROMs that use that mapper. Both defining a new mapper and defining a new PRG ROM size for an existing mapper have the same net effect of turning one particular combination of bytes in the header from invalid to valid.

NROM-368 is mostly just a definition of "If you see an iNES ROM with 3×16KiB PRG banks on a mapper that doesn't support PRG banking, what does it mean?". Hence the extension to CNROM-368 and others.

The only reason we talk about a 64KiB version of it has to do with ease of hardware implementation: a 64KiB EEPROM and a 74hc85 digital comparator is all that's needed. The different version of it using a 16KiB and 32KiB EEPROM involves more complicated hardware.

IMO, the UNIF format should have an PRG0 field of precisely 47104 bytes. There's no reason to include the 2KiB padding that iNES requires, let alone the 18KiB that the hardware does. Regarding UNIF MAPR fields, calling it "NROM-368" and "CNROM-368" are fine; unfortunately, no such thing exists for the other boards for which the extension is well-defined (CPROM, SUNSOFT-K, CHR-less mapper 218 homebrew).