STE BAD RAM (not bad simms)

[exxos]

Found a inherent fault on a STE motherboard relating to RAM issues.. read all about it on my site..

http://www.exxoshost.co.uk/atari/last/STERAMISSUE/

[Greenious]

I have never seen that on any atari ST/STE with supposedly good memory.

ST/STE don't have a separate ram-refresh. It relies on the constant video access to provide ram refresh for the memory, which is why they only use Fast Page mode dram.

SIMMs came in all sorts of shapes and sizes, are you absolutely sure these are FP-dram SIMMs?

[czietz]

@exxos: Did you also observe RAS and CAS? The address lines are latched with falling edges of RAS and CAS, so any noise on MADx at other times should not interfere with RAM access. On my ST, which has no RAM errors, I also see some glitches on the MAD lines, but not at the same time as falling edges on RAS/CAS.

ST/STE don't have a separate ram-refresh. It relies on the constant video access to provide ram refresh for the memory

This is not exactly true. On the ST there are separate RAM refresh cycles (RAS-only cycles) during (vertical?) blank. I didn't check on an STE but I assume it's the same.

which is why they only use Fast Page mode dram.

Again, the DRAMs used in the ST don't necessarily support Fast Page Mode. Also I'm not sure why FPM would help with the refresh...

[czietz]

PS: See the last slide in https://ocean.czietz.de/index.php/s/eea ... #pdfviewer on how (linear) addresses are decoded into row and column addresses on the STE. Maybe you can find a pattern if you map the addresses failing the RAM test to particular address lines.

[exxos]

FPM simms do not work on the STE.

I checked RAS,CAS, and all other lines, they are pretty much ok. Its only the MAD lines which suffer, mostly MAD9,MAD8 possibly.

Its interesting how the fault didn't show up for about 2 hours, then after 8 hours MAD9's fault vanished, but the fault seemed to be more on MAD8 then. So it seems the fault varies depending how long the STE is powered up.

As I have not seen this problem before, its either just a bad GLUE IC, or its a inherent problem with the STE's with a internal blitter.

It would really help if someone could scope out MAD9 on such a motherboard.

[czietz]

I checked RAS,CAS, and all other lines, they are pretty much ok. Its only the MAD lines which suffer, mostly MAD9,MAD8 possibly.

Yes, but what's the timing between RAS, CAS and the glitches/noise you see on MADx? As already stated, MADx need only to be stable around falling edges of RAS and CAS. Can you make a scope capture showing RAS and/or CAS together with MAD8 or MAD9?

[exxos]

Yes, but what's the timing between RAS, CAS and the glitches/noise you see on MADx? As already stated, MADx need only to be stable around falling edges of RAS and CAS. Can you make a scope capture showing RAS and/or CAS together with MAD8 or MAD9?

Looks like RAS, CAS come in half way though the MAD cycle. Its hard to capture because loading RAS & MAD causes the machine to crash. Individually its ok. Its possible loading on the RAS,CAS lines could be a issue aswell, but one problem at a time...

I've designed and ordered a 9bit buffer board, schmitt buffer to clean up MAD signals. Then I will see about RAS & CAS if there are still faults. Be a couple weeks before PCB's get here.

Atari buffered all lines on the MEGA, so likely they knew of such issues.

[czietz]

During Jean-François del Nero's and my reverse engineering of the STE and ST MMUs for EmuTOS, he posted a scope screenshot of these lines on his STE:

http://hxc2001.free.fr/vrac/STE_RAS_CAS_A9_B2.jpg

You can see how MAD9 (A9) changes between falling edges of RAS and CAS, depending on the address which is to be accessed.

[exxos]

Yellow = A9

CAS & A9

cas1.png

cas1a.png

RAS & A9

xras1.png

xras1a.png

[czietz]

At least on the scope traces it looks as if the noise / the spikes on MAD9 do not coincide with falling edges of either RAS or CAS. For example for NEC µPD41256 DRAM the setup time for addresses is 0 ns (i.e. addresses must be stable exactly when the falling edge begins) and the hold times after the falling edge are 10 ns (RAS) and 20 ns (CAS). So the address lines don't need to be at the defined level for a very long time.

However, it'll be probably very hard to capture the precise moment when a RAM error occurs. Maybe in that case some glitch does happen at the same time as a falling edge on RAS/CAS. Hence when your buffer board arrives I'll be interested if it fixes the errors.

[exxos]

At least on the scope traces it looks as if the noise / the spikes on MAD9 do not coincide with falling edges of either RAS or CAS. For example for NEC µPD41256 DRAM the setup time for addresses is 0 ns (i.e. addresses must be stable exactly when the falling edge begins) and the hold times after the falling edge are 10 ns (RAS) and 20 ns (CAS). So the address lines don't need to be at the defined level for a very long time.

However, it'll be probably very hard to capture the precise moment when a RAM error occurs. Maybe in that case some glitch does happen at the same time as a falling edge on RAS/CAS. Hence when your buffer board arrives I'll be interested if it fixes the errors.

The signals are not great, but like you say, they not exactly at fault. But the error is hard to track. Like 2 entire passes of RAM test and it fails once. So its unlikely to ever capture the actual fault.

Looks iffy as the A9 signal while it could latch while A9 is low, there is always a spike there. So its possible if the spike got worse at some point, it could actually latch A9 as HI not LO. Adding capacitors reduces the spikes and its a lot more stable. So that is my best guess at the moment. I think a few ns delay on the address lines should help also.

[Greenious]

What kind of SIMMs are these? 9 chip? Is it a fan-out problem?
Can you replicate the error with same SIMMs in another STE? Different set of SIMMs in the same STE?

I know ppl in the past have been complaining that SIMMs with parity is troublesome. Atari at the time said parity did not matter, and I have used 3 chip SIMMs with parity without problems.

And another thing, even though you stated you don't want to discuss the matter at all anymore, this error does fit the original "bad DMA" description perfectly.

[dlfrsilver]

Well, i have been reading this topic as i did with all the other interesting ones opened by Chris, and i'm itching my head......

Are you sure Greenious that this error fit with the original "bad DMA" ?

If yes, can you explain or expand what you know on this matter ?

Thanks a lot

[Greenious]

Well, the "original" description of the bad DMA, says the HDD will get corrupted after a few hours of use.

This post with an excerpt from ST-Format says it all: viewtopic.php?f=15&t=28504#p280934

If ram starts randomly get read/write errors like exxos describes in this thread... The DMA shares the bus with the CPU..

So. This explains the "bad DMA", with facts, better than anything else I have read or come across. Since the topic has become somewhat of an elephant imho, with ppl attributing everything from toilets not flushing to the brexit to a bad DMA in their STE.

[exxos]

I locked the DMA thread as I am really stick to death of seeing people looking for a "good DMA" , not reading a word ive put, and nobody being bothered to actually try things which would help the community. Every time I see a post with "I've got a bad DMA" I want to punch that person in the face, I really do.

As for RAM. Parity simms are not advisable. Some brands seem to work ok, but others dont. Some might be stable for some hours then become unstable. There is no parity on the STE so using party IC's where you end up with floating inputs....

I've tried simms from another STE, and many other sets which are known working and it doesn't matter. Either this machine is faulty, or its because its the type with integrated blitter, all my other machines have a separate one. Really I need to find another STE with integrated blitter, but not got time at the moment to start taking piles of machines to bits.

This seems to be a thermal problem with the large SMT IC. Normally DMA problems start after about 10mins. While pullups have solved all problems (for me anyway) The STE also suffers from RAM issues. It took 2 hours before the RAM started to fail , so it doesn't fit in with the DMA issues in that respect, but similar.

The SMT IC, I had the machine running for a hour, no RAM faults, then I got my gas soldering iron on it to heat it up (iron wasn't very close to the IC) and after a few seconds the machine crashed on RAM test. That is with the diagnostic cartridge aswell.

I've designed a buffer board to buffer the MAD lines like on the MEGA, though while it will clean up the signals, I'm not sure if it will cause RAS CAS timing errors, though I may buffer those aswell to keep the timings as before. Things need to be tried and ruled out.

Another guy on facebook as been talking to me about it, he says his STE has the same bad looking signals, but his machine generates garbage on the screen when his scope probs is on RAS, CAS. I have seen that, and my machine just crashes, or doesn't boot up all the time. So there is something over-sensitive with the RAM lines, I think thats proven now.

Also the length of time the machine is on the faults change, again thermal problems. Over sensitive RAM signals, with noise which changes as the IC heats up over time.. I think "buggy MMU" on the STE seems more fitting.

[dlfrsilver]

Chris, can you post a picture of your STE motherboard which has a problem with the RAM ?

[exxos]

Chris, can you post a picture of your STE motherboard which has a problem with the RAM ?

Think these STE boards pretty much look the same dont they ?! This is just a later one with the integrated blitter.. Its the first "type" of board I have tried and just so happens to be the first board I've noticed this ram problem.

Someone else has confirmed the spike problems, but he doesn't have any RAM issues (at least that he knows of). I really need a custom RAM test program that I can pass about to people to see if others actually have this fault or not.

[czietz]

What needs to be custom about the RAM test program? Aren't these errors found by a regular RAM test program? Of course, then you can't say if it is the SIMM or the MMU, but I don't see any way to determine this in software.

That being said I always wanted to port memtest86's test algorithms to the Atari, because they are good at finding subtle faults. Never got around to do it, though.

[exxos]

What needs to be custom about the RAM test program? Aren't these errors found by a regular RAM test program? Of course, then you can't say if it is the SIMM or the MMU, but I don't see any way to determine this in software.

That being said I always wanted to port memtest86's test algorithms to the Atari, because they are good at finding subtle faults. Never got around to do it, though.

The only thing which seems to find errors is the diagnostic cartridge. Theres only the marpet RAM test and that doesn't seem to find the problems. Really I want one which will mimic the GB6 window test. Where it flashes the background colour green and white, because I can visually see if there is a problem. The test loop has to be fast as possible. Could be the marpet test just isn't fast enough to "see" the errors. So really want one to just test screen memory, write green/white colours to screen and read them back.

It could just be a illusion, but I can often see anything from 1 to 20 failed colours on the screen at once, even the diagnostic cartridge doesn't pick up that many at once. So I think a new RAM program which can test screen memory so I can visually see whats going on, plus have the colours read back to see if they are still the same. If the RAM test doesn't show errors and I see them, then it doesn't work for some reason. But no such test have even been programmed. I think looping the 32K screen memory should loop through a lot faster and show the errors quicker than testing the whole RAM area. Errors don't seem to happen under 1MB. So testing it is pointless for starters. I assume screen RAM is high up in the RAM map somewhere, but don't know offhand.

Such a RAM test should show up a lot of errors, which I am just not seeing. So without some proper tools for testing, its just making debugging faults even more problematical.

[troed]

I assume screen RAM is high up in the RAM map somewhere

Yes. xF8000 where x is 0,1,2,3 depending on the amount of memory in the machine.

/Troed

[troed]

I assume screen RAM is high up in the RAM map somewhere

Yes. xF8000 where x is 0,1,2,3 depending on the amount of memory in the machine.

edit: ... and 78000 if you only have 0.5MB ...

/Troed

[Greenious]

Personally, because of fan-in/out aspects of TTL-Logic, I never upgrade STEs with SIMMs that got more than 4 ram chips.

Regarding SIMMs with parity, if you read Ataris official tech papers, they say it's not a concern. And personally I have never had any problems with parity simms, atleast not that I can attribute to parity...

But I have had problems with 8/9 chip SIMMs. And I believe it is a fan-out problem with ST(E) MMUs in general. And that's why I asked about the SIMMs...

[exxos]

I have the same problem with 3 chip simms. The 256K simms I used are 8 chips each and they work fine. Its not a fan out problem as I have tried loading the lines even more with resistors, the outputs are pretty tough.

[dlfrsilver]

Chris, can you post a picture of your STE motherboard which has a problem with the RAM ?

Think these STE boards pretty much look the same dont they ?! This is just a later one with the integrated blitter.. Its the first "type" of board I have tried and just so happens to be the first board I've noticed this ram problem.

Someone else has confirmed the spike problems, but he doesn't have any RAM issues (at least that he knows of). I really need a custom RAM test program that I can pass about to people to see if others actually have this fault or not.

Ok, when you get this program, i'll volunteer to test my 520 and 1040 STE (both with 4mb) and return the result here.

[exxos]

Ok, when you get this program, i'll volunteer to test my 520 and 1040 STE (both with 4mb) and return the result here.

Cool Just need someone to write it , thats the problem. The more STE's which are tested the better.

If you have a diagnostic cartridge then you could try that.