per
Veteran Member
I've been working on a memory daugthercard for an expansion to the Tiki-100 computer, but I'm having problems with odd data-corruptions whenever I try to use it.
This far I've made a prototype PCB I've etched myself, and I've made one using a factory-made PCB. Both show a somewhat similar behaviour: At very spesiffic address patterns, in the entire RAM and not just at the dedicated expansion area. It's almost always addresses ending with 111000xx00 that gets corrupted, the higer in memory the worse it gets. It's seemingly random, but the number of corruptions at different address areas are more or less the same.
I've tested for several things. Very first I used the factory-made PCB, thinking something was wrong with the prototype. Then I swapped RAM chips with some in the system itself, but the RAM chips were fine. Thinking there must have been something wrong with the soldering, I reflowed everything but still no success.
But just now I thought about that maybe there was something wrong with the timing. Originally the card had 41256 style DRAM chips rated for 150ns, but when I got memory for the daugthercard I got a whole bunch of 80ns Intel 21456 chips. Since these had slightly thinner plastic packages, I replaced all the original chips with the 80ns version (it's a very tight fit, about 2mm clearing to the metal top plate with the sockets I'm using). Going back to the original chips on the main card, then it works with the daugthercard without giving errors (only problem is that now I need a few more to put in the daugthercard).
What's puzzling me is that the 80ns chips work very fine when I only use them in the two banks originally on the card (0-512K). Used together with the memory daugthercard (512K-768K), it fails every single time with the same weird corruption patterns.
---------------------------------------
For testing I use a program in ROM that rep stosb a 4K block of data at a time, then tries to xor the whole thing with the original byte pattern to check for errors.
All memory banks have their own separate /RAS line, otherwise they share the exact same input signals.
This far I've made a prototype PCB I've etched myself, and I've made one using a factory-made PCB. Both show a somewhat similar behaviour: At very spesiffic address patterns, in the entire RAM and not just at the dedicated expansion area. It's almost always addresses ending with 111000xx00 that gets corrupted, the higer in memory the worse it gets. It's seemingly random, but the number of corruptions at different address areas are more or less the same.
I've tested for several things. Very first I used the factory-made PCB, thinking something was wrong with the prototype. Then I swapped RAM chips with some in the system itself, but the RAM chips were fine. Thinking there must have been something wrong with the soldering, I reflowed everything but still no success.
But just now I thought about that maybe there was something wrong with the timing. Originally the card had 41256 style DRAM chips rated for 150ns, but when I got memory for the daugthercard I got a whole bunch of 80ns Intel 21456 chips. Since these had slightly thinner plastic packages, I replaced all the original chips with the 80ns version (it's a very tight fit, about 2mm clearing to the metal top plate with the sockets I'm using). Going back to the original chips on the main card, then it works with the daugthercard without giving errors (only problem is that now I need a few more to put in the daugthercard).
What's puzzling me is that the 80ns chips work very fine when I only use them in the two banks originally on the card (0-512K). Used together with the memory daugthercard (512K-768K), it fails every single time with the same weird corruption patterns.
---------------------------------------
For testing I use a program in ROM that rep stosb a 4K block of data at a time, then tries to xor the whole thing with the original byte pattern to check for errors.
All memory banks have their own separate /RAS line, otherwise they share the exact same input signals.
Last edited: