Dio wrote:In the details it gets pretty complex. The rough rules are:
- The MMU phase contains either a DRAM refresh or a Shifter video access. There is no way to disable the refresh and force it to hand the phase to the CPU instead.
EvilFranky wrote:How does the Amiga blitter work in comparison to this?
Sent from my GT-I9100 using Tapatalk
mc6809e wrote:My understanding is that the Amiga blitter/CPU can use any extra cycles (including odd cycles) but in some cases doesn't
mc6809e wrote:That's too bad. Even with refresh enabled there should be something like 50 odd bus cycles available after HBlank. If the blitter had the even cycles and the CPU the odd cycles remaining during HBlank then the HOG bit could be left on and the CPU would still get something. And then there are the 60+ lines where Shifter is off completely...
Dio wrote:The ST is very aggressive with its DRAM timing. It clearly breaks at least timing parameter, the back-to-back cycle time for most of the memory types used is a bit over the actual slightly-under-250ns cycle time - for example, for the Fujitsu RAM common in early STs the cycle time minimum is quoted as 265ns. A few of the other parameters and signals are driven awfully close and exploited to the max as well. dadhacker quoted one of the ST designers as saying "You see, DRAMs are analogue devices really..."
During the visible screen, no refreshes are actually needed at all, but when V is inactive you need to average about five refreshes a line to stay in spec. The ST does the simplest thing and just refreshes on every MMU phase if it's not a video access. Probably costs a bit in power consumption, but doesn't change the peak, just the average, so doesn't add any cost.
Users browsing this forum: No registered users and 5 guests