[Coco] too wordy?

[Ciaran Anscomb]

Mark McDougall wrote:
> On 10/10/2013 12:27 AM, Ciaran Anscomb wrote:
> 
> > Unless you had a handle on exactly what it was doing, you're likely to hit
> > the same issue reimplementing it in FPGA!
> 
> Hmm... I have a Coco 1/2 FPGA implementation... what exactly is the issue?
> And do you have sample code to test against?

Hmm this is actually on topic.  As in, it's "too wordy".  But here goes :)

It's to do with the video address counter.  XRoar (and I assume now MESS)
handles the X and Y divisors correctly in normal operation (so you get
your 42 byte and 48 byte modes, etc., just fine), but switching SAM video
mode mid-scanline causes occasional jumps in the address on real machines.

The obvious assumption is that the various dividers are all clocked
from the same source - B3 for the X dividers (/1, /2 or /3), B4 for the
Y dividers (/1, /2, /3 or /12) - and that switching mode selects the
appropriate output, which may cause a transition causing a ripple.

I have a small test app here:

http://www.6809.org.uk/tmp/da/paranoid/

(Hacked down from what I initially started as a demo effect, assuming
the dividers would clear, and I'd get "fer free" vertical scaling just by
being clever with timing - nothing ever quite works out that way, eh...)

It lets you adjust the delay before it switches between two SAM modes by
one scanline at a time using up/down (semicolon and comma on the coco I
guess).  With a logic analyser on the SAM RAM lines and triggering off RAS
& CAS you can then observe the video address jump when it changes mode.

Been a little while, but according the comments it's deliberately not
modifying the X divider, only Y, between /1, through /3 to /12, then
back a few lines later.

So far I've recorded the address after various amounts of delay,
and written a Perl script to brute force scan through every possible
combination of duty cycles for the various dividers and see if I can
get all the simulated addresses to match.  No joy!

Must get my Dragon back out and hook everything up again.  Hopefully I'm
just missing something obvious, not coming at it from completely the
wrong angle.

..ciaran