DRAM data retention time

A place to discuss everything Dragon related that doesn't fall into the other categories.
sorchard
Posts: 463
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

DRAM data retention time

Post by sorchard »

Someone who shall remain nameless put the idea in my head that I may not need the 74LS785 version of the SAM in my 256K Dragon, as there is a chance the video display could refresh the memory often enough to do the job.

Naturally I was curious to find out just how long the memory could last without being refreshed, so I created this program to help find out.

It works by writing a test pattern to memory, running in fast mode for a set time (such that refresh is disabled), and then checking the test pattern for changes.

The obvious problem is the program needs to be refreshed so that it doesn't become corrupted during the test. My solution is to arrange the program in memory carefully so that it occupies a subset of the memory rows. The program can then refresh itself while the test is running on the rows not occupied by the program. To ensure all memory is covered the program moves itself between one set of rows and another.

It seems the memory can last a surprisingly long time. I'm getting 2-3 seconds with 4164 & 41256 DRAMs (even longer when cold). The 4116 type DRAMs in a Dragon 32 were much less impressive, lasting only about 350ms.

wav/bin/source files and further info can be found here:
https://gitlab.com/sorchard001/dragon-refresh-test

Oh, and there's a stable text display while in fast mode :)
Stew
User avatar
robcfg
Posts: 1350
Joined: Sat Apr 04, 2009 10:16 pm
Location: Stockholm, Sweden

Re: DRAM data retention time

Post by robcfg »

Can it be run from a cartridge?

It may be way easier to program an eeprom or run it from the DragonMMC.

And, did I read 256KB Dragon? :mrgreen:
sorchard
Posts: 463
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: DRAM data retention time

Post by sorchard »

The .bin file is actually a DragonDos binary which you may be able to put on an SD card.

I've now added a cartridge rom image to the repo anyway.

Yeah, the 256K machine has been kicking around for years with a rats nest of wiring in it. It's an old school banked memory style upgrade with 41256 DRAMs on the main board. I recently built a much better prototype and have designed a pcb which I hope to be ordering soon. It's not a beginner project but is easier than the 32K to 64K upgrade. The possibility that it will work well enough with the original SAM chip makes it more viable.
Stew
sorchard
Posts: 463
Joined: Sat Jun 07, 2014 9:43 pm
Location: Norwich UK

Re: DRAM data retention time

Post by sorchard »

sorchard wrote: Fri Apr 23, 2021 12:42 pm easier than the 32K to 64K upgrade
I meant to say that it's easier from 64K to 256K than it is from 32K to 64K.

The reason being that the 41256 DRAMs are virtually pin compatible with 4164.
Stew
bluearcus
Posts: 94
Joined: Wed Sep 07, 2016 4:45 pm

Re: DRAM data retention time

Post by bluearcus »

Most interesting! So it seems that fixing the NHS signal on one of my Dragon64s was a bit of a waste of time then :-)
prime
Posts: 257
Joined: Fri Apr 10, 2009 1:40 am

Re: DRAM data retention time

Post by prime »

I keep wondering about using SRAM for a memory upgrade after all 512K RAMs can be had pretty cheap nowadays, and you don't have the problem with refresh. However you would have to demux the Z0..Z7 lines from the SAM, and cope with the fact that the Dragon & CoCo designs rely on the fact that
generally DRAMS have separate Din and Dout pins.

Cheers.

Phill.
sixxie
Posts: 1176
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: DRAM data retention time

Post by sixxie »

prime wrote: Sun May 09, 2021 9:32 pm I keep wondering about using SRAM for a memory upgrade after all 512K RAMs can be had pretty cheap nowadays, and you don't have the problem with refresh. However you would have to demux the Z0..Z7 lines from the SAM, and cope with the fact that the Dragon & CoCo designs rely on the fact that
generally DRAMS have separate Din and Dout pins.
Definitely possible, and straightforward:
ramboard.jpg
ramboard.jpg (2.25 MiB) Viewed 1206 times
You can see it plugs in where the latches/transceivers to the VDG and CPU go, which is how it somewhat solves the Din/Dout thing.

The "only" problem with that (only 128K) board is it doesn't work in high speed mode. As "someone" pointed out to me, I oops missed a CPU latch. Ah well, that's what prototypes are for. Working on a 512K internal version...
pser1
Posts: 1416
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: DRAM data retention time

Post by pser1 »

a great job, congrats!
These are really great news, Ciaran
I would really like to add an internal 512Kb RAM expansion to my Dragon-MSX2+
That will be the icing on the cake!!
I asume that it will go in the SAM socket and the SAM will go on the new module, right?
You can put me down for one
thanks in advance
pere
sixxie
Posts: 1176
Joined: Fri Jul 18, 2008 8:36 am
Location: Hertfordshire
Contact:

Re: DRAM data retention time

Post by sixxie »

Oh, ok! I was mostly just mucking about, seeing what sort of thing worked if I wanted to potentially make a whole replacement motherboard. That's a long way off though, and PCB places tend to have a minimum order, so if the 512K revision works, I'll be sure to let you know.
pser1
Posts: 1416
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: DRAM data retention time

Post by pser1 »

sixxie wrote: Tue May 11, 2021 12:27 pm Oh, ok! I was mostly just mucking about, seeing what sort of thing worked if I wanted to potentially make a whole replacement motherboard. That's a long way off though, and PCB places tend to have a minimum order, so if the 512K revision works, I'll be sure to let you know.
thanks a lot!
I am pretty sure that there will be more people interested and more when John's MSX2+ boards will be available too
We could end up with a very powerful machine!
Of course we need to convert a lot of games and utilities to attract people to this hdw solution!
By now I have the AGD engine already converted for the MSX2 graphic mode G4 (256x192 bitmapped) 16 colours out of a palette 512 colours
with sound and music supported too ...
cheers
pere
Last edited by pser1 on Fri May 14, 2021 11:03 am, edited 1 time in total.
Post Reply