stephen@hpdmd48.HP.COM (Stephen Holmstead) (03/01/90)
Ok, hardware experts. I built a DRAM memory expansion board that seems to work for me: I wrote a 'C' program that can read and write to all locations. I have tried different patterns, etc. It works. OK. I have not put on any autoconfig hardware, so I try to add this memory to the system free memory list with ADDMEM and ADDMEM dies stating 'Couldn't clear memory. Memory location bad.' What? I can read and write just fine. What's wrong? What does ADDMEM do that I don't? Here is an output of the key signals during a read access (I also have them for the writes, if desired). Is there any major faults in this picture? What are the pitfalls that I should look for? CDAC |-------_______-------_______-------_______-------_______-------_______| _AS |-------------___________________________________----------------------| R_W |----------------------------------------------------------------------| _RAS |---------------__________________________________---------------------| _CAS |--------------------______________________________--------------------| _UDS |-------------___________________________________----------------------| _LDS |-------------___________________________________----------------------| _OVR |-------------__________-----------------------------------------------| _DTACK|-----------------------__________________________---------------------| D0-15 |++++++++++++++++++++++++=======================================+++++++| CDAC |-------_______-------_______-------_______-------_______-------_______| NOTE: each character is 10 ns wide. KEY: --- High signal ___ Low signal +++ High impedence state === valid (High or Low) signal SIGNALS: CDAC - 7M clock signal (pin 15) _AS - Address strobe (pin 74) R_W - Read/Write (pin 68) _RAS - Row address strobe (not on expansion bus) _CAS - Column address strobe (not on expansion bus) _UDS - Upper data strobe (pin 72) _LDS - Lower data strobe (pin 68) _OVR - Override strobe (pin 17) _DTACK - Data transfer acknowledge (pin 66) D0-15 - Data lines I have a couple of other questions: Since the 7M clock that feeds the MC68000 is not available on the bus, I am using the CDAC. Is this ok? I think I have seen a couple of time when this clock appeared to glitch. Is this true? On the schematics for the A500, the CDAC appears to get inverted before it gets to the expansion bus. Does this put it 90 degrees out of phase with the 7M clock? Or is it already out of phase? Is this a good clock signal? Also, since the "GARY" chip automagically generates the _DTACK signal for the MC68000, I am using the _OVR signal on the expansion bus (that feeds into "GARY") to keep the _DTACK from falling before my data is ready. Is this the "correct" thing to do? I noticed that there is also a _OVL signal. What is that for? Since the data latches on the falling edge of the clock following the first falling edge of the clock that latches the fall of _DTACK, doesn't the UDS and LDS still have to be valid at this point. According the the CDAC, the UDS and LDS rise about 20 ns BEFORE the data is latched. Are there any common hints that I can try to get this thing to work with an Amiga? Thanks for your patience in reading through this. Remember, I'm a CS weenie, not an EE weenie. ____ ____ | / /_ __\ | Disk 0S/2 == 1/2 OS (Leo Schwab) Stephen Holmstead | | / / /_/ | | Mechanism // ...!hplabs!hpdmlge!stephen |___\ / /___| Division \X/ Amiga stephen@hpdmlge.boi.hp.com
daveh@cbmvax.commodore.com (Dave Haynie) (03/02/90)
In article <19770001@hpdmd48.HP.COM> stephen@hpdmd48.HP.COM (Stephen Holmstead) writes: >I have not put on any autoconfig hardware, so I try to add this memory to >the system free memory list with ADDMEM and ADDMEM dies stating 'Couldn't >clear memory. Memory location bad.' What? I can read and write just fine. >What's wrong? What does ADDMEM do that I don't? I'm not sure what ADDMEM is doing, but writing memory tests that fully test memory is a fine art. I'm not claiming to be able to do this either -- I have about 7 different type of memory tests I use here at work, and I've still had boards pass them all but not run code correctly. A good memory test should test various data patterns, most do this. It should also try byte, word, and longword accesses to the memory. It should run a unique address test. A random address and word-width test is another good one; such a test picks an address within a range at random, writes a random value there with a random word width, then reads it back. It's probably possible to vary this theme and come up with a test that simulates code. Also, watch out for C coding. Another aspect of a good test is that you run as many consecutive cycles as possible; a C program running in Chip memory may only touch your memory occasionally. And it couldn't hurt to have a refresh test as well for testing DRAM -- you write out your patterns, wait a few seconds, then read them back. >Here is an output of the key signals during a read access (I also have them >for the writes, if desired). Is there any major faults in this picture? >What are the pitfalls that I should look for? s1 s2 s3 s4 s5 s6 s7 7M |---_______-------_______-------_______-------_______-------_______----| >CDAC |-------_______-------_______-------_______-------_______-------_______| >_AS |-------------___________________________________----------------------| >R_W |----------------------------------------------------------------------| >_RAS |---------------__________________________________---------------------| >_CAS |--------------------______________________________--------------------| >_UDS |-------------___________________________________----------------------| >_LDS |-------------___________________________________----------------------| >_OVR |-------------__________-----------------------------------------------| >_DTACK|-----------------------__________________________---------------------| >D0-15 |++++++++++++++++++++++++=======================================+++++++| >CDAC |-------_______-------_______-------_______-------_______-------_______| There's at least one mistake here. What are you trying to do with _OVR? Whatever it is, it's wrong. The _OVR signal is normally used to allow your board to control _DTACK, rather than using the A500 supplied _DTACK. If that's your intention (you driving _DTACK), you want _OVR to stay asserted as long as your board is selected. If you simply want to delay the automatic _DTACK, XRDY does what you want, pretty much the way you're driving _OVR up above. The only other thing that's obvious here is that you're holding onto data much longer than necessary. The 68000 latches read data on the clock edge between s6 and s7; there's no reason to hold data after _AS is negated. >I have a couple of other questions: Since the 7M clock that feeds the >MC68000 is not available on the bus, I am using the CDAC. Is this ok? Not in the general case; it's hard to tell if you're getting into trouble based on that or not here. I drew in a rought 7M clock; some folks use the approximation: 7M_EQUIV = _C1 XNOR _C3 That's almost always better than using CDAC, unless you're really careful to account for CDAC in your design. >I think I have seen a couple of time when this clock appeared to glitch. >Is this true? I've never know this to be the case, but I haven't mucked around with A500s much. You may need to play around with some termination on the clock lines on your board to get the best clocks. >On the schematics for the A500, the CDAC appears to get >inverted before it gets to the expansion bus. Does this put it 90 degrees >out of phase with the 7M clock? Or is it already out of phase? Is this >a good clock signal? The Agnus chip actually creates the _CDAC signal, as well as C1 and C3. For the expansion connector or the Zorro II bus, you get CDAC, _C1, and _C3. There's nothing wrong with using any of these clocks as long as you know what you're doing. >Also, since the "GARY" chip automagically generates the _DTACK signal for >the MC68000, I am using the _OVR signal on the expansion bus (that feeds >into "GARY") to keep the _DTACK from falling before my data is ready. Is >this the "correct" thing to do? No. Whether you need to modify _DTACK or not depends on your memory. The 68000 will never run a cycle in less than 4 clocks; if you always have your data ready 10ns or better before the S6-S7 clock edge, you don't need to worry about _DTACK at all. If you simply want to delay _DTACK, use XRDY, as mentioned above. >I noticed that there is also a _OVL signal. What is that for? OVL is the ROM overlay signal, which tells Gary to put ROM down at location $00000000 so the system can get its reset vector on reset. You can't get to this from the expansion, and don't need it. >Since the data latches on the falling edge of the clock following the first >falling edge of the clock that latches the fall of _DTACK, doesn't the UDS >and LDS still have to be valid at this point. According the the CDAC, the >UDS and LDS rise about 20 ns BEFORE the data is latched. Look at my 7M drawing; you seem to be a bit confused about when data is actually being latched. >Thanks for your patience in reading through this. Remember, I'm a CS weenie, >not an EE weenie. Hey, you've got to start somewhere. >| / /_ __\ | Disk 0S/2 == 1/2 OS (Leo Schwab) Stephen Holmstead -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough