Would be great if this core got the Srg320 treatment.

User avatar
SegaSnatcher
Posts: 163
Joined: Sun May 24, 2020 9:18 pm
Has thanked: 36 times
Been thanked: 43 times

Would be great if this core got the Srg320 treatment.

Unread post by SegaSnatcher »

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
mario64
Posts: 119
Joined: Sun May 24, 2020 6:50 pm
Has thanked: 18 times
Been thanked: 10 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by mario64 »

I second this request
Lancelot
Posts: 29
Joined: Mon May 25, 2020 4:56 am
Location: Campinas
Has thanked: 1 time
Contact:

Re: Would be great if this core got the Srg320 treatment.

Unread post by Lancelot »

Yes, GB and GBC definitely needs a better treatment.
vanfanel
Posts: 119
Joined: Sun May 24, 2020 6:53 pm
Has thanked: 9 times
Been thanked: 20 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by vanfanel »

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.
User avatar
Sorgelig
Site Admin
Posts: 877
Joined: Thu May 21, 2020 9:49 pm
Has thanked: 2 times
Been thanked: 211 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by Sorgelig »

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.
User avatar
SegaSnatcher
Posts: 163
Joined: Sun May 24, 2020 9:18 pm
Has thanked: 36 times
Been thanked: 43 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by SegaSnatcher »

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.
mario64
Posts: 119
Joined: Sun May 24, 2020 6:50 pm
Has thanked: 18 times
Been thanked: 10 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by mario64 »

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
User avatar
SegaSnatcher
Posts: 163
Joined: Sun May 24, 2020 9:18 pm
Has thanked: 36 times
Been thanked: 43 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by SegaSnatcher »

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.
Ashenshards
Posts: 6
Joined: Fri Jun 05, 2020 1:10 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by Ashenshards »

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.
FPGAzumSpass
Core Developer
Posts: 380
Joined: Sat May 23, 2020 12:55 pm
Has thanked: 38 times
Been thanked: 383 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by FPGAzumSpass »

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.
User avatar
Cebion
Posts: 115
Joined: Sun May 24, 2020 7:30 pm
Has thanked: 1 time
Been thanked: 3 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by Cebion »

Kudos for your work FPGAzumSpass.
Your work is really awesome,keep up your awesomeness =)
brNX
Posts: 12
Joined: Thu Jun 18, 2020 1:50 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by brNX »

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
User avatar
bootsector
Posts: 162
Joined: Sun May 24, 2020 6:58 pm
Has thanked: 4 times
Been thanked: 30 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by bootsector »

It's great to see you back, brNX!!
paulbnl
Core Developer
Posts: 205
Joined: Sun May 24, 2020 8:48 pm
Has thanked: 18 times
Been thanked: 196 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by paulbnl »

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.
brNX
Posts: 12
Joined: Thu Jun 18, 2020 1:50 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by brNX »

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
paulbnl
Core Developer
Posts: 205
Joined: Sun May 24, 2020 8:48 pm
Has thanked: 18 times
Been thanked: 196 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by paulbnl »

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.
brNX
Posts: 12
Joined: Thu Jun 18, 2020 1:50 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by brNX »

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.
User avatar
SegaSnatcher
Posts: 163
Joined: Sun May 24, 2020 9:18 pm
Has thanked: 36 times
Been thanked: 43 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by SegaSnatcher »

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.
Lancelot
Posts: 29
Joined: Mon May 25, 2020 4:56 am
Location: Campinas
Has thanked: 1 time
Contact:

Re: Would be great if this core got the Srg320 treatment.

Unread post by Lancelot »

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.
brNX
Posts: 12
Joined: Thu Jun 18, 2020 1:50 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by brNX »

@paulbnl You saved megaman xtreme :) Thank you
User avatar
wark91
Core Developer
Posts: 334
Joined: Sun May 24, 2020 8:34 pm
Has thanked: 447 times
Been thanked: 94 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by wark91 »

Thank you @paulbnl and @brnx !
paulbnl
Core Developer
Posts: 205
Joined: Sun May 24, 2020 8:48 pm
Has thanked: 18 times
Been thanked: 196 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by paulbnl »

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.
brNX
Posts: 12
Joined: Thu Jun 18, 2020 1:50 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by brNX »

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.
User avatar
Newsdee
Top Contributor
Posts: 830
Joined: Mon May 25, 2020 1:07 am
Has thanked: 98 times
Been thanked: 209 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by Newsdee »

Great job on the improvements, brNX and paulbnl!
LeftEmpty
Posts: 141
Joined: Sun May 24, 2020 6:47 pm
Has thanked: 2 times
Been thanked: 4 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by LeftEmpty »

Can't thank both of you enough indeed!
mario64
Posts: 119
Joined: Sun May 24, 2020 6:50 pm
Has thanked: 18 times
Been thanked: 10 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by mario64 »

Yes. Thank you so much for these improvements!
User avatar
SegaSnatcher
Posts: 163
Joined: Sun May 24, 2020 9:18 pm
Has thanked: 36 times
Been thanked: 43 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by SegaSnatcher »

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?
Mills
Posts: 83
Joined: Mon Jun 08, 2020 2:52 pm
Has thanked: 15 times
Been thanked: 29 times

Re: Would be great if this core got the Srg320 treatment.

Unread post by Mills »

Awesome improvements!

I tested several demos with lots of weird effects, and they were nearly perfect, :).
User avatar
maniac79
Posts: 2
Joined: Mon May 25, 2020 9:55 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by maniac79 »

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! :)
50% of the NES Commando (German YouTube duo).
Check us out, we stream retro games with MiSTer: https://youtube.com/c/nescommando
brNX
Posts: 12
Joined: Thu Jun 18, 2020 1:50 pm

Re: Would be great if this core got the Srg320 treatment.

Unread post by brNX »

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
Post Reply