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

From: Bil Herd (
Date: 2007-05-28 18:49:45

Hi Andre

Sounds like you have the basics covered.  Problem with deriving mux through several inversions is that if the chip is fast, say 1ns, you have only 4ns, if it is slow, say 4 ns, you have 16; huge change as parts in a chip tend to track each other. 

The shift register approach is a very usable approach, saved my ass a few times (see the 8563 story).  I could even move a wire from tap to tap like adjusting the dwell in a car.  Problem is we used one half cycle of the 8mhs clock I think, and again frequencies are controlled but not duty cycles.

I used to say it's all analog, we just call certain voltages after certain time periods a one or a zero but it was very analog to get there.  The insides of the old NMOS chips even more so, they would pick device sizes based on analog parameters to drive digital circuitry.

An important part of any DRAM development is a GOOD DRAM test, the last thing you want to do is catch a dram problem by backtracking a crash.  The one problem I told you about where the one bit would get drug along with the rest (ground pin lift) was not caught in a DRAM test, it would just crash.  I noticed that it often put an "@" sign into a spot in the video memory early in the crash so I hooked a light pen to the scope and analyzer and held it up to the spot on the monitor where the @ sign would sometimes appear and triggered the equipment within one screen time of the write.  I got lucky and found the cause within 10 minutes.

So does your circuit work sometimes, most of the time, or not at all?  Do you have circuit timings and schematic I could glance at?  For a good description including the math of what I learned an intuitive feel for you might want to check out  I have bought three of these books and give them away every couple of years to old friends, young engineers, etc.  

So is the thing your talking about a video board or a C64 expander?  I am kind of confused.


Bil Herd

-----Original Message-----
From: [] On Behalf Of "André Fachat"
Sent: Monday, May 28, 2007 12:17 PM
Subject: Re: RE: RE: How to design non-trivial cartridges for c-64?

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

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.