More Bringing up a CPM

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Jun 1 17:39:37 1999

Is there a monitor that can be run to do things like run a software loop to
write to, and subsequently, read from a block of SRAM? Does that work? If
you're having doubts about the memory, it might be a good idea to leave the
DMA out of things for a while, at least until your confidence in your
memories, of whichever type you decide to use, gets to where you have some.

I have seen no evidence of any confidence testing in your RAMs, whatever
they are, and until you have at least 4K in which you have confidence, you
really can't do much, can you?

If you do have confidence in the processor being able to read/write the
DRAMs, then why not look at the access waveform timing on pins 3,4,and 15.
IIRC, those are nRAS, nWE, and nCAS, and they're the ones which have to work
correctly. If the processor works these devices correctly and the DMA
controller doesn't, the relative timing of these strobes will be the reason.
The DMAC itself may not, in fact, be causing your timing problem, in the
event that's the finding, but the bus interface logic may be incompatible.
I've seen some memory cards which decode sMEMWR and pDBOUT but don't use
pWR, which occurs once the data is valid. If that's not the case, you may
have to get out your XACTO knife, to make sure the memory isn't WRITTEN with
data that's not valid. It's also possible, as old as those boards are, that
they may have been designed in a way which causes incorrect bus acquisition
by the DMAC. The DMAC may, therefore, be fighting with some other player on
the bus. DRAM boards on a multi-card system are always difficult to debug
if there isn't a program running in them because there's no really frequent
cycle to use as a trigger for your 'scope. If your system can allow you to
load and run a little monitor program in the DRAM board, you'll have plenty
of cycles you can trigger on.

Dick



-----Original Message-----
From: CLASSICCMP_at_trailing-edge.com <CLASSICCMP_at_trailing-edge.com>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Tuesday, June 01, 1999 2:44 PM
Subject: RE: Re[2]: More Bringing up a CPM


>> I have some DRAM boards that I've used with my Poly88.
>>These are 64K boards and I thought I'd use them but the disk's
>>DMA doesn't seem to write to them. I'm able to read and write
>>from the front toggles, just not from the DMA to the RAM.
>>
>> Does anyone know what the problem is here? Is there some
>>timing or pin out issue with DRAMs that would cause this
>>to happen in a standard IMSAI 8080? I'd really like to use
>>this DRAM because I trust it more than the statics in the
>>system, at least until I get things fully functional.
>
>Welcome to the world of S-100, where DRAM boards often didn't
>support DMA controllers properly. In some cases, you can rejumper
>them so that the DMA vs refresh timing conflict isn't such a problem.
>But many of us just went to pure static RAM systems where DMA
>was being done.
>
>What disk controller are you using, BTW? In some cases the problem
>isn't so much the memory, but it's the disk controller.
>
>> In any case, I think just getting to the A> prompt is
>>a major mile stone. I had to completely write a boot loader,
>>CBIOS, disk formatter and serial data transfer to get this far.
>
>It certainly is a major milestone. Congratulations!
>
>--
> Tim Shoppa Email: shoppa_at_trailing-edge.com
> Trailing Edge Technology WWW: http://www.trailing-edge.com/
> 7328 Bradley Blvd Voice: 301-767-5917
> Bethesda, MD, USA 20817 Fax: 301-767-5927
>
Received on Tue Jun 01 1999 - 17:39:37 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:15 BST