From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2005-10-12 21:34:41
On Wed, Oct 12, 2005 at 07:53:43PM +0200, Daniel Kahlin wrote:
> On Wed, 12 Oct 2005, Spiro Trikaliotis wrote:
>
> >I always thought the VIC refreshed the DRAM simply by accessing it. If
> >you "swap" A0-A7 and A8-15 inside of the VIC, the VIC just accesses
> >every row while generating its screen ($0400-$07E7), as the last byte
> >cycles through all possible values. Thus, it could refresh all 64 KB RAM
> >just by displaying the screen.
> >
> >Is this wrong? Does the VIC really generate some refresh cycles?
>
> This is correct. This is why messing with $d011, like FLD, FLI and
> line-crunch may in some cases corrupt memory.
Are you absolutely positive that the memory corruption is because of
lacking memory refresh? I always thought it is because of a bus glitch,
i.e., the VIC-II would start DMA immediately upon receiving the write
to $d011, while the 6510 is still holding the R/-W line low.
According to my measurements, the built-in memory refresh in the
VIC-II, VIC-IIe and TED simply access some memory locations. On
the VIC-II and VIC-IIe, the locations are $3fff to $3f00 in the
currently selected 16k video bank, five addresses per line, in
descending order. The VIC-IIe and the TED will switch to
"1 MHz mode" during the memory refresh cycles.
> This is especially true with line-crunch. How sensitive a machine
> is to this is dependent on which revision of the c64, and probably
> what type of DRAM chips there are installed.
I agree. Some machines do not seem sensible at all.
Another thing that varies from computer to computer is the
"stability" of unconnected address space ($de00..$dfff in the I/O area
or the 4 most significant bits of $d800..$dbff). On some systems, the
unconnected bits reflect the data fetched by the video chip; on others,
some of the bits are stuck to 0 or 1 for most of the time.
You can even run a program entirely in the I/O space. Well, you'd better
fill the stack with a constant, so that you can use easy single-byte
instructions such as RTS or RTI. Some 10 years ago, I wrote a program
that runs in the color memory. It took me 2 weeks to design that
program. The stack would be filled with $da, and most of the color
memory was filled with $x0, so that the program could execute RTS
(jump to $dadb) or relative branch instructions most of the time. It
was much easier to write a program that runs in the unconnected I/O
space, because there the 9 least significant bits of the program counter
can be ignored.
I even tried to write such a program that would run in the 2 MHz mode
on the 128. Obviously, it didn't work, because the memory would not
be accessed for long periods, and you could see on the screen that
the data bus contents would get corrupted.
> Also, the 256Kbit chips (41256) does not require you to cycle more than
> the lowest 8-bits. You can put 41256 chips into a regular c64, and put a
> very simple circuit for manual bank select on A8 if you like.
The internal 256k memory expansion designed by Pekka Pessi in 1986 does
exactly that. I translated the document into English in 1993.
Marko
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.