Would be great if this core got the Srg320 treatment.
- 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.
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
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
Re: Would be great if this core got the Srg320 treatment.
Yes, GB and GBC definitely needs a better treatment.
Re: Would be great if this core got the Srg320 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.
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.
- Sorgelig
- Site Admin
- Posts: 886
- Joined: Thu May 21, 2020 9:49 pm
- Has thanked: 2 times
- Been thanked: 212 times
Re: Would be great if this core got the Srg320 treatment.
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.
Open source should encourage curious people to start to develop, especially the things they really want to improve.
- 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.
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.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.
Re: Would be great if this core got the Srg320 treatment.
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 yearSegaSnatcher wrote: ↑Sun May 31, 2020 7:53 pmOh, 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.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.
- 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.
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.mario64 wrote: ↑Mon Jun 01, 2020 3:39 amNot 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 yearSegaSnatcher wrote: ↑Sun May 31, 2020 7:53 pmOh, 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.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.
-
- Posts: 6
- Joined: Fri Jun 05, 2020 1:10 pm
Re: Would be great if this core got the Srg320 treatment.
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.
-
- Core Developer
- Posts: 382
- Joined: Sat May 23, 2020 12:55 pm
- Has thanked: 38 times
- Been thanked: 407 times
Re: Would be great if this core got the Srg320 treatment.
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.
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.
Re: Would be great if this core got the Srg320 treatment.
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
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
- bootsector
- Posts: 163
- Joined: Sun May 24, 2020 6:58 pm
- Has thanked: 4 times
- Been thanked: 30 times
-
- Core Developer
- Posts: 206
- 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.
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.
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.
Re: Would be great if this core got the Srg320 treatment.
I'm happy to hear @paulbnl and excellent work.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.
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
-
- Core Developer
- Posts: 206
- 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.
Here is a difference that I found compared to BGB. https://i.imgur.com/eiwpLH7.pngbrNX 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.
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.
Re: Would be great if this core got the Srg320 treatment.
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).
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.
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.
- 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.
I tested a compiled core with your fixes and thought maybe you'd like some feedback.paulbnl wrote: ↑Sat Jun 20, 2020 12:09 pmHere is a difference that I found compared to BGB. https://i.imgur.com/eiwpLH7.pngbrNX 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.
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.
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.
Re: Would be great if this core got the Srg320 treatment.
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.
- 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.
Re: Would be great if this core got the Srg320 treatment.
@paulbnl You saved megaman xtreme
Thank you
![Smile :)](./images/smilies/icon_e_smile.gif)
-
- Core Developer
- Posts: 206
- 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.
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.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.
Pinball Fantasies relies on a specific way of handling of interrupts by the CPU which is not yet fixed.
That was a silly bug
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Would be great if this core got the Srg320 treatment.
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.
- Newsdee
- Top Contributor
- Posts: 830
- Joined: Mon May 25, 2020 1:07 am
- Has thanked: 99 times
- Been thanked: 209 times
Re: Would be great if this core got the Srg320 treatment.
Great job on the improvements, brNX and paulbnl!
- 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.
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?
Though I wonder, are most of the remaining bugs mainly PPU or CPU issues?
Re: Would be great if this core got the Srg320 treatment.
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!![Smile :)](./images/smilies/icon_e_smile.gif)
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!![Smile :)](./images/smilies/icon_e_smile.gif)
Gone is the messy timer on top and when climbing a rope from one screen up to another, the sprite is correctly drawn.
Amazing!
![Smile :)](./images/smilies/icon_e_smile.gif)
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!
![Smile :)](./images/smilies/icon_e_smile.gif)
50% of the NES Commando (German YouTube duo).
Check us out, we stream retro games with MiSTer: https://youtube.com/c/nescommando
Check us out, we stream retro games with MiSTer: https://youtube.com/c/nescommando
Re: Would be great if this core got the Srg320 treatment.
https://github.com/MiSTer-devel/Gameboy ... -647822794maniac79 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!![]()
Castlevania 1 is a glitchy and slow game unfortunately