SharpBoy - A Game Boy emulator in C#

[xdaniel]

Only port I can (= could probably) do myself is one to Linux, but as long as they're in any way portable, all functions will be ported, including debugger, memory editor, etc.

[Malqua]

I was just sayin', it'd be cool to have shaders so that, oh I don't know, something like more creepy-pasta using that "old movie (Sepia and Scratch)" filter thing.

 

It'd be cool, is all I's sayin'.

[xdaniel]

Yeah, would be cool I have to admit, but adding something like that to a much more advanced emulator, like VBA-M, would make more sense than adding it to some rather experimental one.

 

Also, current changelog for v0.4, which will probably come in a few days or so, considering ex. the GBC DMA regression I've mentioned before:

 

• Fixed compatibility regression with GBC DMA transfers, affects ex. Pokemon Puzzle Challenge
• Improved LCD Status interrupt generation, fixes faked high-color display in certain Game Boy Color games
• Some improvements in handling of disabled LCD; ex. Zelda: Oracle games no longer freeze when leaving the menu
• Improved timer emulation and improved emulation of HALT opcode, fixes ex. Stunt Race FX Demo
• Added crude frame blending via OpenGL; blends currently drawn frame with previous frame to better simulate pseudo-transparency
• Added option to keep aspect ratio intact when resizing window; also double-clicking the game screen maximizes/normalizes the window
• Very minor GUI changes

...oh, and this post marks the completion of Generation 1! Next post will be Chikorita then~

[xdaniel]

 

The MBC7 is a complicated beast, so this is all thanks to GEST's source. Before this, the game managed to boot up, had junk data for saved games, had no tilt sensor input and crashed when trying to go in-game - now, it's pretty much perfect (keeping SharpBoy's limitations in mind), besides the obvious fact that a keyboard is -not- how the game's supposed to be played with.

[xdaniel]

 

I think the biggest problem so far was getting my Wiimote to play nice with my PC... Some more work to be done there, but it's working rather well overall.

 

EDIT: Status update: The MBC5's Rumble feature (used in ex. Pokemon Pinball) is now emulated if you're using a Wiimote, and the Wiimote's battery status is shown via its 4 LEDs (> 0%, > 25%, > 50%, >75%) as well as in the control settings dialog.

 

And also, the current v0.4 changelog (release probably later today, that is Sunday 29th):

 

• Fixed compatibility regression with GBC DMA transfers, affects ex. Pokemon Puzzle Challenge
• Substantially improved MBC7 emulation via GEST's source code, Kirby Tilt 'n' Tumble is now playable
• Improved LCD Status interrupt generation, fixes faked high-color display in certain Game Boy Color games
• Some improvements in handling of disabled LCD; ex. Zelda: Oracle games no longer freeze when leaving the menu
• Improved timer emulation and improved emulation of HALT opcode, fixes ex. Stunt Race FX Demo
• Added Wii Remote support for input and Rumble, button configuration is fixed; MBC7 tilt sensor is controlled by Wii Remote when enabled
• When using keyboard control, MBC7 tilt controls can be changed via the GUI's control settings
• Added crude frame blending via OpenGL; blends currently drawn frame with previous frame to better simulate pseudo-transparency
• Added option to keep aspect ratio intact when resizing window; also double-clicking the game screen maximizes/normalizes the window
• Added drag-and-drop capabilities to GUI, ROMs can now be loaded by dropping them into the program window
• Very minor GUI changes

[Salvage66]

Other controlers used for gameboy games Freaking sweet!

[xdaniel]

Well, just the Wiimote, it doesn't support other controllers.

 

Also, release hopefully coming later today; currently fighting with my Bluetooth setup which doesn't appear to work at all anymore right now. Once that works again, I'll clean up the control settings window a bit, then prepare the v0.4 release.

 

EDIT: Fucking Bluetooth, it's still not working, despite countless driver removals and reinstalls, restarts, etc., etc. If I can't get this to work tomorrow or the day after, I'll just release it like this. It's not a problem with the emulator AND I didn't change anything Wiimote-wise in there prior to my BT problems, but I'd still like to test the Wiimote support once more beforehand...

[xdaniel]

SharpBoy v0.4 released - http://magicstone.de/dzd/sharpboy/

[Salvage66]

I have recieved a fatal error upon running your program

[xdaniel]

Try downloading it again, hopefully fixed that problem. Was related to non-working sound emulation; if it was already working you'd need to download something, but as it's not yet working I just disabled it completely.

[xdaniel]

 

Game Boy Wars 3's External RAM size (128KB/16 banks) was detected correctly, yet it wasn't actually taken into account in the MBC emulation. That resulted in it defaulting to 8KB/1 bank, which made the game crash when it tried to access External RAM beyond that single 8KB bank!

 

Wonder if that fixes any other games, tho I'm not sure if I had ever seen those symptoms elsewhere...

 

EDIT: And another bug fixed (I/O register-related) that appears to have only affected one game, Taiyou no Tenshi Marlowe - previously, it hang at the Technos logo screen, because it didn't get to swap the correct ROM bank back in before trying to execute code there, but now it happily goes in-game and is playable.

 

 

Also, what I've been tinkering with, but can't yet say if it's gonna become a feature, is netplay. I'm having some problems with the actual networking, and serial link emulation is still buggy and barely tested, so it's gonna be some time until I can even say if this'll be in at some point

 

EDIT 2: Improved serial link emulation and implemented rudimentary communication between two SharpBoy processes, which gives us...

 

...one Game Boy that recognizes a working serial link and one Game Boy that doesn't. As you can see in the screenshot, one instance of the emulator is letting us into the Cable Club, while the other's basically telling us that there's no link cable attached. Same thing with Tetris, which allows one player into the VS menus, while the other isn't allowed in.

 

EDIT 3: Most likely not an emulation issue, but timing issues with the inter-process communication... well, something for later, now it's past 3am and I'm tired.

Edited June 10, 2011 by xdaniel

[xdaniel]

You cheater!

 

"Megaman - Dr. Wily's Revenge (U) [!].cht.xml":

 

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfCheat xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Cheat>
    <Enabled>true</Enabled>
    <Text>010A08C1</Text>
    <Prefix>1</Prefix>
    <Value>10</Value>
    <Address>49416</Address>
    <Description>Infinite lives</Description>
  </Cheat>
  <Cheat>
    <Enabled>true</Enabled>
    <Text>015039D8</Text>
    <Prefix>1</Prefix>
    <Value>80</Value>
    <Address>55353</Address>
    <Description>Invincible</Description>
  </Cheat>
</ArrayOfCheat>

[Gump]

I'm liking this, xdan! Keep up the good work on the emulator.

[The Tjalian]

Netplay for the original Pokemon games? Yes please, YES PLEASE!

[xdaniel]

Weird how a single post can make me look at a project again...

 

Since opening the SharpBoy project in VC# some 30 minutes ago for the first time several months, I've fixed the horribly broken FPS limiter (replaced it with the hi-res-timer-based one from my PC Engine emulator), slightly improved the cheats interface, and am going to throw out - after backing it up - a bunch of incomplete and/or useless code (ex. GB Camera, broken netplay), then read up on networking in C# again and try the netplay thing once more. Breakpoints and some other parts of the debugger need some overhauls as well.

 

Changelog for v0.5 so far:

• Some fixes to External RAM handling in MBC emulation; Game Boy Wars 3 doesn't crash anymore and is now playable
• Fixed incorrect writes to certain I/O registers; Taiyou no Tenshi Marlowe isn't crashing anymore as well and is playable
• Minor improvements to timer emulation
• Added cheating functionality for GameShark codes, not finished yet; code list is saved to XML file in savegame directory
• Improved FPS limiter; now less prone to ridiculous slowdown and similar glitches

(...tho most of it is actually from May/June or thereabouts)

 

EDIT:

 

 

Would you look at that! Instance acting as the server on the left, client connected to it on the right. Not actually hooked up to the emulation core yet, but should hopefully be easy... although bad timing could still throw everything off and make me stop trying (like before). We'll see.

Edited December 21, 2011 by xdaniel

[The Tjalian]

You really do love me, don't you?

 

Go for it mate, you can do it!

[xdaniel]

Alright, a status update of sorts... To get to the main point right away: The existing interface and especially the debugger maybe aren't complete and utter crap, but they certainly have some stupid problems. A few things on top of my head...

• The main window resizing code is bloated and doesn't even do its job correctly in some cases, ex. when switching to 1x window size
• The memory editor doesn't update itself correctly; only updates the I/O register area when single-stepping through the code, not when tracing or running the game normally
• Not directly interface-related: storage of configuration/saves/etc. inside the emulator folder as opposed to ex. XP's Application Data or Vista/7's AppDataRoaming

So yeah, because of those problem, bloat, dead code and the like, I set out to rewrite the GUI portion of SharpBoy:

 

 

Only the main window, options dialog and memory editor are "done" so far, but things are looking up. Plus, while also going over some of the emulation core, I've also fixed some bugs in it - namely that the MBC3's RTC didn't actually update itself in-game (thus making the clock in ex. Pokemon GSC stand still or only update erratically), and some (probably) less severe timing errors which resulted in things like IRQs firing a scanline too late and such - and started cleaning it up, too. There's dead or commented-out code everywhere, even I as its author was surprised by the amount of it...

 

EDIT:

 

 

Next piece of debugger functionality implemented, and it's one that didn't even exist in the original SharpBoy - a GBC palette viewer.

Edited March 21, 2012 by xdaniel

[xdaniel]

 

Tile viewer not yet working in monochrome GB mode, will do that next.

[SanguinettiMods]

Will these viewers eventually be able to update and edit the ROM?

[xdaniel]

The memory editor could in theory edit the ROM itself because ROM bank 1 (each ROM is segmented into banks of 0x4000 bytes) is always mapped at 0x0000, and it's known which bank is mapped to 0x4000. However, things like tiles or palettes can be loaded into RAM from pretty much anywhere, and without any indication where they came from, not to mention the many games that use compressed graphics that get decompressed into RAM. Thus, no, permanent editing of ROM contents will never be supported.

[xdaniel]

Work done over the last month: not too much.

 

 

First off, a simple disassembler/tracer is implemented. No single step, breakpoints, etc. yet, I'll see about that. Also showcasing a tiny fix regarding GBC palette writes in Lego Racers, which previously had some wrong colors in the sky. Hope this isn't going to become "edge case hell", but looking at VBA-M's source... ugh.

 

 

Next (and last, actually) is Glocal Hexcite, which didn't have working input whatsoever - input only "worked", if you can even call it that, on the title screen, where any button press sorta paused code execution and corrupted the tilemap. Or that's what it looked like, I don't remember the specifics right now. Anyway, it's fully playable now, after some changes to the input-related I/O register code.

 

So yeah, that's about it. Still some stuff left to do before I'll release the next build - and first one with the whole GUI rewrite and such - but it's getting there, I guess.

[xdaniel]

From the notes:

 

improved GBC palette conversion (moderate speedup in GBC games)

fixed 64kb external RAM handling (Pokemon Crystal JPN, fixed missing town map gfx & non-working saves)

fixed MBC3 RAM bank select (Pokemon Crystal JPN, fixed access of wrong banks after above fix)

 

...and from the source:

 

/* A wee bit faster than going through a Color, then using ToArgb on it...

* Some casual testing (Tetris DX title) gives a speed diff of ~30-40FPS w/o FPS limit

* (~180 with Color, ~220 without)

*/

 

Really need to go through the source and identify other wasteful operations, like the above color conversion. Why create a Color object when, most of the time, a long containing the ARGB data is all I want? Why not create that long directly? And for the few times where a Color is needed for drawing, mainly in the palette and tile viewers, I can just make one on the spot using Color.FromArgb!

 

...and how come I never even noticed Pokemon Crystal JPN not working correctly? Also makes me wonder if there's any other games that have 64 KB of external RAM...

 

---

EDIT: Another core change:

 

changed CPU core opcode execution (moderate speedup)

 

...which, together with the previous color-related speedup means:

• GB: Kirby's Dream Land 2 (world 1 map): ~160 FPS vs. ~205 FPS (+45)
• GBC: Pokemon Crystal (system menu): ~170 FPS vs. ~250 FPS (+80)
• GB: Super Mario Land 2 (map): ~170 FPS vs. ~200 FPS (+30)
• GBC: Tetris DX (file select screen): ~140 FPS vs. ~215 FPS (+75)
• GBC: Zelda Link's Awakening DX (intro): ~65 FPS vs. ~170 FPS (+105)

That's the released SharpBoy v0.4 vs. my current v0.6 WIP, with FPS limit disabled, the FPS numbers are rough averages. I also tried some of the games with both emulators running side-by-side, and the difference in FPS really shows with ex. Zelda LA: in v0.6 the title screen logo appears when v0.4 is just starting to scroll the camera up to the egg.

 

---

optimized sprite evaluation and drawing (slight speedup)

 

...the slight speedup really being slight, around 5-10 FPS in Zelda LA DX. Removed some superfluous memory read calls, as sprite data can only come from OAM (0xFE00 to 0xFEA0) - there's no need for the memory read function to evaluate each address, then always fetch the data from OAM anyway, when I can just directly read from my OAM array.

 

---

Less speeding stuff up, more features getting implemented:

 

(And of course I forgot to change "Tile Viewer" into "Map Viewer" before taking this screenshot...)

 

http://i.imgur.com/Twq5n.png

 

Scratch the above, this is better:

 

Edited May 14, 2012 by xdaniel

[xdaniel]

Everything refreshing constantly, the disassembler tracing code execution, etc., and never below 100 FPS unless you make the disassembly window much larger (redrawing that takes time, not sure how to make it faster):

 

[spinout]

...never below 100 FPS unless you make the disassembly window much larger (redrawing that takes time, not sure how to make it faster)...

If the problem is decoding and generating strings fast enough, you might want to consider making an array of pointers to strings of disassembled opcodes, the opcodes themselves being array indicies.

... but that might not be the problem you're having, just throwing it out there.

[xdaniel]

If the problem is decoding and generating strings fast enough, you might want to consider making an array of pointers to strings of disassembled opcodes, the opcodes themselves being array indicies.

... but that might not be the problem you're having, just throwing it out there.

 

It's likely either that or updating the listbox, still have to check that, then (if possible) optimize the thing...

 

Besides that,

 

changed HALT opcode behavior (fixes blargg cpu_instrs test, -shouldn't- break anything)

 

 

...at least none of my 37 frequently tested ROMs broke, four of which - Stunt Race FX Demo, Zerd no Densetsu, Waverace and X - usually died in some way or another whenever I messed with HALT and the associated logic. So I'm counting the current behavior to be correct, unless I find yet another game or demo that craps out on me.

 

By the way, said 37 games/demos are:

 

 

AIR Pocket OP Demo (PD) [C].gbc

Alone in the Dark - The New Nightmare (E) (M6) [C][!].gbc

Demotronic Final Demo (PD) [C].gbc

Donkey Kong Country (UE) (M5) [C][!].gbc

Gameboy Wars 3 (J) [C][!].gbc

Glocal Hexcite (J) [C][!].gbc

Kaeruno Tameni (J) [!].gb

Kirby's Dream Land 2 (U) [!].gb

Kirby's Tilt 'n' Tumble (U) [C][!].gbc

Legend of Zelda, The - Link's Awakening (U) (V1.0) [!].gb

Legend of Zelda, The - Link's Awakening DX (U) (V1.0) [C][!].gbc

Legend of Zelda, The - Oracle of Ages (U) [C][!].gbc

Mary-Kate & Ashley - Crush Course (U) [C][!].gbc

Motocross Maniacs (U) [!].gb

Pocket Puyo Sun (J) [C][!].gbc

Pokemon - Crystal Version (UE) (V1.0) [C][!].gbc

Pokemon - Gold Version (UE) [C][!].gbc

Pokemon - Red Version (UE) [!].gb

Pokemon Pinball (U) [C][!].gbc

Pokemon Puzzle Challenge (U) [C][!].gbc

Prehistorik Man (U).gb

Shantae (U) [C][!].gbc

Stunt Race 3D Demo (PD).gb

Super Mario Bros. Deluxe (U) (V1.0) [C][!].gbc

Super Mario Land (W) (V1.0) [!].gb

Super Mario Land 2 - 6 Golden Coins (UE) (V1.0) [!].gb

Taiyou no Tenshi Marlowe - Ohanabatake wa Dai-Panic (J).gb

Tetris (W) (V1.1) [!].gb

Tetris DX (JU) [C][!].gbc

Trip World (J).gb

Wario Land - Super Mario Land 3 (W) [!].gb

Wario Land 3 (JU) (M2) [C][!].gb

Wario Land II (U) [C][!].gbc

Wario Land II (UE) [!].gb

Wave Race (UE).gb

X - Xekkusu (J) [!].gb

Zerd no Densetsu (J).gb

 

 

---

Alright, damn it. No matter what I do, what seems to be a combination of string generation and updating the listbox causes the heavy slowdown when having a big disassembly window. Since this post, I had spent several hours trying to speed things up - looked up possible optimizations for C#/.NET's string manipulations, tried different ways to update the listbox (including bloody direct WinAPI calls), nothing helped. So, last thing I'm gonna try before I give up, is to write a custom control that mimics the look of a listbox, but is only capable of doing what it needs to and as fast as possible. We'll see how that goes...

 

---

 

Muuuuuch better. No interaction at all currently, just the bare opcode disassembly output, but I'll get to it.

 

---

Hmm, I'd say mostly done now:

 

 

Opcode at PC gets highlighted (might still change the colors/style a bit), the gray column on the left side is planned to show symbols representing breakpoints and the like - say, red circles for BPs, a filled one for the last BP triggered - once I get to reimplementing them.

 

Note that there is still a small performance hit when the disassembler is open, and another bit more when tracing is enabled, but it's far smaller and far more consistent than what happened previously.

Edited May 22, 2012 by xdaniel