From: André Fachat (afachat_at_gmx.de)
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.
Regards,
André
-------- Original-Nachricht --------
Datum: Mon, 28 May 2007 11:43:00 -0400
Von: "Bil Herd" <bherd@ids-business.com>
An: cbm-hackers@ling.gu.se
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: owner-cbm-hackers@ling.gu.se [mailto:owner-cbm-hackers@ling.gu.se]
> On Behalf Of "André Fachat"
> Sent: Monday, May 28, 2007 10:14 AM
> To: cbm-hackers@ling.gu.se
> 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: http://www.6502.org/users/andre/csa/index.html
> (the ramdisk is not yet there, though)
>
> -------- Original-Nachricht --------
> Datum: Mon, 28 May 2007 09:33:03 -0400
> Von: "Bil Herd" <bherd@ids-business.com>
> An: cbm-hackers@ling.gu.se
> 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: owner-cbm-hackers@ling.gu.se [mailto:owner-cbm-hackers@ling.gu.se]
> > On Behalf Of "André Fachat"
> > Sent: Monday, May 28, 2007 8:27 AM
> > To: cbm-hackers@ling.gu.se
> > 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: http://www.gmx.net/de/go/smartsurfer
>
> 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: http://www.gmx.net/de/go/multimessenger
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.