MiSTer FPGA Forum

I can now build the core.

Once I confirm it works, I will update this thread with a new version when there is an update on the original core. I might do it thru a github branch in the future. For the time being, mega will suffice for storage I guess.

Its been a long a difficult journey but I was finally was able to make it happen. Enjoy.
https://mega.nz/folder/xlUVEIzB#vKdNV8vkMuQixxPgItnV2w

uberyoji wrote: ↑Thu Feb 25, 2021 2:13 am Its been a long a difficult journey but I was finally was able to make it happen. Enjoy.
https://mega.nz/folder/xlUVEIzB#vKdNV8vkMuQixxPgItnV2w

Thank you so, so, much for this. Also to all the others that have contributed to this thread.

Outside of my main retro gaming PVM I have an ASUS ROG Swift PG279Q, an Iiyama RedEagle G-Master, and downstairs a Samsung JU7500. The NeoGeo core simply flat-out refuses to lock sync on any of them. I get nothing but a series of flickers followed by a black screen unless I want to forfeit vsync_adjust=2 (no thanks). The only solution up until now was to run the MiSTer through my old Elgato Game Capture HD and activate its software through my computer which would bridge some form of pass-through or sync handshake to my various displays. Hardly ideal.

These revised cores have fixed all of this. Thank you again, honestly. I don't like to power my PVM up unless I'm going to be playing for extended durations, so this has enabled quick-fix bouts of Neo gaming through my LCDs. To me, at least, this is a big deal. If I didn't have the PVM I wouldn't have been able to play at all.

How difficult is the process? It's something I'd like to learn how to do myself and maybe assist with.

Not too complicated honestly if you have a little xp in software devs. It is basically those steps high level:
1) install Quartus lite v17.0 (once)
2) Install git (once)
3) Get/update source code from repo
4) Modify Entity pll from 96 to 97.330180 and 48 to 48.665090
5) Compile core
6) Profit

I plan to maintain the 60hz fork forever so no worries, I will always update this thread each time there is a version in a timely fashion now that my setup is done. I put some notifications on the repo to alert myself when the master is updated.

Is this an issue where an incompatible pixel clock is being calculated for some displays? I wonder if changing the video mode would help a bit.
A real example. I run vsync_adjust=2 unless forced to otherwise. I had a global video_mode set to 1920x1080@60hz (one of the standard modes available).

The arcade scramble core WOULD NOT sync to my freesync monitor unless I used vsync_adjust=0. I brought it up in the bug tracker and Sorg said that sometimes the calculated pixel clock isn't compatible, so maybe try the PAL (50hz) mode. That works, and since I am using vsync_adjust=2, the vertical refresh matches the core like it should.

If you're using vsync_adjust=2 try another video mode and see what happens.

Issue for reference: https://github.com/MiSTer-devel/Arcade- ... /issues/25

Maybe I am mistaken, but I always though the vsync_adjust param to be related to the scaler and therefore attached to the hdmi output (unless you are using the scaler on vga). I personally don't have any issues with hdmi output on any of my lcd tvs using the original neogeo core. The tweak is aimed more at forcing 60hz for crt usage. Without this fix, on my end, I have a slight roll/wave on my sony trinitron. Now the picture is more stable at the cost of accuracy I guess.

You are actually wrong here, vsync_adjust only applies to hdmi-output.

Ganondork wrote: ↑Sun Apr 04, 2021 6:03 pm You are actually wrong here, vsync_adjust only applies to hdmi-output.

I think this is what I said vsync_adjust applies to hdmi output.

Thank you for this. This has fixed the issue of stuttering scrolling on my TCL 55R617. I'd like to try this with the double dragon core as well, as the 57hz refresh rate causes stuttery scrolling on my TV. However speeding that game up to 60hz would probably affect gameplay more noticeably than the neo's slight increase?

rastan wrote: ↑Wed Apr 07, 2021 4:57 pm Thank you for this. This has fixed the issue of stuttering scrolling on my TCL 55R617. I'd like to try this with the double dragon core as well, as the 57hz refresh rate causes stuttery scrolling on my TV. However speeding that game up to 60hz would probably affect gameplay more noticeably than the neo's slight increase?

I can have a look for you. Is it the jtdd core?

Insert Disk Two wrote: ↑Sat Jan 16, 2021 6:46 pm Updates on Neogeo are done by Sorgelig himself and he does not want to include this option.

I am sure with everything else on his plate, and he understands how individual cores interface with the main framework that Sorgelig got his reasons.
Plus he is not fond of 15khz CRTs so there no motivation on his part to include the option in the core.

uberyoji wrote: ↑Wed Apr 07, 2021 10:35 pm

rastan wrote: ↑Wed Apr 07, 2021 4:57 pm Thank you for this. This has fixed the issue of stuttering scrolling on my TCL 55R617. I'd like to try this with the double dragon core as well, as the 57hz refresh rate causes stuttery scrolling on my TV. However speeding that game up to 60hz would probably affect gameplay more noticeably than the neo's slight increase?

I can have a look for you. Is it the jtdd core?

Yes. thanks for offering to look at it!

darksakul wrote: ↑Thu Apr 08, 2021 1:39 pm

Insert Disk Two wrote: ↑Sat Jan 16, 2021 6:46 pm Updates on Neogeo are done by Sorgelig himself and he does not want to include this option.

I am sure with everything else on his plate, and he understands how individual cores interface with the main framework that Sorgelig got his reasons.
Plus he is not fond of 15khz CRTs so there no motivation on his part to include the option in the core.

Ummm adding a 60hz option would be beneficial to LCD screen users not CRT.

Insert Disk Two wrote: ↑Wed Jun 02, 2021 11:14 am
Ummm adding a 60hz option would be beneficial to LCD screen users not CRT.

Nothing to do with what I was talking about

15Khz is the carrier frequency not the refresh rate.

uberyoji wrote: ↑Thu Apr 01, 2021 10:06 pm Not too complicated honestly if you have a little xp in software devs. It is basically those steps high level:
1) install Quartus lite v17.0 (once)
2) Install git (once)
3) Get/update source code from repo
4) Modify Entity pll from 96 to 97.330180 and 48 to 48.665090
5) Compile core
6) Profit

I plan to maintain the 60hz fork forever so no worries, I will always update this thread each time there is a version in a timely fashion now that my setup is done. I put some notifications on the repo to alert myself when the master is updated.

Hello mate, any chance of 'NeoGeo_20210713.rbf' being given your magic touch? Thanks!

Sure. But if I read the github thread correctly, sorgelig agreed to make the mvs and aes timing different. It might fix our crt problem by selecting aes. I will have to check if I can still apply the mod.
You can see the discussion here: github.com/MiSTer-devel/NeoGeo_MiSTer/pull/134

Since there is now a clock switch used in the core you'll have to change it to 60Hz in a different way.

There are 2 numbers here: https://github.com/MiSTer-devel/NeoGeo_ ... eo.sv#L373
The first is for MVS and the second for AES. The number for 60Hz should be 3148288251. So just change one or both numbers.

You might also still need to change the PLL to the higher clocks if it is unstable.

paulbnl wrote: ↑Tue Jul 20, 2021 10:21 am Since there is now a clock switch used in the core you'll have to change it to 60Hz in a different way.

There are 2 numbers here: https://github.com/MiSTer-devel/NeoGeo_ ... eo.sv#L373

Code: Select all

cfg_data <= sys_mvs_r ? 2576980378 : 2865308404;

The first is for MVS and the second for AES. The number for 60Hz should be 3148288251. So just change one or both numbers.

You might also still need to change the PLL to the higher clocks if it is unstable.

I finally decided to get back to this. How do you calculate the fractionnal? On my end I approximated to 3148289000 but I can use your constant instead. I am building a version and will test shortly.

Here's the latest version fixed at 60hz.
https://mega.nz/file/sxUi3BrC#CBxoZxTKy ... h3eQ9Abz44

Updated folder with a patched version of the Sept 8th release.
https://mega.nz/folder/xlUVEIzB#vKdNV8vkMuQixxPgItnV2w

uberyoji wrote: ↑Sat Jul 31, 2021 10:12 pm I finally decided to get back to this. How do you calculate the fractionnal? On my end I approximated to 3148289000 but I can use your constant instead.

I just changed the PLL to the higher clock and then the value is at Advanced Parameters -> K-Fractional Division Value (DSM).

Hi everyone, would it be possible to make a similar change to the Game Boy/GBA cores? So, adjusting the core clock from 59.7Hz to 60Hz? These systems are really the only ones giving my TV (Sony XH90) trouble, I get frequent stuttering even with vsync_adjust=2. I'm not able to build the change myself unfortunately as I'm on MacOS.

wondermagenta wrote: ↑Mon Sep 27, 2021 6:39 pm Hi everyone, would it be possible to make a similar change to the Game Boy/GBA cores? So, adjusting the core clock from 59.7Hz to 60Hz? These systems are really the only ones giving my TV (Sony XH90) trouble, I get frequent stuttering even with vsync_adjust=2. I'm not able to build the change myself unfortunately as I'm on MacOS.

What I do on my end is I toggle the Stabilize Video(buffer) on. Try it out and let me know.

uberyoji wrote: ↑Tue Sep 28, 2021 3:29 amWhat I do on my end is I toggle the Stabilize Video(buffer) on. Try it out and let me know.

I do have that option turned on actually (without it, the image just completely goes haywire,) but unfortunately the stutter I mentioned is present either way. It's relatively subtle, but personally I believe it has to do with my TV deliberately dropping frames to keep pace with the GBA's 59.7Hz, so the only real fix would be to run at 60Hz I feel (like the GBA Consolizer does for example.)

Ok I'll check over the weekend and make builds.

uberyoji wrote: ↑Tue Sep 28, 2021 1:05 pm Ok I'll check over the weekend and make builds.

Just wanted to say thank you for looking into this, I know it's gonna be a big help for a ton of people.

Arg. I am a bit screwed. The timings are already tweaked on the pll component. I would need base timings to recalculate the ratios. Anyone knows the proper timings? Gameboy is quite far from the 96/48 baseline.

Currently this is what is set:
GBA
- 100.663296
- 50.331648

Gameboy
- 67.108864
- 33.554432

I'll try pinging Robert on Discord/Twitter.

For GBA:

base clock is 16.78Mhz.
Core is using 6x this clock, so 100.68 Mhz.
In total there are 280896 pixels (visible and blank), resulting in 59.73 Hz

So let's do the math other way around: 60hz * 280896 = 16.853760 mhz * 6 = 101.122560Mhz

You can probably round it a bit if the PLL cannot directly match it.


For Gameboy:
base clock is 4.194Mhz.
Core is using 8x this clock, so 33.552 Mhz. (core is actually using 33.56)
In total there are 70224 pixels (visible and blank), resulting in 59.72 Hz

So let's do the math other way around: 60hz * 70224 = 4.213440 mhz * 8 = 33.707520 Mhz
You also need to set SDRAM clock to 16 times clock: 4.213440 mhz * 16 = 67.415040 Mhz (currently 67.12)
Make sure both clocks are excatly 1:2 in ratio!


I hope i didn't miscalculate somewhere, that's why i kept the math here.

Have fun!

Wow. By the man himself thank you. I'll do the mods right away.