Gameboy core

[Sorgelig]

yes, it seems some regression present. Dec 2 release has all enemies. Releases after that till the latest don't want to load the Xenon 2 at all (no reaction on rom loading).

[slingshot]

yes, it seems some regression present. Dec 2 release has all enemies. Releases after that till the latest don't want to load the Xenon 2 at all (no reaction on rom loading).

Ah, ok. Back to C64 then.

[brNX]

I've made an attempt to backport the MiSTer changes to MiST. But I realized that something is odd with sprites, e.g. in Xenon 2, many of the enemies are invisible with the MiSTer version (easy to see at the first stage, e.g. the worms here:
https://youtu.be/ZR9Va4090Nk?t=109
Totally invisible, but kill you.
Is it OK and I made a mistake during the port?

yes, it seems some regression present. Dec 2 release has all enemies. Releases after that till the latest don't want to load the Xenon 2 at all (no reaction on rom loading).

Hi,
feel free to open an issue on github, it is probably the best place to track that, I've been thinking about adding the known issues to it but haven't had the opportunity to do it yet.
I've been looking into timing bugs and already found a few things that are off, the sprites bug could be related to the new GBC flags that should be ignored in GB mode.

Cheers

edit: added https://github.com/MiSTer-devel/Gameboy ... /issues/28
edit2 : xenon 2 loads fine @sorgelig with fast boot disabled... , that feature should probably be removed what do you think ?
edit3: the sprite regression was added in version Gameboy_20181229.rbf, when adding GBC, it plays fine with Gameboy_20181211.rbf

[brNX]

yes, it seems some regression present. Dec 2 release has all enemies. Releases after that till the latest don't want to load the Xenon 2 at all (no reaction on rom loading).

Ah, ok. Back to C64 then.

PR sent https://github.com/MiSTer-devel/Gameboy_MiSTer/pull/29 that fixes xenon 2, thanks for reporting it.

Cheers

[slingshot]

PR sent https://github.com/MiSTer-devel/Gameboy_MiSTer/pull/29 that fixes xenon 2, thanks for reporting it.

Cheers

Great, it works on MiST, too. One issue remained, the percussions of the music is heavily distorted (Xenon 2). Maybe that's what you refer in the github issue (sound crackling and noise in wave channel)? Or the DAC has overdriven here.

[slingshot]

Is this correct?

Code: Select all

wire [6:0] mbc2_rom_bank = mbc_rom_bank_reg[6:0] & rom_mask[6:0];  //16

As I read, mbc2 has max. 256kb ROM (16 pages), the rom bank register shouldn't be 4 bits only? Now it's the same as MBC1.

[brNX]

Is this correct?

Code: Select all

wire [6:0] mbc2_rom_bank = mbc_rom_bank_reg[6:0] & rom_mask[6:0];  //16

As I read, mbc2 has max. 256kb ROM (16 pages), the rom bank register shouldn't be 4 bits only? Now it's the same as MBC1.

Hi,

you are probably right, more than likely a forgotten copy paste but it should be "ok" because of the rom_mask.

Code: Select all

(cart_rom_size == 3)? 9'b000001111:  // 3 - 16 banks = 256k

I have to check xenon 2 against the original hardware, didn't notice anything while testing but I'm not familiar with the game.

[slingshot]

I have to check xenon 2 against the original hardware, didn't notice anything while testing but I'm not familiar with the game.

Forget it, was just about signed vs unsigned samples.

[brNX]

I have to check xenon 2 against the original hardware, didn't notice anything while testing but I'm not familiar with the game.

Forget it, was just about signed vs unsigned samples.

Good to know .
Btw I'm glad you're "backporting" the updates to the MiST.

[slingshot]

I have to check xenon 2 against the original hardware, didn't notice anything while testing but I'm not familiar with the game.

Forget it, was just about signed vs unsigned samples.

Good to know .
Btw I'm glad you're "backporting" the updates to the MiST.

It can be relaxing if somebody else already did the debugging part

[bitfan2011]

we were messing around with random GBC games and it's surprising now nice they look
i use the HDMI output with integer and some mild scanlines (looks a lil too harsh with no filtering)
is there a filter which accurately represents the original GB pixels? they kind of have a thin border around each pixel IIRC
thanks!!

[kitrinx]

we were messing around with random GBC games and it's surprising now nice they look
i use the HDMI output with integer and some mild scanlines (looks a lil too harsh with no filtering)
is there a filter which accurately represents the original GB pixels? they kind of have a thin border around each pixel IIRC
thanks!!

You could always try the LCD filters.

https://github.com/MiSTer-devel/Filters ... er/Filters

[slingshot]

Just one thought: what about using isGBC_game instead of isGBC in many places? isGBC_game is not used at all now, and I presume it would allow more mono games running correctly in color mode (like the previously mentioned Xenon2).

[brNX]

we were messing around with random GBC games and it's surprising now nice they look
i use the HDMI output with integer and some mild scanlines (looks a lil too harsh with no filtering)
is there a filter which accurately represents the original GB pixels? they kind of have a thin border around each pixel IIRC
thanks!!

we were messing around with random GBC games and it's surprising now nice they look
i use the HDMI output with integer and some mild scanlines (looks a lil too harsh with no filtering)
is there a filter which accurately represents the original GB pixels? they kind of have a thin border around each pixel IIRC
thanks!!

You could always try the LCD filters.

https://github.com/MiSTer-devel/Filters ... er/Filters

my vote goes to the LCD filters too, it looks soooo good

[brNX]

Just one thought: what about using isGBC_game instead of isGBC in many places? isGBC_game is not used at all now, and I presume it would allow more mono games running correctly in color mode (like the previously mentioned Xenon2).

isGBC_game is leftover code, I wasn't sure if I needed to check for it and do something different, I left if because it could still be useful, it comes from parsing the rom header, color palettes in GB (aka black and white) games are loaded from the GBC bootrom, so using isGBC_game is the wrong thing to do in this case. I still have to check why GB games like xenon2 and others display the wrong palettes when played in (forced) GBC mode, the palettes are loaded, you can check it pressing the button combinations just like in a real GBC during boot-up but often the sprites look wrong. But it's not really my priority at the moment.

I have been trying to hunt timing problems, I've been making slow progress, already found a few opcodes that need fixing and the PPU has wrong timings (Mode 3 should be at least 172 cycles long is 160 at the moment, among other things), I want to have the timings solid before going back to other things as it could affect (and it is) many games.

[slingshot]

I understand. I see timing issues, too, in some games it's very obvious so good if you work on this.

[deltax5]

Would it possible to make a link cable usb adapter and implement it in the gameboy core? I know it's kinda ridicules but I want to know if it would be possible to trade my pokemons and play multiplayer. Or even add it to the io.

[slingshot]

@brNX
Just tried the new updates on MiST. Is Aladdin title screen supposed to be still garbled on MiSTer, too?

And probably a mistake with the assignment (not confident in the code, so not sure):
https://github.com/MiSTer-devel/Gameboy ... deo.v#L389

[vanfanel]

@slingshot: Super Hunchback tittle screen still looks garbled, too

[brNX]

@brNX
Just tried the new updates on MiST. Is Aladdin title screen supposed to be still garbled on MiSTer, too?

And probably a mistake with the assignment (not confident in the code, so not sure):
https://github.com/MiSTer-devel/Gameboy ... deo.v#L389

Hi ,

yes super hunchback and probably aladdin are still having the same issue , you can check my PR text here about it https://github.com/MiSTer-devel/Gameboy_MiSTer/pull/31, tl;dr the core has the cpu and ppu synced now and is cycle accurate, the problem is probably related to the background and window scroll registers, the zelda oracle games scroll issues in the intro confirm that too.

The line you showed looks ok to me , stage2 is when the core processes the sprites , in mode 3 , you only want to do it outside of vblank.

[brNX]

Would it possible to make a link cable usb adapter and implement it in the gameboy core? I know it's kinda ridicules but I want to know if it would be possible to trade my pokemons and play multiplayer. Or even add it to the io.

Yes, catskull over on github opened an issue with it (https://github.com/MiSTer-devel/Gameboy ... /issues/19), it's doable but not a priority for now, at least for me.

Cheers

edit: yes , the usb io port would be the way to go

[slingshot]

The line you showed looks ok to me , stage2 is when the core processes the sprites , in mode 3 , you only want to do it outside of vblank.

I've just referred to the blocking vs unblocking assignment.

But at least the bugs are not from a MiST port mistake

[brNX]

The line you showed looks ok to me , stage2 is when the core processes the sprites , in mode 3 , you only want to do it outside of vblank.

I've just referred to the blocking vs unblocking assignment.

But at least the bugs are not from a MiST port mistake

oh , yes , I will have to check that out with signaltap, should be okay.
And yes , not from the port , I will have a look at Shantae this weekend and will have to look at that code after that too.~

It's the last remaining big bug ...

Cheers

[uigiflip]

just wondered if any1 is working on gameboy advanced core yet? ok found info on this http://www.atari-forum.com/viewtopic.php?f=117&t=34809

[brNX]

Hi

heads-up for those that didn't see it, added a workaround to the README to enable analog out (15KHz) for now until a better solution is found/implemented
have fun.

https://github.com/MiSTer-devel/Gameboy ... /ReadMe.md

Cheers