[Coco] MC6847 VGA (FPGA) Project underway...

[Brendan Donahe]

Ciaran,

Very interesting information.  I'll have to add "Flee!" to the test suite
for when we get to the Dragon.

Dragonfire does work with CoCoVGA on the CoCo 2 today, so I must have the
data/CSS latching pretty close, at least.

Thanks,
Brendan



On Fri, May 27, 2016 at 1:38 AM, Ciaran Anscomb <cocomalt at 6809.org.uk>
wrote:

> Darren A wrote:
> > On Thu, May 26, 2016 at 7:41 AM, Brendan Donahe wrote:
> >
> > > I had the understanding that SG6 didn't work right on the CoCo, too,
> > > however, it looks to me like it can on some systems, and I don't want
> to
> > > exclude the Dragon or MC-10.
> >
> > The problem with SG6 is that all 256 byte values are used to produce
> > graphics characters in that mode. But because the CoCo, Dragon and MC-10
> > all have the A/S pin hard-wired to data line D7, you can only use values
> > 128-255, eliminating half of the available colors in each color set. Byte
> > values 0-127 will give you the External Character ROM mode. Since there
> is
> > no external character ROM you end up with vertically striped characters
> > corresponding to the byte's bit pattern.
>
> If you set the SAM divisor to give you 1 row lines you can get some
> pseudo-hires stuff onto the screen along with 4-colour semigraphics
> (except on the later CoCos, where a buffer was put in place so the
> data lines stopped being treated as the "external" character set).
>
> You end up able to manipulate 7 out of 8 "pixels": bit 6 always ends up
> the same colour because setting it asserts INV which then inverts the
> whole pattern :)
>
> There was a BASIC+M/C game published in Dragon User called "Flee!" that
> made use of this if you want to see it in action (XRoar supports this
> use): http://www.6809.org.uk/tmp/da/dragon_originals/
>
> Something else you might want to implement: RP occurs on the switch from
> graphics to alphanumeric, which (with some cleverness updating memory
> at the right time) can give a smooth scroll effect in (normal SG4)
> text mode as it resets the row index into the font.
>
> I guess you'll already have the data/CSS latch timing in mind, as lots
> of things use that (DragonFire being the obvious example).
>
> Probably less important is that while data/CSS is latched ahead of time
> and populates the bit pattern/palette stuff, switching G/¬A happens
> pretty immediately and due to system timing always partway through a
> byte, and that leads to some non-obvious effects as the different buffers
> are selected.  I think the only time I've seen this used in anger is in
> the PAL hack of DragonFire, and even then only used to change the border
> colour for the bouncing message.
>
> ..ciaran
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>