Hugo Holden
Veteran Member
I thought I should report some interesting findings in my PET which involve defective DRAM. Because, it is somewhat unusual.
In my quest to check DRAM, I wrote an assembly language program to write to the DRAM from page 04 up to page 7F.
Nothing fancy as the program is still in evolution and I am only just learning to code 6502 assembly language.
So initially I got it working (it required self modifying code to avoid using page 0)
The program I wrote resides in page 03 where the cassette buffers are.
In any case, so far it does something really simple. All it does at the moment is fill the user memory with byte 00 from addresses $0400 to $7FF0. Once it does that it returns to BASIC. ( I can do this in BASIC of course, but it takes ages to do it, but only a second or two with the assembly language program).
Once I had filled the memory with byte 00, then I have been inspecting it with BASIC, to PEEK the locations.
I found that my DRAM had four defective locations in the upper part of page 06 that did not retain the 0 written there.
But, the plot seriously thickens:
One of the four defective locations at address decimal value 1667 is behaving very strangely. Not only does it not "remember' the 0 that was written to it, it has another strange peculiarity. When "Peek'd" it will return a different value depending on how it is done. For example, if the bytes around it are Peek'd with a FOR-NEXT loop the location 1667 returns a value of 96 (when it should have been zero). But, if the location is individually Peek'd it returns a value of 244. Yet the other three defective locations in this region at least return the same value, regardless if they are Peek'd as a one off , or Peek'd by a loop.
This might go to show some of the unusual time or pattern sensitive faults, that can crop up in this 4116 DRAM, making the notion of an accurate DRAM memory check program much more difficult than it looks on face value.
I have attached two screen images showing these issues.
In my quest to check DRAM, I wrote an assembly language program to write to the DRAM from page 04 up to page 7F.
Nothing fancy as the program is still in evolution and I am only just learning to code 6502 assembly language.
So initially I got it working (it required self modifying code to avoid using page 0)
The program I wrote resides in page 03 where the cassette buffers are.
In any case, so far it does something really simple. All it does at the moment is fill the user memory with byte 00 from addresses $0400 to $7FF0. Once it does that it returns to BASIC. ( I can do this in BASIC of course, but it takes ages to do it, but only a second or two with the assembly language program).
Once I had filled the memory with byte 00, then I have been inspecting it with BASIC, to PEEK the locations.
I found that my DRAM had four defective locations in the upper part of page 06 that did not retain the 0 written there.
But, the plot seriously thickens:
One of the four defective locations at address decimal value 1667 is behaving very strangely. Not only does it not "remember' the 0 that was written to it, it has another strange peculiarity. When "Peek'd" it will return a different value depending on how it is done. For example, if the bytes around it are Peek'd with a FOR-NEXT loop the location 1667 returns a value of 96 (when it should have been zero). But, if the location is individually Peek'd it returns a value of 244. Yet the other three defective locations in this region at least return the same value, regardless if they are Peek'd as a one off , or Peek'd by a loop.
This might go to show some of the unusual time or pattern sensitive faults, that can crop up in this 4116 DRAM, making the notion of an accurate DRAM memory check program much more difficult than it looks on face value.
I have attached two screen images showing these issues.