[Coco] Cocovga 64 column not 80?
Brendan Donahe
brendan at polylith.com
Wed May 1 22:50:25 EDT 2019
Inline, below...
On Wed, May 1, 2019 at 9:34 PM Joel Rees <joel.rees at gmail.com> wrote:
> Okay, I'm beginning to get the picture ...
>
>
> 2019年5月2日(木) 10:06 Brendan Donahe <brendan at polylith.com>:
>
> > Joel,
> >
> > There were a number of reasons for this CoCoVGA FPGA design decision:
> >
> > 1.) I could conserve space in the FPGA by reusing the character ROMs
> Steve
> > Spiller and I re-implemented in the design, as opposed to creating
> another
> > new character set.
> > 2.) By default in text mode or RG6/PMODE4, each CoCo video pixel
> consumes a
> > 2x2 pixel of the VGA 640x480. This means that resolution could be
> doubled
> > in each direction without exceeding the current VGA video format or doing
> > away with the border around the green field.
> >
>
> So does 640 wide include the border area, which means 512 pixels of useable
> width?
>
Bingo! Yes, the apparent "resolution" (with the character tile limitations
of course) of a custom character set on a 64 column text screen is 512x384.
Or is there a mode which enables 640 useable pixel width?
>
Not today. Perhaps in the future, although there are other features which
I'd like to get in first. One issue here is the limitation of the VDG to
DMA (with the SAMs help) its own video memory, which maxes out at 6144
bytes per frame in the highest resolution graphics modes (CG6/RG6 a.k.a.
PMODEs 3/4). It would be necessary to stitch multiple frames together
(effectively reducing CoCoVGA's refresh) to go beyond this boundary.
3.) Doubling the 32x16 = 512 byte text and semigraphics display
> > horizontally and vertically still enables nice power-of-2 (64x32 = 2048)
> > counters and sampling into the FPGA's video buffers.
> >
>
> Nice numbers indeed, should work well when editing a traditional Forth
> fixed-width "screen".
>
Neat idea. Let me know if/how I could help with this.
4.) Sticking to a 8x12 character enables the software-uploadable custom
> > character sets to be used in both 32-column and 64-column modes.
> >
> > I agree it was a bit of a compromise. I would have preferred 80 columns,
> > but not at the expense to the design size and complexity.
> >
>
> [thumbs-up /]
>
> Note that all of this logic has been re-implemented from the 6847. In
> > other words, the VDG and CoCoVGA FPGA each have their own character
> > generator.
> >
>
> Mimicking the internal to keep it simple. Gotcha.
>
More information about the Coco
mailing list