The code and diagrams can be found at github.com/trevor-makes/avr-dram-tester What other features would you like to see in a kit or assembled board? I'm working on supporting 41256 and 4116, and maybe 4416, 41464, 44256 DRAMs
Don't know where to start with the compliments. First amazing video quality, second great content, third just blown away by the deep dive knowledge. Thank you!!
Perfect!! Thank you for documenting this. I have a bunch of them to test before using them. Why would I use them? Well, just for the challenge and nostalgia. I'm building an 8-bit uP and thought it would be great to have a few banks of them and to push my knowledge a bit. Will need to check your channel if you have more content on DRAMs. Cheers.
This really is the best implementation I've seen of an efficient DRAM tester using the nano, and I really like the infinite loop switch to measure the access time! One thing I would like to see is an option to print out the first failing address and data bits through serial monitor, or to a simple display OLED screen. Even better, a code switch allowing the first N number of failures to be displayed or printed. Have you considered this type of enhancement? My coding isn't up to the level of doing it myself. But again... great work here!
Thanks! I had been considering printing the failing addresses, but figured it wasn't that helpful in the case of a bad DRAM--though I suppose it could help diagnosing if there's a loose connection in the tester/ZIF socket or something. If I get around to adding an OLED display I may take another look at this.
That's exactly what I just did using serial monitor. ALL my RAMs are failing and I wanted to find out if they really are all bad or I assembled something wrong. Since they're all failing at the first address I guess it's back to building. 😄
thx, I can use your scope technique to test memory access times on a static RAM. I have a dual port IDT7132 2K x 8 Static ram shared between a Motorola 6802 at 1MHz on a pinball machine and an AtMega 1284 at 16 MHz. The ram busy signal is fed to a D flip flop that stretches the φ2 on the 6802 when an address collides. Confirming the stretch is working to properly read the ram is the test.
That sounds tricky to implement and test! And the ATMega can get a busy signal too! I wonder if you could do something like tie both address ports to the 6802 and trigger a fake one-shot write pulse on master from the real 6802 write pulse on slave. That way every write should be delayed by the same one-shot pulse width, making the timing more predictable/stable to examine with a scope. I was just thinking that if you have the ATMega and 6802 going asynchronously, the collisions will be unpredictable and you may need a logic analyzer to grab a trace to look over after the fact.
I have some of those on hand and have been meaning to make a tester for them. The pinout is pretty different (4-bit vs 1-bit data bus), but I think I determined it was doable with similar firmware on the same microcontroller.
@@TrevorMakes have you already checked if 256kx4 Chips work as well - like the ones used in Amiga for instance 256kx4 or 1Mx4 RAM (mostly ZIP Sockets, but this can be adapted). I just bought some of those (256k x 4) and I have RAM faults, as there is plenty of those, checking them would allow easier tracking of the faulty RAMs.
I've had some requests for that and I literally have some on my desk within arms reach right now. Feels likely that I'll finally get around to it this year!
I just developed a Tester that can test a few Chips. I did not use the above mentioned Algo but I think it is rather close. Video: ua-cam.com/video/9TBlnfiTfQk/v-deo.html
Interesting project. Did you get around to creating a custom board with your custom layout? How about a second micro controller doing the timing testing using the interrupt lines?
Still on the back burner. The best I could measure with the ATmega was 50ns intervals, which was interesting, but not really that practical (and I don't have any failing/out of spec DRAM to test it with). I think the timing measurement mode with an oscilloscope is the most reliable way.
@@TrevorMakes Hmmmm how about switching up to a Raspberry Pi Pico? Use one core for the DRAM testing and one core for measurement? Plus could probably do the measurement live while reading from the RAM? That is if I remember right and the Pico has a 2 core ARM based micro controller
Maybe using the PIO of the pi pico the DRAM CAS latency could be measured in a standalone tester device. Would be nice if the device could also test SRAM ICs
I've been looking to get something to test my old DRAMs. My only comment is it would be nice to not have to plug the power cable in each time you want to test another DRAM. I'm sure I can just add another switch for power but figured I'd mention it if you ever decide to modify this version. Also, what is that board you're attaching the Arduino to? It's not in the BOM.
I've been meaning to get back to this project. If I remember correctly, I was thinking I could make an SPI display work with this. But I was also thinking about redoing the whole thing with a Pi Pico to possibly support finer access time measurement. I've got some vintage computer stuff to work on, so maybe I'll take another look at it this year.
@@TrevorMakes Just a small suggestion: Instate of combining both 4164 and 41256 into "one program" and increasing the complexity, keep the two programs separate. One program for 4164 and a different program for 41256.
I went ahead and added 41256 support to the same program since it was easy to do so with template parameters. The test does some initial writes/reads to the lower and upper address spaces to detect the type of RAM.
This is good! I have also messed with those existing projects you mentioned, and thought that they were not enough. A march test is the way to go, and I thank you for this project. I don't have enough C++ knowledge to understand and modify your code, so I need to ask you, could you extend this to cover 4116 DRAMs too? Yes, I know there are other voltages (-5V and 12V) involved here, but if those were handled, the rest should be pretty much the same.
Thanks! I think the work would mainly be in wiring up the -5 and +12 as you suggest, along with a small code tweak. I'll take a look at it when I pick up the project again. Options would be a one-off tester for just 4116, a simpler board with different sockets for 4164/256 and 4116, or a more sophisticated board with one socket that has configurable pins.
Nice project. I build it and having some problems with it. All my 4164 ICs were measured bad. With my logic analyser i figured out that PD0 and PD1 ~7us after powerup are permanently in a HIGH state, while all other pins toggle correctly. I tried several NANOs but on all it the same issue. At first i thought the FTDI/CH340 is the problem and removed them, but the issue still exists. Is there any fix i can try to solve the problem?
After further testing i found the error. Somehow PlatformIO programmed the wrong firmware after compiling. I removed the ATMega328 from the NANO Board and verified the written firmware with the firmware from the PlatformIO folder and they were different. After that i flashed the firmware from the PlatformIO output folder and now the RAM Tester Workshop flawlessly. Strangely the issue occurrred on several NANOs i used. Each time the firmware was recompiled and the issue kept occuring
That's strange. On the official Nano as well as the clone boards I have, there are 1K resistors between D0/D1 and the USB serial chip, which should keep it from interfering too much with anything directly connected to D0/D1. Are you using the tester while powered with a computer-and are you keeping a serial monitor open-or are you powering it with a USB power adapter? If you went as far as removing the USB chip, that definitely shouldn't be affecting D0/D1. Edit: oh you checked the signals with your logic analyzer hm... Without the DRAM in place and the circuit off, is there continuity between those pins and the 5V rail? Can you try a simple Arduino sketch that configures those pins and toggles them high/low in a loop to see if there's something weird with your Nanos?
Bah, I just now saw your followup where you found the problem. Hard to sort through comments in the YT Studio app... Glad you found the problem. Very strange about the firmware. I've had a few random Nano clones where I've had to reflash them with an ISP to get them working, so I know that pain.
Interesting. I have the same problem. D0 and D1 are always HI/5v on my cheap Nano clone. I'm relatively sure PlatformIO uploads the correct hex. I assume the RX/TX is the cause in my case. Trying to figure out if I can configure them to act as I/O only.
Man that access time mode is the bees knees! Just found out the seller actually scammed me by sending me 80ns chips relabeled as 120ns. 😄 I guess I can live with that.
I just push random data N amount of times and that's it. if any bit it wrong, i will see it. any address is wrong, \I see it. This can detect every single possible problem with memory. and so easy ti implement
Do you write a bit and then immediately read it back, or do you write the whole pattern before reading it back (using the same seed)? Do you then write the same random pattern inverted so you make sure to cover both 0 and 1 at every bit?
In platformIO? Maybe the atmelavr platform isn't installed, but platformIO should do that for you. The code will also work with the standalone avr-gcc and avrdude tools.
The code and diagrams can be found at github.com/trevor-makes/avr-dram-tester
What other features would you like to see in a kit or assembled board? I'm working on supporting 41256 and 4116, and maybe 4416, 41464, 44256 DRAMs
44256 would be great ,because a lot of Amiga users need them. That’s a huge, if not even the biggest retrocomputing community, after c64!
Don't know where to start with the compliments. First amazing video quality, second great content, third just blown away by the deep dive knowledge. Thank you!!
Thank you for the kind words!
@@TrevorMakeshello is it possible to do this with ddr1 tsop66 chip?
Cheers! I just used tester (it was quick to set up on a breadboard) with some DRAM I purchased online. Out of the 20, 16 are working perfectly.
Thank you for this great project. I am diagnosing a non-booting Kaypro IV and this has helped me diagnose few bad chips.
I would be interested in one and as far as options, I guess everybody loves to see LCD screens. -Mark
Thank you for this very informative video.
Perfect!! Thank you for documenting this. I have a bunch of them to test before using them. Why would I use them? Well, just for the challenge and nostalgia. I'm building an 8-bit uP and thought it would be great to have a few banks of them and to push my knowledge a bit. Will need to check your channel if you have more content on DRAMs. Cheers.
This really is the best implementation I've seen of an efficient DRAM tester using the nano, and I really like the infinite loop switch to measure the access time! One thing I would like to see is an option to print out the first failing address and data bits through serial monitor, or to a simple display OLED screen. Even better, a code switch allowing the first N number of failures to be displayed or printed. Have you considered this type of enhancement? My coding isn't up to the level of doing it myself. But again... great work here!
Thanks! I had been considering printing the failing addresses, but figured it wasn't that helpful in the case of a bad DRAM--though I suppose it could help diagnosing if there's a loose connection in the tester/ZIF socket or something. If I get around to adding an OLED display I may take another look at this.
That's exactly what I just did using serial monitor. ALL my RAMs are failing and I wanted to find out if they really are all bad or I assembled something wrong. Since they're all failing at the first address I guess it's back to building. 😄
thx, I can use your scope technique to test memory access times on a static RAM.
I have a dual port IDT7132 2K x 8 Static ram shared between a Motorola 6802 at 1MHz on a pinball machine and an AtMega 1284 at 16 MHz. The ram busy signal is fed to a D flip flop that stretches the φ2 on the 6802 when an address collides. Confirming the stretch is working to properly read the ram is the test.
That sounds tricky to implement and test! And the ATMega can get a busy signal too! I wonder if you could do something like tie both address ports to the 6802 and trigger a fake one-shot write pulse on master from the real 6802 write pulse on slave. That way every write should be delayed by the same one-shot pulse width, making the timing more predictable/stable to examine with a scope. I was just thinking that if you have the ATMega and 6802 going asynchronously, the collisions will be unpredictable and you may need a logic analyzer to grab a trace to look over after the fact.
Is it possible to add 44256 dram as well?
These are used as well in retrocomputers and have a DIP20 package
I have some of those on hand and have been meaning to make a tester for them. The pinout is pretty different (4-bit vs 1-bit data bus), but I think I determined it was doable with similar firmware on the same microcontroller.
@@TrevorMakes have you already checked if 256kx4 Chips work as well - like the ones used in Amiga for instance 256kx4 or 1Mx4 RAM (mostly ZIP Sockets, but this can be adapted).
I just bought some of those (256k x 4) and I have RAM faults, as there is plenty of those, checking them would allow easier tracking of the faulty RAMs.
It’ll be great to have a similar solution for 41256 and 44256 DRAM chips , they are quite often used in vintage computers as well!
I've had some requests for that and I literally have some on my desk within arms reach right now. Feels likely that I'll finally get around to it this year!
I join in here - the 44256 are used in Amiga 500
I just developed a Tester that can test a few Chips. I did not use the above mentioned Algo but I think it is rather close. Video: ua-cam.com/video/9TBlnfiTfQk/v-deo.html
Interesting project.
Did you get around to creating a custom board with your custom layout?
How about a second micro controller doing the timing testing using the interrupt lines?
Still on the back burner. The best I could measure with the ATmega was 50ns intervals, which was interesting, but not really that practical (and I don't have any failing/out of spec DRAM to test it with). I think the timing measurement mode with an oscilloscope is the most reliable way.
@@TrevorMakes
Hmmmm how about switching up to a Raspberry Pi Pico?
Use one core for the DRAM testing and one core for measurement? Plus could probably do the measurement live while reading from the RAM?
That is if I remember right and the Pico has a 2 core ARM based micro controller
That's a good idea. I think I had been considering the Pi Pico for that. I should give that a try!
@@TrevorMakesThe PIO blocks could also be interesting for this purpose.
Maybe using the PIO of the pi pico the DRAM CAS latency could be measured in a standalone tester device. Would be nice if the device could also test SRAM ICs
Good idea! Yeah, I've been thinking about doing exactly that when I pick this project up again
I've been looking to get something to test my old DRAMs. My only comment is it would be nice to not have to plug the power cable in each time you want to test another DRAM. I'm sure I can just add another switch for power but figured I'd mention it if you ever decide to modify this version.
Also, what is that board you're attaching the Arduino to? It's not in the BOM.
Will there be a version with a display ?
I've been meaning to get back to this project. If I remember correctly, I was thinking I could make an SPI display work with this. But I was also thinking about redoing the whole thing with a Pi Pico to possibly support finer access time measurement. I've got some vintage computer stuff to work on, so maybe I'll take another look at it this year.
I wonder if modern PC drams can be tested, obviously using a modified circuit and code
PLEASE PLEASE add support for 41256.
I personal restoration work is pending due to a proper DRAM tester.
PLEASE.
I have some 41256 coming in the mail. I'll add support for those in this version of the tester.
@@TrevorMakes Just a small suggestion:
Instate of combining both 4164 and 41256 into "one program" and increasing the complexity, keep the two programs separate.
One program for 4164 and a different program for 41256.
I went ahead and added 41256 support to the same program since it was easy to do so with template parameters. The test does some initial writes/reads to the lower and upper address spaces to detect the type of RAM.
This is good! I have also messed with those existing projects you mentioned, and thought that they were not enough. A march test is the way to go, and I thank you for this project. I don't have enough C++ knowledge to understand and modify your code, so I need to ask you, could you extend this to cover 4116 DRAMs too? Yes, I know there are other voltages (-5V and 12V) involved here, but if those were handled, the rest should be pretty much the same.
Thanks! I think the work would mainly be in wiring up the -5 and +12 as you suggest, along with a small code tweak. I'll take a look at it when I pick up the project again. Options would be a one-off tester for just 4116, a simpler board with different sockets for 4164/256 and 4116, or a more sophisticated board with one socket that has configurable pins.
@@TrevorMakes Thanks! I think the best approach would be a single board with 2 ZIF sockets.
Great Video Travis! Will this tester work on 4060 4k DRAM?
Nice project.
I build it and having some problems with it. All my 4164 ICs were measured bad. With my logic analyser i figured out that PD0 and PD1 ~7us after powerup are permanently in a HIGH state, while all other pins toggle correctly. I tried several NANOs but on all it the same issue. At first i thought the FTDI/CH340 is the problem and removed them, but the issue still exists. Is there any fix i can try to solve the problem?
After further testing i found the error. Somehow PlatformIO programmed the wrong firmware after compiling. I removed the ATMega328 from the NANO Board and verified the written firmware with the firmware from the PlatformIO folder and they were different. After that i flashed the firmware from the PlatformIO output folder and now the RAM Tester Workshop flawlessly. Strangely the issue occurrred on several NANOs i used. Each time the firmware was recompiled and the issue kept occuring
That's strange. On the official Nano as well as the clone boards I have, there are 1K resistors between D0/D1 and the USB serial chip, which should keep it from interfering too much with anything directly connected to D0/D1. Are you using the tester while powered with a computer-and are you keeping a serial monitor open-or are you powering it with a USB power adapter? If you went as far as removing the USB chip, that definitely shouldn't be affecting D0/D1. Edit: oh you checked the signals with your logic analyzer hm... Without the DRAM in place and the circuit off, is there continuity between those pins and the 5V rail? Can you try a simple Arduino sketch that configures those pins and toggles them high/low in a loop to see if there's something weird with your Nanos?
Bah, I just now saw your followup where you found the problem. Hard to sort through comments in the YT Studio app... Glad you found the problem. Very strange about the firmware. I've had a few random Nano clones where I've had to reflash them with an ISP to get them working, so I know that pain.
Interesting. I have the same problem. D0 and D1 are always HI/5v on my cheap Nano clone. I'm relatively sure PlatformIO uploads the correct hex. I assume the RX/TX is the cause in my case. Trying to figure out if I can configure them to act as I/O only.
Well - powering the Nano through it's 5V pin instead of USB didn't solve it.
Man that access time mode is the bees knees! Just found out the seller actually scammed me by sending me 80ns chips relabeled as 120ns. 😄 I guess I can live with that.
I just push random data N amount of times and that's it. if any bit it wrong, i will see it. any address is wrong, \I see it. This can detect every single possible problem with memory. and so easy ti implement
Do you write a bit and then immediately read it back, or do you write the whole pattern before reading it back (using the same seed)? Do you then write the same random pattern inverted so you make sure to cover both 0 and 1 at every bit?
It can't find #include
In platformIO? Maybe the atmelavr platform isn't installed, but platformIO should do that for you. The code will also work with the standalone avr-gcc and avrdude tools.