strange output on blargg tests

Discussion of programming and development for the original Game Boy and Game Boy Color.
Post Reply
theotherjim
Posts: 6
Joined: Sun May 17, 2015 2:14 pm
Location: seattle

strange output on blargg tests

Post by theotherjim » Sun May 31, 2015 3:56 pm

Hi all,

I'm getting some bizarre output running the individual roms for blargg's cpu tests. At the end of the test run when (I assume) all the tests pass, I get output like:

Code: Select all

Passed
Failed #10L
Image

Any ideas what might be causing it?

Also, running the full cpu_tests.gb rom shows strange behavior:

Image

Any feedback or things to check would be appreciated.

Shonumi
Posts: 315
Joined: Sun Jan 26, 2014 9:31 am

Re: strange output on blargg tests

Post by Shonumi » Wed Jun 03, 2015 9:45 am

Hard to say. Could be rendering issue, or something to do with your CPU emulation (...which in turn would cause a rendering issue). Have you tried running other test ROMs for basic graphical output (or for that matter, commercial ROMs?) I would suggest trying Imran Nazar's Opus 5 demo (https://github.com/Two9A/jsGB/tree/master/tests). It's what I cut my teeth on way back when I started GB/GBC emulation. Try to at least get that displaying the BG correctly, then move on to several title screens for commercial games. Super Mario Land, Tetris are good ones to start with, since they don't really do anything fancy before displaying things on-screen.

Also, for individual tests, it should be easy enough to run it through a debugger (look into BGB) and see if you're doing everything correctly. If not, then you definitely have a CPU issue, and you should look into what behavior the test considers accurate. Of course, you should have a debugger in your own emulator. If not, code one right away! I can't stress enough how important this is ;)

theotherjim
Posts: 6
Joined: Sun May 17, 2015 2:14 pm
Location: seattle

Re: strange output on blargg tests

Post by theotherjim » Thu Jun 04, 2015 8:40 am

The Opus5 demo is definitely exposing some issues. It looks like I have some graphical issues to sort out first. (ship appears many times in the background) Then apparently quite a bit of other work too as the background is scrolling (oddly) non-stop. Definitely going to work on a debugger first though. I've just been using xcode as my primary debugger, but it clearly doesn't supply all the information I need to properly work through this. I'll take a look at bgb. Thanks!

User avatar
Dwedit
Posts: 4273
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: strange output on blargg tests

Post by Dwedit » Thu Jun 04, 2015 9:01 pm

Opus5 appears to be quite buggy. On VisualBoyAdvance you can see lots of discontinuities if you scroll diagonally.
It appears to look fine on NO$GMB though. In BGB, it crashes at an invalid opcode after jumping to ram or echo ram.

I can't recommend use of buggy test programs for testing emulators.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Shonumi
Posts: 315
Joined: Sun Jan 26, 2014 9:31 am

Re: strange output on blargg tests

Post by Shonumi » Fri Jun 05, 2015 12:01 am

Those discontinuities are present on real hardware. If it appears fine in NO$GMB, it's inaccurate emulation. BGB shouldn't crash if real hardware doesn't either. VBA-M gets it correct in this case (well, almost, the irregularities should have a staircase pattern on real hardware). I would imagine Gambatte works too, but I haven't built it in a while.

The purpose of Opus 5, for those beginning to write a GB emulator, is just to test fundamental BG rendering. Pop it open in your emulator; if you don't see asteroids, you know you have core issues with LCD emulation. Since it actually does have some unique scrolling quirks, it's probably a better judge of accurate LCD emulation than other "basic" demos.

telliott
Posts: 1
Joined: Sat Feb 09, 2019 11:40 pm

Re: strange output on blargg tests

Post by telliott » Sat Feb 09, 2019 11:46 pm

I was seeing the same thing on my emulator project and in my case this was because I had the carry flag behavior reversed for the CP instruction (see this post on StackOverflow).

Because CP was setting the carry flag incorrectly, a JP C call following CP wasn't jumping as expected, and the flow dropped into failure output, so both "Passed" and "Failed" were being output during the exit routine.

Post Reply