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

From: André Fachat (
Date: 2007-05-28 16:13:47

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 

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

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" <>
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

Archive generated by hypermail pre-2.1.8.