My particular C64 uses 8 individual RAM chips most are D4164C-15 and a couple are D4164C-2. I replaced all the RAM but I wanted to know if both the original and replacement chips were functioning properly. I decided to test each chip, I needed some hardware to test with.
I decided to use a MEGA8U2 AVR microprocessor, mainly because I have one that can plug into a breadboard and it has enough pins to drive the D4164C chips.
I wired the test setup to try to reduce the instruction count where I could so it is a little messy. Wiring and instruction count could be greatly improved if I didn't need the programming header, but it gets the job done.
At this point I realized I had no idea how to control DRAM. My friend CNLohr gave me a quick explanation of how DRAM works (basically you have to refresh it within time period and this ram appears to be 256 rows by 256 columns). Ok...
The first thing to do was to try to write and read just one bit. The datasheet for the DRAM provided timing windows charts for each step required when perform all of the operations the memory is able to do. After a few hours of stepping through the charts, coding, re-coding, reviewing the charts, and sometimes just trial and error, I finally was able to write and read 1 bit from memory. After a couple more days of work I was reading and writing to the entire memory module. (I forget exactly what made this take so long to accomplish. Some kind of bug in my program.)
I constructed a couple of routines to test both the wiring and the memory. The tests are largely based off of information found at http://www.ganssle.com/testingram.htm. There's a lot of good information there for developing ram tests.
To test the wires I wrote 0 to the first bit of the memory followed by a 1 to a power of 2 memory location (high on just 1 wire). I then read memory location zero and if the value is no longer 0, it indicates a failure on a specific address wire.
I used a walking one algorithm with a bit inversion to test all the memory cells. The goal is to toggle as many bits as possible.
In either case if there's an error, the red LED would turn off forever. While the test is running, the LED will blink at the end of each complete cycle.
I was able to test all the memory modules I had replaced. They were all functioning properly.
Update 5/5/2012:
The source code can be found at https://github.com/axlecrusher/AvrProjects/tree/master/avr_dramTest
I decided to use a MEGA8U2 AVR microprocessor, mainly because I have one that can plug into a breadboard and it has enough pins to drive the D4164C chips.
I wired the test setup to try to reduce the instruction count where I could so it is a little messy. Wiring and instruction count could be greatly improved if I didn't need the programming header, but it gets the job done.
At this point I realized I had no idea how to control DRAM. My friend CNLohr gave me a quick explanation of how DRAM works (basically you have to refresh it within time period and this ram appears to be 256 rows by 256 columns). Ok...
The first thing to do was to try to write and read just one bit. The datasheet for the DRAM provided timing windows charts for each step required when perform all of the operations the memory is able to do. After a few hours of stepping through the charts, coding, re-coding, reviewing the charts, and sometimes just trial and error, I finally was able to write and read 1 bit from memory. After a couple more days of work I was reading and writing to the entire memory module. (I forget exactly what made this take so long to accomplish. Some kind of bug in my program.)
I constructed a couple of routines to test both the wiring and the memory. The tests are largely based off of information found at http://www.ganssle.com/testingram.htm. There's a lot of good information there for developing ram tests.
To test the wires I wrote 0 to the first bit of the memory followed by a 1 to a power of 2 memory location (high on just 1 wire). I then read memory location zero and if the value is no longer 0, it indicates a failure on a specific address wire.
I used a walking one algorithm with a bit inversion to test all the memory cells. The goal is to toggle as many bits as possible.
In either case if there's an error, the red LED would turn off forever. While the test is running, the LED will blink at the end of each complete cycle.
I was able to test all the memory modules I had replaced. They were all functioning properly.
Update 5/5/2012:
The source code can be found at https://github.com/axlecrusher/AvrProjects/tree/master/avr_dramTest
If we have any other old systems lying around, would you want to mess with them? We might still have original Tandy, etc.
ReplyDeleteMaybe. It depends on how complex it is and its certainly not free. It cost quite a lot to get the Commodore 64 working.
DeleteSo what ended up being wrong with the Commodore 64?
ReplyDeleteBurned out quad AND gate.
DeleteCorrection. After going back and looking at my records, replacing the 2 CD4066 quad bilateral switches fixed the problems. The switch that was faulty couples the color RAM to the bus.
DeleteHeh. I have a few old boards here including one from a Sirius.
ReplyDeleteDoes anyone have a use for them because it seems a shame to waste em, mailto mandoline at cwgsy dot net :)
Hi alexcrusher, actually trying to set this up for an atmega328p, but in your sources I don't find usb.h, so I cannot compile. Well, not very used to the blogger site, too. How could I contact you? Thanks, Dominik
ReplyDeleteHi dagrubar, I don't think the usb.h header is actually needed. It may compile if you comment out the line in test.c. If its actually needed let me know and I can try to find the file on my other computer.
DeleteWow, thanks a lot! Right, I could compile and flash it. Will try to plug all together tomorrow.
DeleteGood luck. I didn't make a wiring diagram but d4164.c has the pinout mapping.
DeleteUhhh, there is no PC7 on the atmega328p and PC6 is reset. Aaaargl...
ReplyDeletePC6 and PC7 were a piece of cake. Just two changes in d4164.h, but PB6 and PB7 are hard...
DeleteDid you get it working?
DeleteNah, not yet. I have ordered a ATMEGA32-16PU in China to be more compatible, but it hasn't arrived yet...
DeleteAxlecrusher, I cannot get this code to compile without numerous errors. Can you let me know what you used to compile it please and also the source of the USB.H file? Thank you.
ReplyDeleteHello. I used avr-gcc to compile. It has been so long, I don't remember the version. I'll pull out my laptop later today and see if I can get it compiling. I'll keep you posted.
DeleteThis comment has been removed by the author.
ReplyDeleteThank you, I'd really appreciate that. Even if you have just the HEX that would be great, Cheers.
ReplyDeleteHi Axelcrusher,
ReplyDeleteDid you get anywhere with this trying to compile this again?
It should be compiling again. Pull the git repo again. There will be some warnings but, it should compile. I didn't test it with avr hardware. I'm using avr-gcc version 4.8.1
DeleteOkay, I'll try that again, cheers. One more question: The other leg of that LED, is it going to GND or Vcc?
ReplyDeleteI really should have made a wiring diagram for this. Judging from the code the LED is on port B4 (https://github.com/axlecrusher/AvrProjects/blob/master/avr_dramTest/test.c#L68). DDRB has bit 4 set high (https://github.com/axlecrusher/AvrProjects/blob/master/avr_dramTest/test.c#L59) so that sets port B4 to output mode. That should make it a current source, so the other leg of the led will be going to ground.
DeleteThank you, I did think that was the case, but thanks for checking.
ReplyDelete