From: Gideon Zweijtzer (gideonz_at_dds.nl)
Date: 2005-10-13 22:05:41
Hello Ruud, Do you want to have the VIC access the memory in the expansion that you're planning to make? If not, then things become fairly simple, because you know exactly when the VIC does an access and when the CPU does an access. This is defined by PHI2, right? Using the 8 MHz clock that enters the VIC chip, you can make a three-bit counter and synchronize it with PHI2. This allows you to generate eight sub-clocks in every PHI2 period. Even this 8 MHz clock is slow enough I think I do one refresh AND a CPU access cycle in this one microsecond. Using cas-before-ras, you don't have to worry about offering the right row address for the refresh cycle. PHI2 CNT Action 1 000 1 001 1 010 1 011 0 100 0 101 0 110 0 111 > > Does the VIC really generate some refresh cycles? > > Yes, it does. The problem is that I don't have any simple > means to see what is a refresch cycle and what isn't. Bigger > RAMs then the 4164 use 9 or more addressbits. And all these > bits must be covered for refresh (with the exception of the > 41256). If the VIC accesses the DRAM and it is NOT a refresh, > all these extra bits need to be zero. If it is a refresh, the > bitpattern towards the extra pins has to be activated and I > need a mechanism to detect a roll-over of the original 8 bits > so I can increase this bit pattern. > > Using CAS-before-RAS would simplify things but then I still > need to know what is a refresh cycle and what isn't. And then > I still ain't sure if the VIC generates enough refresh cycles > to refresh the complete DRAM in time. > > I myself have made up my mind and decided to use the original > 64 KB of DRAM plus external DRAM. And the first 64 KB of this > external DRAM simply aren't used at all in the first place. > > > -- > ___ > / __|__ > / / |_/ Groetjes, Ruud > \ \__|_\ > \___| URL: Ruud.C64.org > > > > > > > =====DISCLAIMER=============================================== > ================== > > De informatie in dit e-mailbericht is vertrouwelijk en > uitsluitend bestemd voor de geadresseerde. Wanneer u dit > bericht per abuis ontvangt, verzoeken wij u contact op te > nemen met de afzender per kerende e-mail. Verder verzoeken > wij u in dat geval dit e-mailbericht te vernietigen en de > inhoud ervan aan niemand openbaar te maken. Wij aanvaarden > geen aansprakelijkheid voor onjuiste, onvolledige dan wel > ontijdige overbrenging van de inhoud van een verzonden > e-mailbericht, noch voor daarbij overgebrachte virussen. > > The information contained in this e-mail is confidential and > may be privileged. It may be read, copied and used only by > the intended recipient. If you have received it in error, > please contact the sender immediately by return e-mail; > please delete in this case the e-mail and do not disclose its > contents to any person. We don't accept liability for any > errors, omissions, delays of receipt or viruses in the > contents of this message which arise as a result of e-mail > transmission. > > 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.