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

From: Bil Herd (bherd_at_ids-business.com)
Date: 2007-05-28 06:12:21

Hi Jim

For reads the addresses will stabilize just as fast as they can come out
of Hi-Z, for asynchronous devices like ROM's, their DataOut will become
valid at one access time period (TAC) after the last change. In short,
you just "let 'er rip" and use faster parts if you need data faster/

If you need something synchronous you are actually dealing with the big
C64 dilemma which is how many clock edges can we use to create valid
strobes.  The DRAM timing on the main board suffered from worse case
scenarios where signals could come too early as well as too late.  The
culprit was they were using the rising and falling edges of the 14.318
mhz dot clock but the duty cycle really had no control.  We just didn't
have easy access to 28mhz sources to remove the duty cycle problem.
This lead to Production putting capacitors on RAS and CAS DRAM signals
which causes ither problems (slow rise/fall times, blow the precharge
time, etc) 

You could use a delay line to generate a "x-ns after Phi" signal (WAY
too expensive back then... $6) but for reads its not usually a problem.

For write's you want to latch the data as close to falling PHI2 as
possible, PHI0 is better when available.  The trick is to create valid
GatedRW lines (/WE)if needed.  These days fast circuits can make do with
minimal setup and hold times so it can all happen on the end of the
cycle (vs DRAMS which took something like 55ns to create a valid write
portion of the cycle) 

If you have an actual example I can maybe comment.

Bil Herd






-----Original Message-----
From: owner-cbm-hackers@ling.gu.se [mailto:owner-cbm-hackers@ling.gu.se]
On Behalf Of Jim Brain
Sent: Sunday, May 27, 2007 10:08 PM
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?

       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.