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: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Jim Brain Sent: Sunday, May 27, 2007 10:08 PM To: firstname.lastname@example.org 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.