Game Boy

[Dark Stalker]

Time for an overdue update. I haven't exactly got an abundance of time, but I do work on my emu occasionally. I've gotten enough done now that I thought it might be worthwile to make a WIP release.

I guess the biggest new feature of this release may be sound support. Implementing it was interesting and a lot of fun too. It wasn't really that hard either. Of course, since I haven't done anything sound related before, I had to learn a bit of the terminology and how sound waves tend to be represented digitally etc. After that things became a lot clearer. My general impression is that the accuracy is pretty good. The only quirk I know isn't emulated is the so-called "zombie volume change", which is wrongly or inaccurately documented. I think bgb is the only emu supporting this, and I've only found one rare game depending on it. I could make an implementation based on some guesses I suppose. The quality of the sound seems to be quite decent too, even though I don't use any complex filters or synthesis.

I also added the 10 sprites pr. line limit, in addition to sprite sorting by x-pos for DMG games, while doing some optimizations to sprites-rendering. This will make some sprites flash or disappear when the limit is exceeded like on the real GB. GB games tend to combine several sprites to make bigger ones, so usually it will be parts of sprites disappearing/flashing. For the same reason, DMG sprites that pass each other tend to have a somewhat segmented appearance.

Another new feature is input configuration as well as gamepad/joystick support. There's a simple addition to the GUI for this. Speaking of the GUI, I did some cleanups and changes to make it a bit less ugly. I also added some ifdefs so that the win32 build uses the native windows file selecting dialog. I'll probably make a nicer GUI later, but it's not the highest priority atm.

The RTC emulation now uses system time so that the time passed in the game will reflect the actual time passed between sessions. I also added support for games to change the actual rtc values through modifying the timestamp, although I haven't seen this used in any game.

Save-files now spawn in a seperate subfolder, so your rom-folders will no longer be spammed with .sav-files. Note that the save-files should be compatible with most other emus.

Cleaning up my drawing code, I came across some interesting issues. It turned out that the previous overlay-based renderer used a generally unsupported YUV-format, making it fall back to SDLs software implementation more often than not. Having fixed this, platforms supporting a hardware overlay should get essentially free scaling. However, it seems that the windows-version of SDL doesn't use an actual overlay, but rather uses the normal DirectDraw scaling-function (which should still be a good bit faster than software at least). According to SDL changelogs true overlay was disabled because of performance issues. I found that the performance problems they encountered were due to them misunderstanding how the DirectDraw UpdateOverlay-function works (they were calling it every screen update). If I get the time to implement a decent fix, I'll see if I can get it included in SDL.

Additionally there's been optimizations and cleanups all over the place, as well as some minor bug fixes and compatibility tweaks.


Downloads:
lameboy-0.10.0_i386_linux.tar.gz
lameboy-0.10.0_win32.zip

 

[HyperHacker]

Cool. Can we choose the save file path?

What is this 'zombie volume change' anyway, and what game depends on it?

 

[ShizZy]

Very nice Dark Stalker, great quality sound too.

 

[Dark Stalker]

Thanks!

Cool. Can we choose the save file path?

What is this 'zombie volume change' anyway, and what game depends on it?

The save path is hardcoded to the "saves" subdirectory for now, but it would be easy to add.

The "zombie volume change" supposedly happens when a game adjusts the volume of a channel while it's outputting sound. Depending on what is written to the envelope register it increases a certain amount and may overflow as I understand it. There's more to it than that too though. It is further described in Lord_Nightmare's GBSOUND.txt. The game I found to depend on it is "Prehistoric Man".

 

[aprentice]

wow sounds very complete, are you even missing anything?

My emu lacks sprite limiting,sound, and some compat, i need to get around to it sometime again, its not too far off from being release worthy

 

[Dark Stalker]

wow sounds very complete, are you even missing anything?

There's all the usability features like save states and video filters for one. It still lacks support for some of the rarer mbcs, and I guess compatibility will never be 100% perfect

My emu lacks sprite limiting,sound, and some compat, i need to get around to it sometime again, its not too far off from being release worthy

Looking forward to it!

 

[mono]

I made a Gameboy emulator and it runs most games, but it can't get past the opening of Altered Space due to a timing issue. It gets stuck in an infinite loop at 78A. Can anyone tell me how one determines the display mode and the number of lcd cycles there should be after the lcd is turned back on?

 

[bcrew1375]

Could you be a little more clear, what do you mean by display mode? What LCD cycles? The retrace cycles?

 

[mono]

Good point. By display mode I mean the mode in the STAT register, and by LCD cycles I mean the number of cycles remaining before the mode is switched.

In my emulator, I handle it like this. I use the term "ticks" here to refer to what I referred to as lcd cycles previously, by the way...

ticks -= cpu_cycles;

if (ticks <= 0)
{
  switch (mode)
  {
    case 0:
      ++ly;

      if (ly == 144)
      {
        mode = 1;
        ticks += 114;
      }

      mode = 2;
      ticks += 20;
      break;
    case 1:
      ++ly;

      if (ly == 154)
      {
        ly = 0;
        mode = 2;
        ticks += 20;
      }
      else
      {
        ticks += 114;
      }

      break;
    case 2:
      mode = 3;
      ticks += 43;
      break;
    case 3:
      mode = 0;
      ticks += 51;
      break;
  }
}

This is just to demonstrate what I mean, by the way. I handle the interrupt stuff as well in my real code.

What I want to know is, when the LCD is turned back on, how do I set "mode" and "ticks"?

 

[aprentice]

anyone know what the numbers in the irq demo (pd).gb mean? im getting different numbers than other emus out there

 

[ShizZy]

mono: After the VBlank period, reset LY, Set mode 2 (OAM Transfer,STAT=(STAT&0xFC)|2), request LCD interrupt, add mode 2 cycles, (20 machine cycles). And start back over.

 

[Dark Stalker]

I made a Gameboy emulator and it runs most games, but it can't get past the opening of Altered Space due to a timing issue. It gets stuck in an infinite loop at 78A.

Executing the vblank interrupt too early will get you stuck on the title screen of Altered Space.


Since I'm not fond of regressions, I'm bumping lameboy to 0.10.1 with the following changes:
- Some changes I did to the halt/interrupt system made "The Smurfs" and "Thunderbirds" stop working. This is fixed.

- Backed down some optimizations as it turns a out that Mortal Kombat 3 actually sets the SP to i/o RAM to change display settings.

- Fixed a silly bug in my DAA opcode that made the counter in Castlevania jump from 9 to 2.

- Fixed a sound initialization bug that sometimes made the sound disappear if the frequency was changed without a reset.

lameboy-0.10.1_linux_i386.tar.gz
lameboy-0.10.1_win32.zip

 

[aprentice]

Executing the vblank interrupt too early will get you stuck on the title screen of Altered Space.


Since I'm not fond of regressions, I'm bumping lameboy to 0.10.1 with the following changes:
- Some changes I did to the halt/interrupt system made "The Smurfs" and "Thunderbirds" stop working. This is fixed.

- Backed down some optimizations as it turns a out that Mortal Kombat 3 actually sets the SP to i/o RAM to change display settings.

- Fixed a silly bug in my DAA opcode that made the counter in Castlevania jump from 9 to 2.

- Fixed a sound initialization bug that sometimes made the sound disappear if the frequency was changed without a reset.

lameboy-0.10.1_linux_i386.tar.gz
lameboy-0.10.1_win32.zip

Are you requesting a vblank interrupt on line 145 to get wizards and warriors to work? I did this to get it to work but it won't go in game. I also cant get wario land 2 for gameboy mono to work, have you had this problem as well when working on your emulator? also i dunno why our numbers are so different in the irq demo

 

[Dark Stalker]

Are you requesting a vblank interrupt on line 145 to get wizards and warriors to work? I did this to get it to work but it won't go in game. I also cant get wario land 2 for gameboy mono to work, have you had this problem as well when working on your emulator? also i dunno why our numbers are so different in the irq demo

I haven't actually tested wizards and warriors until you mentioned it now I'm requesting the vblank interrupt at the start of line 144, but I'm delaying it's execution by one cycle/instruction. I suspect there may be a tiny latency on all interrupts from the moment they're requested until they're called. I can't remember having any problems with the dmg version of warioland 2, and I don't know what the numbers in the irq demo are supposed to represent.

 

[aprentice]

I haven't actually tested wizards and warriors until you mentioned it now I'm requesting the vblank interrupt at the start of line 144, but I'm delaying it's execution by one cycle/instruction. I suspect there may be a tiny latency on all interrupts from the moment they're requested until they're called. I can't remember having any problems with the dmg version of warioland 2, and I don't know what the numbers in the irq demo are supposed to represent.

is delaying it one instruction your suspicion or is it documented somewhere?

 

[Dark Stalker]

it's not documented

 

[bcrew1375]

I've been having quite an annoying problem for some time now. I've tried the suggestion of delaying interrupts, as at first I thought for sure that was it, but it
still has not solved it. Alot of games seem to have a one pixel offset in the drawing, my original suspicion was that the LYC was causing it. In a few games such as Donkey Kong, Earthworm Jim, and Zelda: Link's Awakening(Wow, I mention those games alot ), I have this problem. Donkey Kong has a problem with cutting off the last line of pixels in the status bar and the very bottom of the screen. Earthworm Jim seems to push its status bar down one pixel. I tried a fix which seemed to solve this problem for both games, but then it breaks Zelda. I'm out of ideas on how to fix it.

aprentice, I didn't have any problems with Wario Land 2, even before trying Dark Stalker's suggestion. So, I couldn't say.

Also, after looking at the code for Wizards and Warriors, I noticed it does something weird. It reads the contents of FF44 and expects them to be 0x90, but it also leaves the interrupts enabled. So, if you do immediately call the interrupt, it won't have time to read in the contents as being 0x90. By the time it gets done with the interrupt routine, it's probably already past line 0x90.

 

[ShizZy]

Rewrote my entire emulator, now uses DirectX and is much quicker. Now in the process of debugging. Does anyone have any ideas of what could be going wrong in the following screenshot? (Asteroids) It doesn't show the startup logo, but after a few seconds this titlescreen fades in. I traced through the opcodes, and it breaks after opcode 0x22 (changes from that of other emulators). This was in a loop, I checked every opcode from that point to the beginning of the emulation. All seem to be correct, which leads me to believe it is something wrong with IO. Might be stat, but I'm not sure - I've double and triple checked that already. Any ideas?

 

[bcrew1375]

Well, that is the opcode to load a 16-bit register's value into memory, so maybe the register is trying to load somewhere into memory it shouldn't? Where is it trying to write to?

 

[TJA]

Hi all I've finally got off my arse and decided to start my gameboy emulator today, I'm going well I think just coding lots of opcodes so far but have a question. When the documentation for the cpu for an opcode such as ADC A, n for example is copying (HL) does it mean because the regester is in brakets that it holds an address to be read from memory and then copyed into A, this makes more sense than my original though that I simply copy the 16-bit register to the 8-bit one