[Coco] POKE 65495,0
Phill Harvey-Smith
afra at aurigae.demon.co.uk
Wed Jan 31 13:38:23 EST 2007
Mike Pepe wrote:
>
[snip!]
Hi Mike, and others :)
> 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.
Of course (slaps forehead!), I always tend to forget that in some ways
we have separate buses, the RAM bus controlled by the SAM and then the
rest of the system controlled by the CPU.
Now with a gate between the SAM data bus and the CPU bus, and some logic
to force the SAM into thinking it was accessing a $8000-$FFFF address,
we could have a machine that always ran at 1.8Mhz :) :)
> 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.
Yeah I guess you would just need a counter, that counted 0..255, and
then just did a peek (256*counter), which would cause a refresh to
happen, that would be pretty easy to implement I guess, especially if
you where coding in asm, as you could do it as an irq handler or
something like that.
Cheers.
Phill.
--
Phill Harvey-Smith, Programmer, Hardware hacker, and general eccentric !
"You can twist perceptions, but reality won't budge" -- Rush.
More information about the Coco
mailing list