More Bringing up a CPM

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Jun 1 19:50:01 1999

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_at_hal.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Tuesday, June 01, 1999 6:02 PM
Subject: Re[4]: More Bringing up a CPM


>"Richard Erlacher" <edick_at_idcomm.com> wrote:
>--snip--
>> Have you examined the nRAS nWE and nCAS signals to the DRAM
>> with your 'scope?
>
> Thanks Richard, this sounds like a good place to look.
>
>> Where does this DMA live? Is this an i8257 on the
>> controller?
>
> The DMA controller is all TTL, with no special controller
>chip. Like I said, it is an early unit made about '77 or
>so. The entire sequence is completely controlled by 2
>bipolar PROMs that are part of the controllers sequencer
>and a few flip-flops to deal with the DMA acknowledge sequence.
>It has been fun figuring this out to understand how to
>setup data for formatting ( different than read/write ).
>I'll have to look more at what and when the various
>signals are generated on the bus relative to the DRAM's
>signals.
> I'm just not sure which direction to go from here. Should
>I debug the DRAMs or look for the problem in my static
>RAMs. Since I need a full boat of 64K and I have no more
>static boards to put into it, I'll need to deal with what
>I have.
> I still have other issues to fix, like bad
>select signals going to the drive ( I can only hook up
>one right now ) and flaky RAMs. I have so far replaced
>4 IC's and one capacitor to get this far.
>Dwight
>
Received on Tue Jun 01 1999 - 19:50:01 BST