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 pinout. 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. Gerrit Message was sent through the cbm-hackers mailing listReceived on 2016-10-14 11:01:57
Archive generated by hypermail 2.2.0.