On Sat, 2 May 1998 12:35:20 PDT William Chops Westfield writes: >> Is this true? Does this mean that I _can_ just use PC RAM with >>this >> type of MPU? Does anyone know about or have any experience with >>this? First decide if you really need the megabytes that DRAM offers. The smaller the memory size, the more attractive SRAM becomes. A one-MB array of two 512K x 8 SRAMs is probably a good break point for small productions. If cost is real important, then use DRAM earlier and accept the complexity. One way would be to build a developmental version using SRAM. When the software is more complete, it can be migrated to a less-costly "final" version using DRAM. Then the complexities of running DRAM and writing software to use megabytes of space don't occur at the same time. >Sure, you CAN. You'll need some sort of DRAM controller to at least >multiplex the address bus into the DRAM pins, unless you're using some >68k >variant that has a built-in DRAM controller. Some processors, maybe even some in the 68000 line, have built-in DRAM control. Just make a direct connection to the DRAM and set up a few registers. The AMD 29000 line comes to mind. These were intended to "power" laser printers, which of course need lots of memory. Imagine a 32-bit AVR chip, with an actual 30 MHz rating... How hard it is may >depend on >how fast you want the system to go - if you clock the DRAM signals in >based >on the 68k clock, you'll probably end up with a longer access cycle >than >strictly necessary. Using a separate clock gets you synchronization >issues, of course. If using a state-machine type of DRAM controller, definitely divide down the CPU clock from the state clock so it is certain to be in sync. >Some designs use delay lines here, I think. A once-popular design used 74S158 chips, a tapped delay line, and a little more TTL or a PAL. As the "memory request" signal traveled through the delay line, it would activate the DRAM in proper sequence: RAS, change address, CAS, WR. >The other thing that DRAM needs is periodic refresh - on low end >systems, >you can use "software refresh". ... This is very practical. Other than the relatively long idle time to execute a burst refresh, the performance really isn't degraded that much. With some applications, such as a DSP or communications buffer, a specific refresh action may be completely unnecessary. The data can be arranged in RAM so that normal operation is certain to read or write all the rows in the DRAM often enough. If you have more than one 'bank' of DRAM, for example using a 32-bit wide 72-pin SIMM as two banks of 16 bits, you have to refresh both banks. One way is to RAS all the chips all the time, then only CAS the ones in the bank in use. This will refresh all chips by doing enough (usually 512) consecutive reads in either bank. But in normal operation, half of the DRAMs will be activated unnecessarily so the circuit will use more power. A little more logic in the control circuit so the "refresh reads" RAS all chips but normal reads don't may be useful. > IIRC, the original IBMPC used a periodic interrupt to >start >an appropriately sized DMA (to nowhere) using the DMA controller. It worked about that way. One of the timer channels would, at about a 62 KHz rate, hit the DMA controller for a DMA cycle. The CPU wasn't involved other than giving up the bus for the DMA cycle. It was a 1 byte read of a different address each time. The DMA cycle wouldn't actually read anything, but it would activate special circuitry to RAS all the DRAMs (4 banks of 64K in the more popular "256K" model). I think this method persists into modern PC's, but of course it is now buried in the VLSI support chips on the main board. _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]