From: Baltissen, GJPAA (Ruud) (ruud.baltissen_at_abp.nl)
Date: 2005-10-13 08:45:57
Hallo Spiro,
> 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
Archive generated by hypermail pre-2.1.8.