Re: cbm 8032 motherboard + 4164

From: Gerrit Heitsch <>
Date: Fri, 14 Oct 2016 12:35:02 +0200
Message-ID: <>
On 10/14/2016 12:00 PM, smf wrote:
> On 14/10/2016 08:27, Gerrit Heitsch wrote:
>> You cannnot run the refresh cycles only in the upper and lower border,
>> the screen part takes more than 4ms to display which will take you out
>> of spec for the DRAM.
> The badline fetches should be reading the DRAM enough to refresh it (as
> long as the screen is enabled). When it's disabled then vic2 reverts to
> the upper/lower border case.

The refresh cycles produced by VIC are an insurance policy. They make 
sure that no matter what, the DRAM gets refreshed. Disable all sprites, 
disable the display and run the CPU in a minimal endless loop waiting 
for an IRQ.  (2000  JMP $2000) and you still won't lose data.

> So I wonder why they didn't make the upper/lower border+blank screen
> fetch $3fxx, instead of $3fff & skip the extra refresh cycles. The apple
> 2 gets away with it (they have a border too and I assume they fetch
> during the border).

Would probably have made the logic more complicated. They had enough 
problems to get everything into VIC as it is. And don't forget, the DRAM 
controller came later, the 6566 was SRAM, so it had to fit into whatever 
space they could find. That also explains the weird multiplex address 

As for the Apple 2, one would have to examine its logic to find out how 
it works in detail.

> It would have caused them a problem on the C128, because in 2mhz mode
> the vic2 can't do any fetches. I assume it still pauses the cpu to do
> refresh cycles each line though. But they didn't design vic2 for the
> c128. Of course they didn't design vic2 for the c64 either

TED does that. When drawing the border (or display off), the CPU runs in 
double speed. Except for the 5 refresh cycles per scan line, there the 
CPU runs in single speed.


       Message was sent through the cbm-hackers mailing list
Received on 2016-10-14 11:01:57

Archive generated by hypermail 2.2.0.