Re: Accessing the C64 memory between 65xx chips operations.

From: André Fachat <afachat_at_gmx.de>
Date: Sun, 19 Apr 2020 20:53:57 +0200
Message-ID: <17193ca3d88.27ff.b4d1f2b66006003a6acd9b1a7b71c3b1_at_gmx.de>
Am 19. April 2020 20:41:28 schrieb Gerrit Heitsch <gerrit_at_laosinh.s.bawue.de>:

> On 4/19/20 8:22 PM, tokafondo wrote:
>> So, this is like,
>
>
>> "the memory access will last NNN ns, and even if the memory answers back in
>> NN ns or even N ns, the VIC will wait for NNN ns to continue its tasks,
>> because it doesn't check if the data has been returned but instead, it just
>> expects it to be there".
>
> That's correct. There is no signal the DRAM can use to tell the outside
> that the data is now valid. VIC expects the data to be valid at a
> certain point in the cycle. This cycle is designed to allow DRAM with a
> 200ns RAS access time and have a few ns to spare. If you use a DRAM with
> 100 ns, the data will just sit an extra 100ns on the bus before VIC
> samples it.

You could slice in a hidden cycle "before" the VIC expects the data. That
would require the VIC address lines to be replaced for the say first half
of the VIC's half clock cycle. In the second half the VIC access would be
done, which works if the RAM is fast enough.

So say you have a 4MHz capable SRAM, every second cycle could be used for
the second CPU, and the other cycles would be used by the CPU and VIC.

The C64 1MHz clock is divided into the first 500ns for the VIC and the
second 500ns for the CPU. The same principle could be done with the first
250ns of each 500ns intervall for the external CPU and the second half for
VIC/CPU.

However, as already mentioned that requires redesign of the Address circuitry.

André

>
Received on 2020-05-30 01:30:01

Archive generated by hypermail 2.3.0.