SDRAM board

[Nat]

See here, click on the images and you can zoom in.

https://misterfpga.co.uk/product/mister ... lated-pcb/

Your issue is here

Capture.gif

[jca]

I have a Winbond 32MB board.
In the old times (before boards > 32MB) Memtest showed 167MHz (I think it was fake news).
With Memtest 2019-09-20 this dropped to 130MHz.
With Memtest-ddio this went up to 140MHz.
With the latest Memtest it is now at 150MHZ.
Would an update of the memory controller of Tiger Road and Bionic Commando fix the messed up sprites?

[Sorgelig]

Would an update of the memory controller of Tiger Road and Bionic Commando fix the messed up sprites?

you need to ask the developer of that core.

[RETR0Gamer]

Good news, OSHPARK issued a refund for the defective boards I ordered from them. They seem to have figured out the problem and have a fix for it. This is what they said, and they asked me to also relay this information to the forum:

"Some additional info for you here. Since you're active on the forum, if you want post the following, it might help some users understand this issue here. Seems that the board suddenly got popular, so while we're resolving things now it seems the "forum" is as impacted as much as any one user.

The specific problem is deterministic based on the design, but the conditions to force it are extremely rare (an arc with a length of 0.000001 and 0.000004 inches). As a result, this problem will impact a bunch of people who've ordered the SDRAM boards, but no one else would be affected. Other than this one board, we haven't seen this issue occur in the two years since we previously submitted patches for the base problem.

In the near term, we're going to flag all these boards as they come in so we can swap in corrected files. Long term, we just have to patch one more software package, which should be pretty quick.

So, the technical detail for the failure is how arcs are treated in gerber viewers, and how some software handles this.

Internally, gerbers have arcs represented as 3 points: A start point, a centerpoint offset, and an end point. Gerber circles are represented the exact same way, only the gerber spec simply states to have the start and end point be the same. The upshot of this file format decision is that if a gerber ever loses precision on the coordinate data, it's possible to convert arcs of an extremely small length to a zero length, which in turn converts it to a full circle. This has to be precisely mitigated by either A) Never changing the format precision to a lower value, or B) Carefully tracking any arcs and avoiding this drop.
There's also some specific gerber commands that are intended to prevent this conversion through single or multi-quadrant arc specifications, but they tend to be less robust in how they're interpreted in practice. We've seen this exact issue come up in several software packages, including our fab's production equipment and processing tools.

Over the years we've patched a bunch of software to avoid this gracefully (allowing precision loss without causing arc wrapping). However, apparently we missed one software tool which is still is using 3.5 format instead of 3.6, which generates a precision loss of 1 digit. This means arcs that are between 0.000001 to 0.000004 inches in length, _and_ does not cross value of 0.000005 (which would cause them to round them to different values), can get converted to full circles.

Hopefully this helps explain the issue, and we encourage anyone affected to contact us for replacements and/or refunds. We really dislike bugs like this impacting our users, so we're happy to help correct things however we can."

[Sorgelig]

It's good they tracked down the problem and will solve it.
From my side i don't think i can do anything. Probably these micro-arcs are generated by Altium while converting design to gerber.

[RETR0Gamer]

Yes I'm also very happy that they acknowledged there was a problem and actually cared to spend the time figuring out what went wrong. I was worried they were going to just blame the gerbers and tell me too bad, but they've shown that they are good people over there at OSHPARK. I will order some more boards from them and this time hopefully there will be no issues!

Also, excuse me if it is posted somewhere, but where can I download the gerber files for the the V 2.5 pcb? I read a post where you said that there is no difference except V 2.5 is made to be easier to solder, but I can only find V 2.4 gerber on the DIY SDRAM page.

Thanks and Happy New Year!!

[Sorgelig]

same place as 2.4

[RETR0Gamer]

Oh my bad, I was looking on the main DIY page where it has the pictures and approved PCB manufacturers. On that page there's only a download link for 2.4, but I clicked the link to the GitHub repo and found the latest files! I will report back once I get some new boards from OSHPARK.

[poodude]

I'm glad I read this post, I had submitted the v2.5 gerbers to OshPark about 5 days ago. I can report back if I have any issues with the PCBs.

[UnannouncedFart]

Just received my 128MB memory module today, however when I installed it and ran the memtest it doesn't detect any memory module inside. The detected memory module says '0'. This is with using the latest memory test and the DDIO build provided on the previous page of this thread. I can load games that require it such as SNES/NES games. When trying to load any Neo Geo game it says memory will be corrupt (and graphics are corrupt). Is there some jumper to set to enable SDram or do I have a bad board?

EDIT:

This was solved. The issue was having done the SD card installer, updating the Mister binary but not the menu and other things. After running the update script, it detected the memory module and everything worked.

[type78]

Hello!
I have a question: is it possible to make a 64MB memory module from 2 x 32MB memory chips with XSD 2.5 pcb?

[Sorgelig]

Hello!
I have a question: is it possible to make a 64MB memory module from 2 x 32MB memory chips with XSD 2.5 pcb?

possible, but it won't be recognized by cores as 64MB.

[RETR0Gamer]

Just got the new 2.5 boards from OSH Park, and they appear to be fine now. Have a look:

https://ibb.co/7b6dGvJ
https://ibb.co/9V45SRp
https://ibb.co/VQpPpdQ
https://ibb.co/ZhW6dpw

I originally ordered the 2.4 boards from OSH when I experienced the manufacturing issue. Dan told me they'd flag that file so they automatically apply the 'fixes' to them on their end, so I also sent him the 2.5 gerber to flag as well. Any boards ordered from them should be fine now, and if there are any problems it has been documented with them so it should be easy to get a refund.

These boards are way cheaper to order from JLC, btw. So only order from OSH if you only plan to make a few boards and want them delivered faster in the USA. 1 batch (3 boards) from OSH is $18 shipped and there is no break on the price on higher quantities--2 batches (6 boards) will be $36 shipped. You can get 50 boards from JLC for like $45 shipped.

[djmartins]

So only order from OSH if you only plan to make a few boards and want them delivered faster in the USA.

OSH waits until it can fill a whole board and then it takes them a while to ship so in spite of shipping from the USA
I have received boards faster from China.
Right now with their coronavirus issues who knows.....

[apparentlymart]

Hello! Thanks for all of the great work in MiSTer!

I have assembled my own 128MB SDRAM board, but the memtest utility is showing it not detected at all. I've inspected my soldering work as best I can and haven't found any specific problem yet, so I'm trying to reduce the search space of the problem with some troubleshooting.

The other discussions I see in this topic were about a detected module that failed the test at higher speeds, so the problem I have here looks different to those.

I've been looking in the MiSTer repositories to try to understand how sdram_sz is detected, in the hope that I can focus my troubleshooting efforts on the specific signals involved in that detection, but sadly I wasn't able to find the actual detection code. Can anyone more familiar with the MiSTer codebase describe what signals are involved in the size detection, or identify the code that is handling the detection so I can study it myself?

I expecting I have a solder bridge or failed solder joint somewhere, so hopefully if I can understand which signals are involved in detection I can focus my checking on those signals for now, and thus have a better chance of spotting the problem. Thanks!

[Sorgelig]

Actual module size detection is done in Menu core. It uses safe 100MHz clock. It writes values into all possible size edges then read it back. Then send the detected size to Main (HPS), Then upon loading on any other core the Main sends the size to the core.

You can solder only U1 and caps on 128MB and then it should be detected as 64MB module. Then solder remaining.

[apparentlymart]

Thanks for the pointer! Good to know that it's okay to have only one of the RAM chips installed to start. I'm going to desolder the second one and focus on getting the first one working first. Thanks again!

[Sorgelig]

You can desolder U3 as well. Not required for single chip.

[gratte]

need bom capacitors
from antonio villena.
sdram xxsdram
thanks

https://github.com/MiSTer-devel/Hardware_alternative

[Nat]

need bom capacitors
from antonio villena.
sdram xxsdram
thanks

https://github.com/MiSTer-devel/Hardware_alternative

I have found using 3 x 10uf capacitors works fine, size is 0805, with 10uf capacitors I produced memory boards which clocks at 140Mhz with no errors for many hours looping with the memtest core.

[gratte]

thanks antono villena who use :

3 capacitors 100nF 0805
Both 10V or 16V works.

Inverter chip is the same of official SDRAM: 74lvc1g04

[richx]

If you are worried unevenly trimmed header pins or too much solder will affect the max frequency a SDRAM module will test at, take a look at the this experiment.

Apparently PCBWay botched one of the inner layer header vias on this batch, causing no-connections between the header pins and IC pads. Didn't even imagine that vias could be left unconnected and that testing continuity might be a good idea on bare PCB and then again before mounting the ICs..

But this module tests fine at 140MHz for 2 hours with all the patched connections, even with the single CLK wire patch. Minimig core seem fine as well.

About 8 of the connections were obvious no-connects and were initially patched. Some others measured 3-10 ohms but must have disconnected after module warmed up for about 15 minutes (memtest started getting tons of fails), so I just patched all of the inner layer ones to fix.

sdram_patched_front_b.jpg

sdram_patched_back_b.jpg

[Sorgelig]

surprised it passed 140MHz!

[digitron]

If you are worried unevenly trimmed header pins or too much solder will affect the max frequency a SDRAM module will test at, take a look at the this experiment.

Apparently PCBWay botched one of the inner layer header vias on this batch, causing no-connections between the header pins and IC pads. Didn't even imagine that vias could be left unconnected and that testing continuity might be a good idea on bare PCB and then again before mounting the ICs..

But this module tests fine at 140MHz for 2 hours with all the patched connections, even with the single CLK wire patch. Minimig core seem fine as well.

About 8 of the connections were obvious no-connects and were initially patched. Some others measured 3-10 ohms but must have disconnected after module warmed up for about 15 minutes (memtest started getting tons of fails), so I just patched all of the inner layer ones to fix.

sdram_patched_front_b.jpg
sdram_patched_back_b.jpg

Lol!

One thing that improved my results on these cheap PCBWay boards is to use low temp when soldering, just enough to make the connection to the pad. You will remove their cheap silkscreen at higher temps.

[Rikko]

Hi all,

would you say that I am correct to assume that adding an SDRAM board does not require any configuration?
Just for transparency, I've got a 128Mb v2.5 that core does not see. Basically, memtest shows 100% failure (multiple versions, all speeds), as if I didn't plug the board in.

Cheers