How to fix refresh problems DRAM

[Marius]

Hi!

 

This is probably dicussed before, but I can't find a real solving solution, so perhaps someone knows.

 

When I upgrade my 130XE to 320KB, and I use dram faster than 100ns... let's say 70ns. The memory upgrade first appears to work, but after 10 minutes (or sooner, or later sometimes) it starts to lose/change it contents. Random!

 

When I exchange the used DRAM for 'slower' chips (like 120 or 150ns) everything works fine.

 

The issue is that I have zillion DRAM chips 70 and 80ns, and not so much slower ones.

 

So how to fix this issue?

 

A Ph2 signal fix did not do the trick.

 

I really need a better refresh circuit.

 

Anyone?

 

Thanks

Marius

[Rybags]

Weren't the 64k x 4 chips used in the later XE (and XEGS) 90 ns ?

 

Or maybe I'm just thinking of the ones I grabbed from a videocard and put into my 600XL.

 

I'm not sure how the Refresh works with Extended RAM... isn't only 8 rows used by default, and you need to have more than that if there's >64K on it?

 

Actually, these later RAM chips will have multiple Refresh methods. Such as a CAS before RAS cycle, which should mean the chip auto-refreshes (generates the row address by itself).

 

Or does the Atari circuit do that anyway?

[+bob1200xl]

Just a wild guess... the faster DRAM is probably built with smaller cells that store less charge than the larger geometry chips. As a result, you may need faster refresh timings. Have you checked the data sheets for the faster DRAM?

 

When you upgrade, do you change the refresh circuits? You should not have to.

 

The SALT cartridge has refresh tests - do they run? This could just be a noise problem, rather than refresh.

 

Bob

 

they make really nice, well-behaved 512K SRAM...

 

 

Hi!

 

This is probably dicussed before, but I can't find a real solving solution, so perhaps someone knows.

 

When I upgrade my 130XE to 320KB, and I use dram faster than 100ns... let's say 70ns. The memory upgrade first appears to work, but after 10 minutes (or sooner, or later sometimes) it starts to lose/change it contents. Random!

 

When I exchange the used DRAM for 'slower' chips (like 120 or 150ns) everything works fine.

 

The issue is that I have zillion DRAM chips 70 and 80ns, and not so much slower ones.

 

So how to fix this issue?

 

A Ph2 signal fix did not do the trick.

 

I really need a better refresh circuit.

 

Anyone?

 

Thanks

Marius

[Rybags]

The datasheet I've got for a 41464 notes 4 ms max refresh interval per row.

 

4 ms is about 62 scanlines which = 558 Refresh cycles, or more than twice around (disregarding hires char "badlines" which would reduce that count by about 64). Still seems like plenty, though.

[ClausB]

Which version of ANTIC does your XE have, the one with 7 bits of refresh or the one with 8?

 

Also check whether your DRAMs need 8 bits refresh address or 9.

Edited February 6, 2011 by ClausB

[MEtalGuy66]

XEs all came with the 8bit refresh antics..

[Marius]

The problem is, I am not really a technician.

 

My Memory upgrade in XE computer is not more than one TTL IC (74HC138) and 256KB Dram.

 

I was using 2 44256 DRAMS 70NS and it failed. I have really a bunch of these.

 

I don't know how to fix that.

 

So if anyone has a solution, please tell me.

 

The upgrade is this:

 

GTIA pin 30 goes to pin one of HCT138

PIA pin 15 goes to pin two of HCT138

PIA pin 16 goes to pin three of HCT138

 

a 33Ohm resistor is connected to A8 of DRAM and the other side of the resistor is connected to pin four of HCT138.

 

The rest of the DRAM is connected to the same Data and Adress lines.

 

HCT138 is also connected to +5 and ground ofcourse.

 

That's all.

 

Works perfect with the slower DRAMS and refuses to work with faster.

 

So I would like to have a fix for that.

 

Thanks

Marius

[+bob1200xl]

I don't find the 44256 chips, but a 514256 chip (also 256Kx4) uses 9 bits of refresh. Are you sure that the slower 44256s work? Or, do they just take a long time to fail?

 

Bob

 

 

 

 

The problem is, I am not really a technician.

 

My Memory upgrade in XE computer is not more than one TTL IC (74HC138) and 256KB Dram.

 

I was using 2 44256 DRAMS 70NS and it failed. I have really a bunch of these.

 

I don't know how to fix that.

 

So if anyone has a solution, please tell me.

 

The upgrade is this:

 

GTIA pin 30 goes to pin one of HCT138

PIA pin 15 goes to pin two of HCT138

PIA pin 16 goes to pin three of HCT138

 

a 33Ohm resistor is connected to A8 of DRAM and the other side of the resistor is connected to pin four of HCT138.

 

The rest of the DRAM is connected to the same Data and Adress lines.

 

HCT138 is also connected to +5 and ground ofcourse.

 

That's all.

 

Works perfect with the slower DRAMS and refuses to work with faster.

 

So I would like to have a fix for that.

 

Thanks

Marius

[MEtalGuy66]

The problem is, I am not really a technician.

 

My Memory upgrade in XE computer is not more than one TTL IC (74HC138) and 256KB Dram.

 

I was using 2 44256 DRAMS 70NS and it failed. I have really a bunch of these.

 

I don't know how to fix that.

 

So if anyone has a solution, please tell me.

 

The upgrade is this:

 

GTIA pin 30 goes to pin one of HCT138

PIA pin 15 goes to pin two of HCT138

PIA pin 16 goes to pin three of HCT138

 

a 33Ohm resistor is connected to A8 of DRAM and the other side of the resistor is connected to pin four of HCT138.

 

The rest of the DRAM is connected to the same Data and Adress lines.

 

HCT138 is also connected to +5 and ground ofcourse.

 

That's all.

 

Works perfect with the slower DRAMS and refuses to work with faster.

 

So I would like to have a fix for that.

 

Thanks

Marius

 

Well, for one thing, you should be using a 74HCT158, not a 138..

 

That upgrade is commonly known as the "Scott Petersen 320k XE" upgrade..

 

As far as the refresh problem goes, you could try the approach that Bob1200XL used in his famous "XL/XE 1 meg SIMM upgrade" several years ago.. In which, you take the REF signal from ANTIC( pin 8 ) and "AND" it with CAS (on the 130XE You'd use the CASBANK signal from pin 10 of the EMMU chip, bend it up so it no longer makes contact with the socket) and hook the output of the AND gate(through a 33ohm resistor) to CAS (would be pin pin 2 on a 30 pin SIMM, but in your case, pin 16 on one of the 2 44256 chips in the extended RAM bank). This effectively creates a "CAS before RAS" refresh scheme (also known as "auto refresh") and thus takes advantage of the built in refresh counters in the DRAM chips.

 

To do this, use a 74LS08 (Quad AND Gate) pins 1 and 2 are inputs, pin 3 is output. pin 7 is VSS, pin 14 is VCC.

Edited February 6, 2011 by MEtalGuy66

[Marius]

As far as the refresh problem goes, you could try the approach that Bob1200XL used in his famous "XL/XE 1 meg SIMM upgrade" several years ago.. In which, you take the REF signal from ANTIC( pin 8 ) and "AND" it with CAS (on the 130XE You'd use the CASBANK signal from pin 10 of the EMMU chip,

 

Ehm ... which chip is that? Is that the 130XE PAL that is not in a 64KB XE?

 

bend it up so it no longer makes contact with the socket) and hook the output of the AND gate(through a 33ohm resistor) to CAS (would be pin pin 2 on a 30 pin SIMM, but in your case, pin 16 on one of the 2 44256 chips in the extended RAM bank).

 

Why shouldn't I connect that to both 44256 chips?

 

And I guess that pin 16 should be not connected to the mainboard of the XE I guess? So when I use a socket for that 44256 chip, pin 16 is out of socket?

 

This effectively creates a "CAS before RAS" refresh scheme (also known as "auto refresh") and thus takes advantage of the built in refresh counters in the DRAM chips.

To do this, use a 74LS08 (Quad AND Gate) pins 1 and 2 are inputs, pin 3 is output. pin 7 is VSS, pin 14 is VCC.

 

Thanks for the info!

 

Marius

 

p.s. you are right it is a HCT158. In my documentation there is "HCT138" but in my 130XE I indeed used HCT158. Thanks!

[MEtalGuy66]

The EMMu is U34.. Should be CO25953.. This should be a 16pin chip, sitting on a 20 pin socket footprint.. Pin 10 is in relation to the 16pin chip, not the 20pin socket footprint.. If you have a 20pin PAL in there(instead of a CO25953), then use pin 14 of that chip instead of pin 10 (either way, its pin 14 of the 20 pin footprint on the motherboard).. Anywayze, YES you should bend up the pin at the EMMU.. NO YOU SHOULD NOT bend up the pins on the DRAMS.. The circuit on the motherboard ties them together, and when you bend up the pin at the EMMU, you have isolated that circuit.. (look at a schematic).. You could use the pin 10/14 of the EMMU chip as one of the inputs, and then just go to pin 14 of the EMMU motherboard footprint as the output.. That way you dont need to add a 33 ohm resitor.. Whatever is easiest for you.. Like I said earlier, pin 8 of ANTIC (REF) is the other input..

Edited February 6, 2011 by MEtalGuy66

[MEtalGuy66]

theory:

 

Remember both CAS and REF are active-low signals.. so what your doing here is like a logical "or".. If either signal goes low, you are pulling CAS low on the DRAM.. This adds an extra CAS pulse any time ANTIC triggers REF.. SO you end up with some extra "cas before ras" conditions in the DRAM access sceme.. each time one of these happens, the "auto refresh" feature of the DRAM will increment it's internal adress counter by one, and refresh another set of rows..

[Marius]

There is one thing I don't understand (sorry!)

 

When I would use a SIMM... I would connect output of LS08 chip (through a 33Ohm resistor) to pin 2. That pin 2 of simm would not connect to another thing on the mainboard would it?

 

So I don't understand: why shouldn't I lift pin 16?

 

Or would I have to connect pin 2 of a SIMM also to a point on the mainboard? (two connections?)

 

And I also don't understand: why shouldn't I connect the signal that comes from the output of the LS08 chip to both 256KB DRAM chips?

 

 

Like I said: I have no idea what I'm doing, I only can build it. Rather good when I may say so but again: I have no idea WHAT i'm doing

 

So please forgive me If I look like a fool/dummy/retard whatever

 

Thanks

Marius

[Rybags]

CAS, RAS, and the Address lines of the RAM chips are all wired together with their equivalents on the other chips ... so you send a signal along one of them, it goes to the other chips as well.

 

CAS (Pin 2) of a SIMM doesn't goto a motherboard point in that scheme - the purpose of the additional circuit is to generate the CAS before RAS Refresh condition, having an extra connection would upset that - normal RAM access is RAS then CAS with the Address lines containing each half of the address on each half of the cycle.

[MEtalGuy66]

Like I said, look at a schematic and you will understand why..

 

The circuit that pin 16 of the DRAMs are connected to ONLY goes to pin 10(14) of the EMMU.. so when you lift that pin at the Emmu, the only thing you are left with is a circuit that connects pin 16 of both DRAMs together.. And a 33 ohm resistor going to the (now orphaned) pad 14 of the 20 pin EMMU footprint on the motherboard..

 

So.. Like I said.. The easiest thing to do is lift the EMMU pin, hook it to pin 1 of the LS08.. connect a wire from pin 8 of ANTIC to pin 2 of the LS08... Then do one of 2 things: either a)hook a 33ohm resitor to pin 3 of the LS08 and then a wire from the resistor to pin 16 of EITHER of the 2 44256 DRAms.. or B) run a wire from pin 3 of the LS08 to pad 14 of the EMMU footprint on the motherboard..

 

This REALLY IS CORRECT.. I dont know how much more clearly I can explain it..

[MEtalGuy66]

normal RAM access is RAS then CAS with the Address lines containing each half of the address on each half of the cycle.

 

Or in the case of ANTIC's normal refresh cycle, RAS (with no cas immediately before or after it) followed by an address setup that indicates a ROW number to refresh.. This is known as "RAS-ONLY Refresh".. What we are doing is adding a CAS before each RAS that isnt a memory access cycle, and therefor creating a bunch of "CAS before RAS" or (automatic) refresh cycles in which the chips do not need (disregard the state of) the adress lines, and use their internal refresh adress counters instead..

Edited February 6, 2011 by MEtalGuy66

[Marius]

Hey MetalGuy!

 

thanks... it is all clear now!

 

I'm going to build that into the XE and let's hope it will fix the problem!

 

Greetz

M.

[MEtalGuy66]

Might wanna try it on a "temporary" basic first, before you invest a bunch of time in a nice permanent installation.. a small breadboard is a nice thing to have..

 

Also, you may take a real close look at the 130xe schematic.. there may be an unused "AND" gate in the 74LS08 thats already on the motherboard.. I can't remember for sure if there is or not. I know there is one in the XL, but I cant remember if the XE uses all 4 or not..

[HiassofT]

Hi Ken!

 

As far as the refresh problem goes, you could try the approach that Bob1200XL used in his famous "XL/XE 1 meg SIMM upgrade" several years ago.. In which, you take the REF signal from ANTIC( pin 8 ) and "AND" it with CAS

Do you have some information about the detailled memory timing of the XE (or Freddie) systems?

 

On the XL series I found out (the hard way...) that simply ANDing REF into CAS does not result in a proper CAS-before-RAS refresh timing. At first everything seemed to work fine, but after a year or two I realized that the memory testers reported spurious errors. I tried several other SIMMs, all with the same result.

 

The problem seems to have been caused by the specific XL timing: CAS is deasserted ~70ns after the falling edge of PHI2, while REF is asserted at ~60ns. So if the cycle before the refresh was a DRAM access cycle, CAS would just stay low (asserted).

 

I _guess_ the XEs might not have this problem, as (IIRC) memory access doesn't extend beyond the end of PHI2. But I'm not 100% sure about it.

 

I looked at the memory circuit and finally was able to build a proper CAS-before-RAS signal using the D440 output of the delay line - you have to AND (REFRESH OR PHI2 OR D440) into CAS.

 

D440 is low from ~180ns - ~460ns and PHI2 from 0ns to ~280ns. From ~180ns - ~280ns all signals are low, if we are in a refresh cycle. RAS is asserted (low) from ~210 to ~70ns (the latter falling into the next cycle), so we have a proper CAS-before-RAS timing (i.e. assert CAS, assert RAS, deassert CAS, deassert RAS).

 

Back then I wrote a small program to simulate the XL RAM timing:

"BPHI2" is the inverted PHI2 signal, as present on the delay line, "foo" is (PHI2 OR D440).

 

so long,

 

Hias

[MEtalGuy66]

That's really good information to have.. I wouldn't imagine that the XE differs much from the XL where refresh timing is concerned, but in the case of the actual timing of CAS, the EMMU is the output and does have both HALT and PHI2 inputs, so who knows..

 

If the straight [_CASBNK & _REF] = CAS approach doesnt work then we can revise the circuit further to include the additions you mentioned (or some appropriate variation thereof)..

[HiassofT]

That's really good information to have.. I wouldn't imagine that the XE differs much from the XL where refresh timing is concerned, but in the case of the actual timing of CAS, the EMMU is the output and does have both HALT and PHI2 inputs, so who knows..

 

If the straight [_CASBNK & _REF] = CAS approach doesnt work then we can revise the circuit further to include the additions you mentioned (or some appropriate variation thereof)..

I just checked my 130XE: CAS and RAS timing is slightly different.

 

RAS is asserted from ~260ns to ~60ns (XL: ~210 to ~70)

read CAS is asserted from ~360ns to ~110ns (XL: ~340 to ~70)

write CAS is asserted from ~480ns to ~150ns (XL: ~470 to ~70)

 

CAS timing on Freddie pin 35 is some 20ns earlier.

Refresh changed state at ~70ns, so this is similar to my XL (~60ns).

 

So ANDing Refresh into CAS will keep CAS low (if a normal DRAM access occured before) and the timing looks like a hidden refresh cycle. Not CAS-before-RAS but it might still work :-)

 

BTW, just remembered another thing with the XLs: timing at the end of refresh (if just ANDing REF into CAS) is also quite tight. REF ends at ~60ns and RAS starts at ~70ns. With the added delay of the AND gate this might lead to a violation of the CAS to RAS precharge time (usually some 0-10ns). It might also be that this caused the troubles with my XL.

 

BTW2: It would be good if someone could re-check this, reading DRAM timing diagrams makes my brain hurt and I'm not 100% sure about the hidden refresh stuff :-)

 

so long,

 

Hias

[MEtalGuy66]

Well, not all chips supported "hidden refresh" either.. If the chips he's using are 70-80ns, I would guess that they would (but thats just a wild guess, based on access times that were popular in "consumer grade" dram devices that utilized specific "generations" of dram) .. but alot of the older/slower chips do not..

 

best approach here is just try one thing after another until it works..

Edited February 10, 2011 by MEtalGuy66

[Marius]

 

best approach here is just try one thing after another until it works..

 

Hi!

 

I did not do the refresh upgrade yet (no time, other things etc.)... but is it still a good idea with the 74LS08 TTL? Or is the continuation of this thread a conclusion that I need another thing to do?

 

Thanks

Marius

[HiassofT]

Hi Marius!

 

I did not do the refresh upgrade yet (no time, other things etc.)... but is it still a good idea with the 74LS08 TTL? Or is the continuation of this thread a conclusion that I need another thing to do?

I'd say give it a try, there's a good chance it'll work on the XE.

 

After performing the mod run some test programs. Here's the ATR with the testers I use: http://www.horus.com/~hias/tmp/ramdisktest.atr

 

PAGEFIND.BAS: test #1 is good at finding timing problems which other testers usually miss.

MEMDRV.COM: standard memory test ("M") and continuous memory test ("D") also runs a refresh test. Delete "MQSQ1.DAT", if present on the ATR, before running MEMDRV.COM.

 

Another good test is the "Numen" demo.

 

BTW: could you post the complete markings on your DRAM chips? Then we could check the datasheets if they also support hidden refresh.

 

so long,

 

Hias

[Marius]

PAGEFIND.BAS: test #1 is good at finding timing problems which other testers usually miss.

MEMDRV.COM: standard memory test ("M") and continuous memory test ("D") also runs a refresh test. Delete "MQSQ1.DAT", if present on the ATR, before running MEMDRV.COM.

 

Another good test is the "Numen" demo.

 

I do another test. It is quite simple. I fill the complete extended memory with a certain value. I start using my atari with 64KB software, so the extended memory is not used. Then I run my own 'check memory' tool. As soon as a "*" is printed on the screen the memory is different from the value it should be.

 

I found out years ago that as soon as the 'screen is off' (the make your atari 30% faster 'trick') the memory problem occurs even sooner.

 

"My" test is really a good one, since it is possible to do the checking days later. It really checks if the ramdisk is reliable. I can do some heavy I/O (like copying a 16MB partition) and then re-check the ramdisk.

 

My slow DRAMS (120ns, 150ns) are perfect with that Scott Peterson upgrade. Now * comes up on the screen. Even after a week of regular 64KB atari use: no * on my screen.

 

With fast DRAMS (70ns) I have * after let's say 10 minutes... or sometimes even after 10 seconds. It is rather weird!

 

BTW: could you post the complete markings on your DRAM chips? Then we could check the datasheets if they also support hidden refresh.

 

Here you go:

 

one DRAM I'm 100% sure it has this problem is:

 

MB81C4256A-70P

 

Also on the chip I read: Malaysia 9421 F72

 

This is a 4bit memory chip!

 

I bought these because I have zillion 65XE computers with 4bit memory chips. I thought: this is a very handy way of upgrading them to 320KB. I was wrong... I ended up with a very unreliable ramdisk.

 

But I am definately going to try the upgrade MetalGuy advised. I have to look if there are any free input/outputs on the existing LS08 TTL onboard.

 

thanks

Marius