MiSTer FPGA Forum

Where are your mame and hbmame directories located?
Did you select MAME and HBMAME Getter in the script setup screen?
Are you using a USB HDD?
Where you using the RetroDriven script before using the Update All script?

jca wrote: ↑Thu Dec 17, 2020 2:50 am Where are your mame and hbmame directories located?
Did you select MAME and HBMAME Getter in the script setup screen?
Are you using a USB HDD?
Where you using the RetroDriven script before using the Update All script?

My mame/hbmame are under /media/fat/games - I even tried moving mame to _Arcade/mame but no dice
I selected both MAME/HBMAME in the script - I even deleted those dirs so script went through and redownloaded everything

I deleted the _Arcade dir and had update_all script redownloaded all the cores and it worked. I went back and ran the retrodriven script and now back to things not working.

Don't run the RetroDriven script, it uses a different file structure for the Jotego cores. If you run the Update All script with Jotego Updater select along MAME/HBMAME Getter you will have everything, all the mra will be in one directory. If you also select the Arcade Organizer it will make it easier to find your cores.

jca wrote: ↑Thu Dec 17, 2020 1:27 pm Don't run the RetroDriven script, it uses a different file structure for the Jotego cores. If you run the Update All script with Jotego Updater select along MAME/HBMAME Getter you will have everything, all the mra will be in one directory. If you also select the Arcade Organizer it will make it easier to find your cores.

I noticed the Jotego cores are mixed in together inn the _Arcade dir when you run the update_all.sh script. I don't think I was also getting the CPS1.5 cores even though I chose to download everything including unofficial in the menu system when you press down to go into the menu. I think that's the reason why I went back to the retrodriven script after so I can pick up those additional cores.

The update all script downloads everything (if you have Jotego selected), the unofficial is for other cores:
Successfully updated cores:
Gyruss (Centuri).mra, Gyruss (bootleg).mra, Gyruss.mra, Venus (bootleg of Gyruss).mra, Penguin-Kun_Wars.mra, Penguin-Kun_Wars_Japan.mra
The update all script put everything in the _Arcade directory contrary to the retrodriven script which uses subdirectories for Jotego cores.
If you also run the organizer you can see that CPS1.5 is there:
You have to go to Organized->Cores, the Jotego cores are prefixed by jt. Like jtcps15.
Come January the retrodriven script will not be updated, better get familiarized with the update all script.

https://twitter.com/topapate/status/1339818314336530432

Btw, I've updated but haven't tested yet. In any case, I haven't experienced any problems to begin with on a 128MB SDRAM module (got it from ultimatemister).

Mmm seems like a may have a bad 128MB module?
With todays update I get this error con C&D and sporadic sprite errors in Street Fighter Zero Qsound version.

If you're having those issues after updating, you might want to let Jotego know via Twitter that you're having a problem. I think he wants to know where you got your module from (and when), what the board layout is... I think that might be it.

But it doesn't mean you module is faulty at all, just that it's not entirely compatible with how Jotego has implemented some stuff He just needs the info to work out the common denominators.

Only Game with an issue Memory Module 2.5 128meg is Slammasters illegal instruction after you beat the 1st stage ! Completed Dynasty Warriors and a little slow to block in top of the screen graphics.

Using 128MB v2.5 . After the last update I get Exception 1111 after few minutes on Punisher. I played last week without having any errors . Maybe something in the last update ?

So I thought it was for a good cause and I felt I had to complete C&D

After loads of coins I have managed to finish it without experiencing any issues/glitches at all.

I have got a 128mb module from Nat at Misterfpga.co.uk and I haven't updated to the last version of Jotego's update though.

I will do a back up of my system and update the CPS 1.5 core so that I can do more testing and I will report back here.

So I have updated the core. I went through the first stages of The Punisher and C&D. No issues at all. However, I need to report that Slammasters doesn't boot anymore, at least with my setup. I have tried to reboot several times but to no avail. I do get the Capcom initial screen presentation but nothing more.

Hi,
I also got a 128mb module from Nat at Misterfpga.co.uk .
I don't have problems with SFZ and C&D. It looks like Punisher give me the error after having played another CPS1 game before. If I load The Punisher as first game after have booted the Mister I can play it fine. I've tried to play with C&D /SFZ and then The punisher and I got the 1111 Exception 0001554A. Tried with KoF and then Punisher and I haven't had any errors.

Hoping it may help.

Kind regards,

Jotego posted SDRAM culprit found on twitter.

In the post he says “Decoupling caps are not good enough”, does this mean that we could have “not good enough” 128 MB modules?

Sorry for the dumb question.

No, it means that he has found a way to access the memory modules which depletes the stored energy in the decoupling caps on some boards.

Two ways forward:
1) don't use that access method if it's not necessary, and understand the limitations of current boards
2) design a new board with more/better decoupling, and label cores using such techniques as requiring the new model.

Thanks. I hope he can choose the first one.

So the only way to test it’s to run the update via RetroDriven or similar and run CPS 1.5 games for “a long time”?

I just ran RetroDriven update script and did the first stage of C&D and had no issues. I’m using a v2.5 bought in October from misterfpga.co.uk.

Well, the two cases aren't mutually-exclusive... there could be situation which require an updated module in future.
But unless it's needed (i.e. memory bandwidth), existing methods should be used.

Could it be the case of more demanding cores like ao486 or PS1 ones?

ao486 uses DDR3, so that's not the case.
I don't know what PS1 intends to use.

It's going to depend on two things:
1) how fast the memory access required by the original machine is (for each object placed in SDRAM)
2) how many separate memory buses the developer is trying to push into the SDRAM

But don't forget that there are also BRAM (FPGA block memory) and DDR3 available on the board as well, to spread out bandwidth needs or multiple buses.

ao486 doesn't use SDRAM.

Thank you guys.

I hope in the future none of the developers will need and put a new module requirement so that anyone who already bought it is safe.

Is this “limitation” part of the design of the board or is it caused by the capacitors choice from the sellers?

A variety of factors.
The SDRAM chips themselves are capable of more.
But the GPIO pins on the DE10-Nano are being pushed; the capacitors are there to try to make up for that, but it's not simple.

When reaching these frequencies, a lot of care needs to be taken in:
- power management
- specific trace sizes and lengths being used
- impedance matching
- capacitive decoupling
...and so on and so on.

This wasn't a product developed in a lab over the course of years by a big team of people on a well-funded project with a single over-arching predefined goal to reach, like a 'normal' commercial product.
It started as a hobby project, and the goals keep getting more and more grandiose as time goes by, and other developers join.

At some point, the goals will likely exceed the original design which were built to suit the goals of an earlier time... just like the furniture you get when you're in your twenties is not likely going to be the same furniture you have when you're in your 40s.

But sure, it'd be nice to keep within the limits of existing hardware until it is no longer possible.

Thanks again for your explanation.

My only doubt is if the problem is also originated by vendors using “not so good” caps since jotego also wrote to check that.

Lots of factors can affect performance. Leaving traces of flux on the board is probably a bigger cause.
I think Jotego used the phrase "made by hand", but it's more specific than that - flux, and the failure to clean it, can cause issues.

Similarly, hand-soldering improperly (i.e. applying wrong heat for wrong period of time) can damage capacitors. Some cheaper types of capacitors may have bad QA and fail tolerances, but more likely, success would have to do with the number, value, and placement of the capacitors.

Why all these wild explanations when in fact all other cores worked with the Winbond chips?
There was a problem between the code and the Winbond chips that are now fixed.
Caps, flux, and global warming have nothing to do with it.

I think you've missed a critical component of the explanation.
It's the SDRAM controller that overdrove the modules - the newly-written SDRAM controller which is specific to Jotego's cores.
You'll notice the other cores don't have problems.

When people ask "how is it overdriving the modules when the chips are rated for higher speed ?", there is nuance. Of course, not everybody likes to know nuance... and you're free to ignore it.

But don't say it's bad chips; that explanation shows a profound misunderstanding of what's going on.

dshadoff wrote: ↑Mon Dec 21, 2020 1:28 am just like the furniture you get when you're in your twenties is not likely going to be the same furniture you have when you're in your 40s.

haha I've still got the same furniture from my 20's!

WolfgangBlack wrote: ↑Mon Dec 21, 2020 5:51 am Caps, flux, and global warming have nothing to do with it.

Very arrogant of you when the dev has publicly mentioned its the caps that is causing the issue.

dshadoff wrote: ↑Mon Dec 21, 2020 6:05 am I think you've missed a critical component of the explanation.
It's the SDRAM controller that overdrove the modules - the newly-written SDRAM controller which is specific to Jotego's cores.
You'll notice the other cores don't have problems.

But don't say it's bad chips; that explanation shows a profound misunderstanding of what's going on.

That is the answer I needed, because there is a difference for people like me that cannot understand those things ( ) between a bad chips/capacitors/board that need to be fixed/bought again and a SDRAM controller that overdrove the modules.

If there was the first case it would be strange that all other cores showed no errors/glitch.

Anyway I got "ADDRESS ERROR" on Street Fighter Zero CPS1.5 too at the start of the first round on a v2.5 128MB.