MiSTer FPGA Forum

Considering how important Gameboy/Gameboy Color system is I believe it deserves the same kind of love other cores have seen like Genesis, NES, SNES, Neo-Geo, GBA, Turbografx 16, etc.

Srg320 has done some truly wonderful things on the MiSTer platform, from developing his own cores to rewriting parts of cores that were initially developed by others and if he was currently thinking of what his next project on MiSTer could be I hope he considers fixing the Gameboy core up. I believe BrNX said the Gameboy core could probably use a rewritten PPU.

The original Gameboy core seems to be in pretty decent enough shape though still less accurate than the best GB emulators out there, but the Gameboy color could definitely use more work. Here is what Great Hierophant said about the Gameboy core on his Nerdly Pleasures blog.

"Game Boy & Game Boy Color

The Game Boy core is also good, but not up to the standard of the most accurate Game Boy emulators like gambatte and bgb. Many games will play without issue but you can expect some glitchy lines at times like in Castlevania II. Games like Pinball Illusions and Pinball Mania will crash and Super Mario Land's timer countdown is wrong. The Game Boy core has just acquired support for 15KHz CRTs but a firmware update has yet to be released.

The Game Boy Color core is okay until you get to anything which uses the Hi-color graphics capabilities. Then things break. Hi-color is used in GBC games more often than you might think."

I know Srg320 is still prioritizing TG-16/CD right now, but just talking sometime in the future if he's interested would be greatly appreciated by many users who enjoy Gameboy games. Thanks

I second this request

Yes, GB and GBC definitely needs a better treatment.

I also second this, yes.
A good test case is "Super Hunchback" tittle screen, where this core shows line problems. And the game stays there as long as you want, so it could be useful for debugging.

MiSTer is open source and hobby project. You can't request what specific developer should do. What is interesting for you might be out of interest for specific developer. srg320 has no plans for Gameboy core, so don't expect too much.
Open source should encourage curious people to start to develop, especially the things they really want to improve.

Sorgelig wrote: ↑Sun May 31, 2020 12:08 pm MiSTer is open source and hobby project. You can't request what specific developer should do. What is interesting for you might be out of interest for specific developer. srg320 has no plans for Gameboy core, so don't expect too much.
Open source should encourage curious people to start to develop, especially the things they really want to improve.

Oh, just to be clear I'm not making any demands or anything, just saying it would be very welcomed as it doesn't seem like anyone else is interested. The Gameboy core has been kinda neglected for a good year, at least in terms of really in depth commits to make the core more accurate. If nothing else maybe this thread will inspire other developers to take this core on and help make it better as I feel it really deserves it. Gameboy is one of the most successful and important game systems of our time.

SegaSnatcher wrote: ↑Sun May 31, 2020 7:53 pm

Sorgelig wrote: ↑Sun May 31, 2020 12:08 pm MiSTer is open source and hobby project. You can't request what specific developer should do. What is interesting for you might be out of interest for specific developer. srg320 has no plans for Gameboy core, so don't expect too much.
Open source should encourage curious people to start to develop, especially the things they really want to improve.

Oh, just to be clear I'm not making any demands or anything, just saying it would be very welcomed as it doesn't seem like anyone else is interested. The Gameboy core has been kinda neglected for a good year, at least in terms of really in depth commits to make the core more accurate. If nothing else maybe this thread will inspire other developers to take this core on and help make it better as I feel it really deserves it. Gameboy is one of the most successful and important game systems of our time.

Not only that but on the old Atari forum there was a post from the main developer where he said he doesn’t expect to work on the GB core again until next year

mario64 wrote: ↑Mon Jun 01, 2020 3:39 am

SegaSnatcher wrote: ↑Sun May 31, 2020 7:53 pm

Sorgelig wrote: ↑Sun May 31, 2020 12:08 pm MiSTer is open source and hobby project. You can't request what specific developer should do. What is interesting for you might be out of interest for specific developer. srg320 has no plans for Gameboy core, so don't expect too much.
Open source should encourage curious people to start to develop, especially the things they really want to improve.

Oh, just to be clear I'm not making any demands or anything, just saying it would be very welcomed as it doesn't seem like anyone else is interested. The Gameboy core has been kinda neglected for a good year, at least in terms of really in depth commits to make the core more accurate. If nothing else maybe this thread will inspire other developers to take this core on and help make it better as I feel it really deserves it. Gameboy is one of the most successful and important game systems of our time.

Not only that but on the old Atari forum there was a post from the main developer where he said he doesn’t expect to work on the GB core again until next year

Yeah BrNX has been on hiatus for quite awhile. If he comes back to develop again that will be great, but I'd rather not assume he will come back, which is why I made this thread.

I'd rather see Robert Piep's GB / GBC on MiSTer as an alternative or eventual replacement. Just my opinion, based on the work that he has done so far with GBA and DS, and the issues of the current GB/GBC core in comparison. Also, a developer wouldn't have to begin from scratch, there is already some framework at least capable of running some titles.

My own GB/C core is roughly in the shape of the GBA core at release: it has bugs, it's inaccurate and all the newer features like savestates and cheats are missing.
At least it already has working Fastforward.

I would really like to work on GB/C again after DS (whenever that will be...) if noone will do it before.
However, i feel like this core has to be very good from the beginning or people will not test/use it, but tests are a hard requirement to get it good, so it's a tough start.

At least GB/C has lots of testroms and very accurate emulators. Both help a lot.

Kudos for your work FPGAzumSpass.
Your work is really awesome,keep up your awesomeness =)

Hi

first of all sorry for being away for a while, if nobody picked up the core (@Sorgelig) I'm thinking of spending some time on it again,
but no promises, I can only give it the brNX treatment.

@FPGAzumSpass, as I said it before on multiple channels, I'm definitely open to some help, there are a lot of gameboy experts out there that could chime in (I'm definitely no expert on the matter)

Before going on hiatus I managed to put together a simulation workbench (https://github.com/brNX/Gameboy_MiSTer/ ... i_sdl_tv80) using verilator, sdl and imgui. I then added the core parts from Sameboy (the very accurate emulator from LIJI32) to make them run side by side and compared the results.
So my next step is to spend some time on it, corner cases like the super hunchback intro screen are very helpful, especially if they show up without user input at the beginning of a game(thanks @vanfanel btw, I spent some time trying to fix it but as it was inconsistent, one frame was fine the next one messed up, it was difficult to track down , I gave up and then implemented said simulation workbench to help).

As usual no promisses, this is a hobby and somewhat a challenge

Regards

Bruno aka brNX

It's great to see you back, brNX!!

I have spent some time improving the PPU timings to make it more accurate to a real Gameboy. Pausing when fetching sprites for example.

Also fixed issues with HDMA and STAT irqs and OAM dma. Almost all games are fixed in the issue tracker.

Super Hunchback writes to SCX/SCY in an LYC interrupt just barely before mode 3 starts. The LYC interrupt triggers at the start of mode 2 so it only has 80 PPU cycles to write to the scroll registers. I am thinking that maybe the CPU takes too long to jump to the irq vector.

@brNX You have spent some time fixing the CPU. The Konami collections use a STOP opcode (10h) with a following FF byte. The GB CPU should skip the byte after the STOP opcode otherwise the CPU gets stuck.

Also for Pinball Fantasies the CPU should read the interrupt vector after writing the current PC to the stack just before jumping to the irq vector. Currently it reads the irq vector first and then writes the PC to the stack and then jumps to the irq vector.

I will send a pull request with my changes soon.

paulbnl wrote: ↑Thu Jun 18, 2020 5:22 pm I have spent some time improving the PPU timings to make it more accurate to a real Gameboy. Pausing when fetching sprites for example.

Also fixed issues with HDMA and STAT irqs and OAM dma. Almost all games are fixed in the issue tracker.

Super Hunchback writes to SCX/SCY in an LYC interrupt just barely before mode 3 starts. The LYC interrupt triggers at the start of mode 2 so it only has 80 PPU cycles to write to the scroll registers. I am thinking that maybe the CPU takes too long to jump to the irq vector.

@brNX You have spent some time fixing the CPU. The Konami collections use a STOP opcode (10h) with a following FF byte. The GB CPU should skip the byte after the STOP opcode otherwise the CPU gets stuck.

Also for Pinball Fantasies the CPU should read the interrupt vector after writing the current PC to the stack just before jumping to the irq vector. Currently it reads the irq vector first and then writes the PC to the stack and then jumps to the irq vector.

I will send a pull request with my changes soon.

I'm happy to hear @paulbnl and excellent work.

Yes I suspected that IRQ jump too, but somehow most of the test roms passed on that one and I couldn't replicate it with consistency, I will continue to work on my testbench with sameboy as something to be compared to, maybe that can help find more bugs that are intermittent of take a long time to find.

I thought that the stop opcode bug was already passing the tests but I may have skipped that one at the time or confusing it with the halt one.

From the top of my head one of the biggest changes that still need to be made is how the PPU handles the STOP opcode, there's a difference between the DMG and GBC, in one of them the PPU doesn't advance in stop mode the other does (not sure which one does what yet).

I'll certainly have a look at the STOP opcode, should be an "easy" fix.

edit: nice catch on the bug it's something I wouldn't expect at this point at all, just confirmed the location with BGB

brNX wrote: ↑Thu Jun 18, 2020 6:38 pm Yes I suspected that IRQ jump too, but somehow most of the test roms passed on that one and I couldn't replicate it with consistency, I will continue to work on my testbench with sameboy as something to be compared to, maybe that can help find more bugs that are intermittent of take a long time to find.

Here is a difference that I found compared to BGB. https://i.imgur.com/eiwpLH7.png

At the interrupt address 0048 the push af instruction should take 4 Mcycles according to BGB but the core takes 5 Mcycles.

Here with a Mooneye test rom something similar happens. https://i.imgur.com/is8SPHk.png

According to the test source the interrupt vector should take 8 Mcycles.
https://github.com/Gekkio/mooneye-gb/bl ... g-GS.s#L68

As seen in the screenshot it also takes 8 cycles with BGB but the core takes 9 cycles. The ret opcode takes 5 cycles instead of 4 because it stays at adress 004A for 2 cycles instead of 1. Though a few nops later it does take 4 cycles for another ret opcode so it has something to do with the interrupt.

That's interesting, the same seems to happen in simulation (at least the glitches look to be the same in Super hunchback, I'll have to check) and I'm using the tv80 core (verilog clone of t80) there with my fixes backported. The issue could be in one of 2 places , the glue code in gb.v to trigger the interrupt or (and probably likely) how the interrupts are handled in t80/tv80 (they are different from the z80 so that part was probably long untested).

paulbnl wrote: ↑Sat Jun 20, 2020 12:09 pm Though a few nops later it does take 4 cycles for another ret opcode so it has something to do with the interrupt.

So jumps should be fine, but not those triggered by an interrupt right ? So the timing should be correct on the ret opcode.

I'll have a look as soon as a find the time for this, again good job narrowing it down, that's usually the time sink.

Btw we should probably open a new thread.

paulbnl wrote: ↑Sat Jun 20, 2020 12:09 pm

brNX wrote: ↑Thu Jun 18, 2020 6:38 pm Yes I suspected that IRQ jump too, but somehow most of the test roms passed on that one and I couldn't replicate it with consistency, I will continue to work on my testbench with sameboy as something to be compared to, maybe that can help find more bugs that are intermittent of take a long time to find.

Here is a difference that I found compared to BGB. https://i.imgur.com/eiwpLH7.png

At the interrupt address 0048 the push af instruction should take 4 Mcycles according to BGB but the core takes 5 Mcycles.

Here with a Mooneye test rom something similar happens. https://i.imgur.com/is8SPHk.png

According to the test source the interrupt vector should take 8 Mcycles.
https://github.com/Gekkio/mooneye-gb/bl ... g-GS.s#L68

As seen in the screenshot it also takes 8 cycles with BGB but the core takes 9 cycles. The ret opcode takes 5 cycles instead of 4 because it stays at adress 004A for 2 cycles instead of 1. Though a few nops later it does take 4 cycles for another ret opcode so it has something to do with the interrupt.

I tested a compiled core with your fixes and thought maybe you'd like some feedback.

Chikyuu Kaihou Gun ZAS now has the 2nd scrolling layer, but the whole game is super flickery now. The current official core doesn't have the 2nd scrolling layer, but it doesn't flicker.

Final Fantasy Adventure Menu Cursor issue is fixed.

Alone in the Dark for Gameboy Color is much improved, but there is some junk in between screen transitions.

Pinball Fantasies actually lets you launch the ball now and play for awhile, but ends up crashing, but still an improvement over official current core.

Gameboy:
- Many fixes from paulb-nl
- CPU opcode fix from brnx
- Option to disable link. Super gameboy mode disable by default
- Update the framework

Thank you for the update, paulb-nl and brnx, this fixed graphical glitches in some games here like Aladdin and Aliens. Probably others too.

@paulbnl You saved megaman xtreme Thank you

Thank you @paulbnl and @brnx !

SegaSnatcher wrote: ↑Mon Jun 22, 2020 11:31 am
Alone in the Dark for Gameboy Color is much improved, but there is some junk in between screen transitions.

Pinball Fantasies actually lets you launch the ball now and play for awhile, but ends up crashing, but still an improvement over official current core.

The junk with screen transitions is probably because a Gameboy normally does not show the first frame after the LCD is enabled which is not yet emulated.

Pinball Fantasies relies on a specific way of handling of interrupts by the CPU which is not yet fixed.

brNX wrote: ↑Mon Jun 22, 2020 4:47 pm @paulbnl You saved megaman xtreme Thank you

That was a silly bug OAM dma would overwrite a part at $CExx when it was writing to $FExx.

paulbnl wrote: ↑Mon Jun 22, 2020 8:33 pm

brNX wrote: ↑Mon Jun 22, 2020 4:47 pm @paulbnl You saved megaman xtreme Thank you

That was a silly bug OAM dma would overwrite a part at $CExx when it was writing to $FExx.

I went through most issues over on github, the latest version fixed most of those , awesome work on the PPU.

The smurfs issue has potential to be interesting (or silly), it still hangs right on the nintendo logo.

Great job on the improvements, brNX and paulbnl!

Can't thank both of you enough indeed!

Yes. Thank you so much for these improvements!

Yes, all these fixes are greatly appreciated and makes this core that much closer to where it deserves to be.

Though I wonder, are most of the remaining bugs mainly PPU or CPU issues?

Awesome improvements!

I tested several demos with lots of weird effects, and they were nearly perfect, .

I‘m very happy to see active development here and immediately noticed vast improvements in Castlevania 1 on GB.
Gone is the messy timer on top and when climbing a rope from one screen up to another, the sprite is correctly drawn.
Amazing!
I noticed some serious screen tearing though when moving the character from left to right. I was wondering if this is something that is known and/or can/should be fixed or if this just „works as designed“?

Thanks for the great work, it‘s much appreciated!

maniac79 wrote: ↑Sun Jun 28, 2020 7:24 pm I‘m very happy to see active development here and immediately noticed vast improvements in Castlevania 1 on GB.
Gone is the messy timer on top and when climbing a rope from one screen up to another, the sprite is correctly drawn.
Amazing!
I noticed some serious screen tearing though when moving the character from left to right. I was wondering if this is something that is known and/or can/should be fixed or if this just „works as designed“?

Thanks for the great work, it‘s much appreciated!

https://github.com/MiSTer-devel/Gameboy ... -647822794

Castlevania 1 is a glitchy and slow game unfortunately