[Coco] POKE 65495,0

[Mike Pepe]

Phill Harvey-Smith wrote:
> Darren A. wrote:
>>> From: Phill Harvey-Smith <afra at aurigae.demon.co.uk>
> 
> [snip description of SAM speed pokes]
> 
>> -
>> Phil, 
> 
> Phill :)
>> here is another excerpt from the SAM datasheet. Maybe this will help 
>> clarify things:
>  >
>> The MPU and VDG must both be able to access RAM without contention. This 
>> difficulty is overcome by taking advantage of the timing and architecture of 
>> Motorola MPUs (6800, 6801E, 6809E and 68000).
>>
>> Specifically, all MPU accesses of external memory always occur in the latter 
>> half of the machine cycle. Similarly, the MC6847 (non-interlaced) VDG 
>> transfers a data byte in a half machine cycle. Thus, when properly 
>> positioned, VDG and MPU RAM accesses interleave without contention.
>>
>> This interleaved Direct Memory Access (IDMA) is synchronized via the MC6883 
>> by centering the VDG data window half-way between MPU data windows. The 
>> result is a shared RAM system without MPU/VDG RAM access contention with 
>> both MPU and VDG running uninterrupted at normal operating speed, each 
>> transparent to the other.
> 
> The point I was trying to make is, that when the speed is set to 
> 0.89MHz, then yes the above will be true, but when the speed is set to 
> 1.7MHz, then the Q and E signals will be half their length, when 
> accessing ROM.
> 
> However, if the above remained true then the data would also be being 
> fed to the VDG twice as fast, which clearly would not work, so the SAM 
> either needs to feed the VDG once every 2 cycles, or in reality the fast 
> mode is only used when the VDG is not accessing the RAM, so when /HS or 
> /FS are low.
> 
> Cheers.
> 
> Phill.
> 
> 

Hi Phill,

The VDG clock and the E & Q clocks are separated. The reason why the 
A.D. mode can actually work is related to that.

Since reading from ROM doesn't contend with the SAM feeding data to the 
VDG, the E&Q clocks can be sped up while the SAM will still feed and 
latch the VDG data at the normal rate.

The true double-speed mode takes the VDG time and uses it for CPU. 
That's why the display goes away. It also apparently takes away refresh 
time (since refresh is done during VDG quiet time). However as I'm sure 
someone already pointed out, reading data from DRAM will refresh that 
entire column, so if something is running and either has properly 
defined loops or relatively random access, the running code will keep 
the RAM refreshed on its own.

-Mike