Could you please add some kind of documentation which keyboard keys are responsible for which gameboy keys? Thanks! I love this emulator, but this makes it hard to recommend it to others. :)

Hey,

I'm trying learn more about emulators and how the things works on low level... I find this function on your code...

fn alu_add16imm(&mut self, a: u16) -> u16 {
  let b = self.fetchbyte() as i8 as i16 as u16;
  self.reg.flag(N, false);
  self.reg.flag(Z, false);
  self.reg.flag(H, (a & 0x000F) + (b & 0x000F) > 0x000F);
  self.reg.flag(C, (a & 0x00FF) + (b & 0x00FF) > 0x00FF);
  return a.wrapping_add(b)
}

Why this can't add the b directly to a? Without make 3 casts to i8 -> i16 and finally u16?

Thank you in advance 😉

In sound.rs

 0xFF23 => {
                self.length_enabled = v & 0x40 == 0x40;
                if v & 0x80 == 0x80 {

The self.length_enabled statement is missing. Adding this fixes annoying noise in a number of games including Zelda: Link's Awakening.

Additionally, the enabled flag on the wave channel should be set like this:

   0xFF1A => {
                self.enabled_flag = (v & 0x80) == 0x80;

The Zelda: Oracle games needs this but seem to have other issues too.

Just stuff I noticed when messing around with it :) (I've been using parts of the code to play with upscaling shaders).

I've been using your emulator as a reference while learning how to write an emulator. Thanks for sharing it!

I had a question about how you implement the GPU's cycle.

In do_cycle https://github.com/mvdnes/rboy/blob/master/src/gpu.rs#L110 it seems like you're emulating the advancement of the GPU's timing fairly accurately. I was expecting to see a mechanism for incrementally drawing graphics into a buffer (later to be output to the host's screen), pixel by pixel. But instead, it seems like you just draw it all at once at the beginning of switching to mode 1, calling self.renderscan() once.

Could you confirm that is indeed what you're doing, and if you had any feedback on it? Was that for performance reasons? Is it because it doesn't affect some, most, or all games? My sense is that some games might want to do clever things depending on what column you're currently drawing to, but that's not possible if you draw it all in one shot and then emulate no-op cycles past that.

Thank you!

Add working link to mirror of pandocs, as the one in README (nocache.emubase.de) appears to be dead

(Used this alternative for quite some time whilst developing another gameboy emulator and they produced BGB, so a fair resource to link to, I think)

Rust: rustc 1.47.0 (18bf6b4f0 2020-10-07) Windows 10 64bit

thread 'main' panicked at 'OleInitialize failed! Result was: `RPC_E_CHANGED_MODE`. Make sure other crates are not using multithreaded COM library on the same thread or disable drag and drop support.', C:\Users\Shell\.cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\winit-0.23.0\src\platform_impl\windows\window.rs:84:25
stack backtrace:
   0: std::panicking::begin_panic<str*>
             at C:\Users\Shell\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\panicking.rs:497
   1: winit::platform_impl::platform::window::{{impl}}::new::{{closure}}<tuple<>>
             at C:\Users\Shell\.cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\winit-0.23.0\src\platform_impl\windows\window.rs:84
   2: core::result::Result<winit::platform_impl::platform::window::Window, winit::error::OsError>::map<winit::platform_impl::platform::window::Window,winit::error::OsError,winit::platform_impl::platform::window::Window,closure-0>
             at C:\Users\Shell\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\result.rs:508
   3: winit::platform_impl::platform::window::Window::new<tuple<>>
             at C:\Users\Shell\.cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\winit-0.23.0\src\platform_impl\windows\window.rs:74
   4: winit::window::WindowBuilder::build<tuple<>>
             at C:\Users\Shell\.cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\winit-0.23.0\src\window.rs:333
   5: glutin::platform_impl::platform_impl::Context::new_windowed<tuple<>>
             at C:\Users\Shell\.cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\glutin-0.25.1\src\platform_impl\windows\mod.rs:55
   6: glutin::ContextBuilder<glutin::context::NotCurrent>::build_windowed<glutin::context::NotCurrent,tuple<>>
             at C:\Users\Shell\.cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\glutin-0.25.1\src\windowed.rs:360
   7: glium::backend::glutin::Display::new<glutin::context::NotCurrent,tuple<>>
             at C:\Users\Shell\.cargo\registry\src\mirrors.sjtug.sjtu.edu.cn-7a04d2510079875b\glium-0.28.0\src\backend\glutin\mod.rs:75
   8: rboy::real_main
             at .\src\main.rs:108
   9: rboy::main
             at .\src\main.rs:26
  10: core::ops::function::FnOnce::call_once<fn(),tuple<>>
             at C:\Users\Shell\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\ops\function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `target\debug\rboy.exe -a D:\bittboy\roms\GB\WWF世界摔角联盟.gb` (exit code: 101)

Hello.

I am looking for an accurate emulator for gameboy color with gdbserver feature. I want to implement it to rboy with gdbstub: https://github.com/daniel5151/gdbstub.

Assign me to this issue please.