More Bringing up a CPM

of all those SRAM boards, there must be one which you believe is pretty solid. IF the bus drivers on your DRAM board are socketed, so you can remove them, perhaps you could put that board in the system as well, in parallel with a "reliable" SRAM board, and, using a monitor or some other means, toggle in a program which just does a jump to itself, followed by a single write cycle. A little imagination will yield an appropriately short loop. This should generate activity on the DRAM control lines which will enable you to observe their interaction under control of the processor. Make note of the duration of each of the control signals. Don't worry , for now about the fact that there's no refresh if there isn't any, and verify that the strobes overlap as they should and last as long as they should for the memories on the board. If there's a refresh circuit, you should be able to observe its operation while your loop isn't running. The remarks made earlier about 8080's and DRAMs are probably quite correct. Lots of DRAM boards rely on the processor to refresh the memories. Not all processors do this. In fact, not even all Z-80 processor cards do this correctly. Hence, DRAMs before '83-84 were somewhat iffy on the S-100. By then, of course, the S-100 was, more or less, history. One of the things you'll be able to do, as a consequence of this effort, is determine whether making your IMSAI work with THIS particular DRAM board is a lost cause. It may be, but DRAMs are not as difficult or fussy as a lot of people have said. I've designed literally dozens of different DRAM circuits which in almost all cases had to "look" as though they were static because no special provision for nRAS precharge or refresh could be made. If you want to use DRAMs, there's a way to make it happen. This particular board may not be the easiest way, however. You need refresh, for sure, and if this board doesn't generate it, there's a pretty easy way, by scabbing on one 16-pin DIP packaged tristate 8-bit counter or, worst-case, a PAL and maybe by swapping tri-state multiplexors for the totem pole types in the circuit (if that is what they used) that non-local accesses to either I/O or PROM can be sensed from the bus interface so you can do cycle-stealing refresh which will be completely hidden. Otherwise, you have to build a refresh timer in addition to some of this other stuff. In that case, I'd recommend another solution. DMA was popular for early FDC's in the mid '70's because 8080 processors were too slow to get around the loop fast enough to transfer data from successive sectors of the diskette. Some were too slow to transfer the data in real time at all. The DMAC was able to keep up with either. Many such DMAC's assumed some things about the system properties which were not warranted. The may have assumed the system clock to be slower than it was, or they may have assumed that there was no need for inter-cycle idle time. SRAMS didn't need such luxuries, but DRAMs generally didn't tolerate being accessed at a greater than 50% duty cycle. If you find that the DMAC is forcing data into memory in bursts which stroke the RAM with little time between access cycles, particularly if it causes the time high on nRAS to be substantially less than the time low, the circuit may not work. There is a FIX, however, which involves swapping low and high address nybbles. This will cause successive byte reads or writes to occur in separate banks of DRAM, which will, then, hopefully and depending on how the circuit is designed, make the short cycle problem go away. . . not completely of course, but sort-of. Let me know how this goes. I'm really quite happy to help with this sort of debugging. Dick -----Original Message----- From: Dwight Elvey <elvey(a)hal.com> To: Discussion re-collecting of classic computers <classiccmp(a)u.washington.edu> Date: Tuesday, June 01, 1999 6:02 PM Subject: Re[4]: More Bringing up a CPM