Re: RE: RE: How to design non-trivial cartridges for c-64?

From: André Fachat (
Date: 2007-05-28 18:17:27

Hi Bil,

in my computer I already use dRAMs in the (working) video board. I produce
the /RAS from Phi2 by delaying Phi2 and XORing both. So I have
two possible dRAM cylces, one during Phi1 and one during Phi2.
Which works fine for 1Mhz and 2MHz BTW.
This line is fed to the dRAMs as /RAS, then delayed, fed to the 
address mux (MUX), delayed again and then switched on/off depending
on whether the dRAM is selected or not and fed to /CAS. 

How did you produce the delay between /RAS, MUX and /CAS. I use the
pretty crude method of using a 7414, i.e. a slow inverter, passing
the signal through it a number of times.
[The Phi2 delay for the /RAS used to be done this way to but is now
done by shifting Phi2 through a shift register with 8 times Phi2 clock
and then using an appropriate output to XOR with Phi2]

During Phi1 I have either
the video address read (from a CRTC - did I mention my computer
is not a C64, but a self-built and expanded PET replica?) on the
video board or a refresh counter on the RAMDisk. /WE is 
setup before /RAS goes low. And I don't use any fancy access mode.
I try to keep it as simple as possible.
I ran into the precharge specs with the video card. Timing and
architecture I think I can cope with.

But I grew up in a digital world ;-)
so I do have problems with the noises and glitches.... :-(
(I probably shouldn't say that too loud, as I am physicist by
education, so I know the theory, but as you know "in theory
there is no difference between theory and practice".... ;-)

It seems I have to also look into the termination stuff again.


-------- Original-Nachricht --------
Datum: Mon, 28 May 2007 11:43:00 -0400
Von: "Bil Herd" <>
Betreff: RE: RE: How to design non-trivial cartridges for c-64?

> Hi Andre,
> There are three aspects to making DRAMs work; absolutely getting all of
> the timings correct, the environmental aspects of noises, glitches and
> terminations, the architectural issues such as access mode and DRAM organization,
> refresh, etc.
> For DRAM timings you absolutely need a stable source of control signals;
> you need to be able to generate /RAS, /CAD, /WE and the direction controls. 
> You need to be able to multiplex the addresses to coincide with those
> major controls, and then you need to cleanly get the signals propagated into
> and out of the arrays.
> Lastly, the logical function of DRAM's may not be the same.  The old CBM
> where the simplest use of drams, we didn't use nibble or page mode accesses,
> we didn't rely on self refresh devices.  With that said I don't know what
> the underlying architecture is of the SIMMS you mentioned.
> I don't know what you are doing for DRAM timing signals, are you tapping
> the VIC chip's signals?
> Brief tutorial on olde DRAM use, based on 25 year old memory:
> /RAS and /CAS need to go high per the precharge specs
> Address set up prior to /RAS per Row Address Setup Spec (I have seen this
> spec blown a lot)
> /RAS goes low and addresses are held for Row Address Hold (RAH) time.
> Only after RAH can you flip the control signal for the address buss mux,
> we used to create a signal between /RAS and /CAS called MUX for this
> purpose.
> Addresses, Data and /WE set up before /CAS.  You can delay some of this
> for a late write but you need to know what your doing so best is you declare
> a write cycle prior to /CAS falling.
> For reads, data comes out one access time after TCAS (Time CAS Access),
> there is also a half dozen other specs that determine when data is valid,
> such as the shortest time from RAS, etc.
> For a write cycle you have to hold write data per the specs, which are
> related to CAS not PHI.  As CAS is generally held later than PHI for writes
> you may end up latching the data.
> Every now and then you need to generate refresh addresses for the dynamic
> part of DRAM.
> CAREFULL layout and series termination of signals is a must.  The one
> jumper on the C128 production was due to a single reflecting node on one
> address line when the Z80 was the active CPU.  The jumper is in parallel to a
> trace on the board that is otherwise perfectly fine except there is a glitch
> that "stands" on the line at a certain point in time under certain
> circumstances.  My boss didn't believe me and ran 10,000 units over the weekend to
> prove that this really did fix the "CPM Loading problem", it was more
> sensitive on one brand of multiplexers than the other.  Also had a problem early
> on when multiplexing from all ones to all zeros's except for one bit, the
> last bit would get drug to zero also.
> As you can see DRAMS are dynamic creatures.  Makes static RAMS look like a
> pretty simple alternative.
> I used to say that engineers should have to get certified to do certain
> parts of a design and that there should definitely be a DRAM badge/stamp
> before tackling DRAMS for production release.... tricky critters on the
> outside, very stable once you get your hands around it.  Think of an array of
> capacitors with leakage and you have a DRAM array.  BTW, I have never been to
> school for any of this (electronics or college, etc), it is careful study of
> the specs and then some lumps along the way.  We didn't have simulators
> back then, we started with timing analysis on graph paper and then later used
> visicalc type programs, there are about 16 specs you need to account for
> if memory serves.
> Regards,
> Bil Herd
> -----Original Message-----
> From: []
> On Behalf Of "André Fachat"
> Sent: Monday, May 28, 2007 10:14 AM
> To:
> Subject: Re: RE: How to design non-trivial cartridges for c-64?
> Hi Bil,
> many thanks for the engineering lesson :-)
> While I am able to make a coprocessor, or a second processor
> that takes over the bus on some condition work almost on the first
> try, I tend to miserably fail with dRAM due to timing problems.
> So maybe I am one of those you mentioned, who get everything
> right but... - but then again, I do it for a hobby :-)
> Currently I am working on a RAMdisk, re-cycling old 30-pin SIMM
> memory modules, and I am desperate because I cannot make it work.
> Probably because the dRAM has much stricter timing requirements.
> Compared to this, 65xx and 74LSxxx parts seem to be much more 
> forgiving.
> Also the SIMM modules draw a lot of power, and I had to add an
> extra power supply connector to the board to keep the voltage monitor
> (7705) from asserting RESET on a low voltage condition.
> Maybe this power hungryness also puts strains on signal lines...
> I will try the Phi0-approch you mentioned, though.
> Thanks again
> André
> P.S.: my system is here:
> (the ramdisk is not yet there, though)
> -------- Original-Nachricht --------
> Datum: Mon, 28 May 2007 09:33:03 -0400
> Von: "Bil Herd" <>
> An:
> Betreff: RE: How to design non-trivial cartridges for c-64?
> > Hi Andre
> > 
> > Bear in mind that I was from the production world where I had to pay
> > strict attention to specs or get thousands of failures, not to mention
> the range
> > of temperatures, voltages and related part specs that we had to account
> > for. (as it was parts didn't always pay attention to specs and we would
> get
> > thousands of failures).  You can often get designs to work just fine in
> low
> > quantities at room temperature under a stable voltage... I.E. some
> things I
> > couldn't do will work just fine for experimenters.
> > 
> > Using a buffer to hold data valid longer was not a useful approach back
> > then as there generally were no valid minimum times on a chip, I.E. your
> best
> > off to assume that the output goes invalid almost immediately after the
> > input goes invalid.  I think in terms of data valid propagation and
> invalid
> > propagation, hoping a buffer reliably holds the exact same input after
> > currents start dumping and nodes start discharging is a bad bet when
> multiplied
> > times 100,000.  Signetics buffers used to Hi-Z with a vengeance as an
> > example.
> > 
> > A variation on this is where someone will but a buffer between the clock
> > and data lines of a latch hoping to create hold time, problem is that
> > variations in layout, pin capacitance, etc can result in -1 ns hold time
> worse
> > case. (not only no delay but negative delay)
> > 
> > You also slow things time by the TProp of the buffer so at best you pick
> > up a hold of something like 3ns but slow things down by an additional
> 20ns.
> > 
> > This was a recurring stickyness to 6502 designs, I used PHI0 (clock
> source
> > instead of clock output)  a lot and thought about using long traces on
> > data lines (joke) among other things... more than one engineer got
> everything
> > else right except for this part.
> > 
> > Bil Herd 
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: []
> > On Behalf Of "André Fachat"
> > Sent: Monday, May 28, 2007 8:27 AM
> > To:
> > Subject: Re: How to design non-trivial cartridges for c-64?
> > 
> > 
> > > Bil Herd wrote:
> > > > The area you have to watch is that the data is valid for only a
> short
> > > > period after Phi goes low, known as the hold time.  Holdtimes are as
> > > > short as 10-20 ns (shorter if using Phi2) which means that if you
> have
> > > > too much logic in line to create the strobe, the data goes away
> before
> > > > the strobe (took you longer than 10ns to decide to do something). 
> > Rule
> > > > of thumb is the strobe has time for only one level of TTL type logic
> > on
> > > > anything trying to capture data.  
> > > >   
> > > So, for something a bit more time intensive, are there any
> suggestions? 
> > > Delay after Phi2 going Hi to start the work?
> > 
> > You can delay the data by feeding it through a buffer (e.g. 74ls245)
> > first.
> > 
> > André
> -- 
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
> Ideal für Modem und ISDN:
>        Message was sent through the cbm-hackers mailing list
>        Message was sent through the cbm-hackers mailing list

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen:

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.