[Coco] GIME text modes and font data

[John Kent]

On 4/09/2012 1:13 AM, jdaggett at gate.net wrote:
> John
>
> The GIME chip has the character generator within. Like the 6847, the GIME chip uses IDMA
> to access video RAM. Therefore the memory access speed has to be half that of the ECLK.
> With a 2MHz ECLK, (500nS cycle time) the memory needs to be faster than 250nS. The
> GIME reads memory when the CPU is not during the first half of the Eclk cycle. Each 6809
> clock cycle starts with the falling edge of the Eclk. The GIME slaves the E and Q clks off of
> the video clock so that the output mux works cleaner for IDMA.
>
> I am not certain of the actual wiring inside the GIME. So most of my opinions are based on
> what I think the GIME is doing from data sheets and other inputs. The GIMe chip reads from
> videso ram at three different rates. The VDU section of the GIME chip has two modes,
> graphics and text. In text mode there needs to be two bytes read to determine the character
> displayed and its attributes if used. Otherwise it is one byte per character. In graphics mode
> there is 2pixels/byte, 4pixels/byte and 8 pixels/byte modes. Depending on the mode and
> screen width, I think the pixel clock is adjusted accordingly.
>
>
> james

Hi James,

Yes, I understand the CoCo accesses RAM on alternate clock phases.
During phase 2 or E high the CPU accesses RAM and during phase 1 or E 
low, the SAM lets the 6847 VDG access RAM.
As I say I, started designing an FPGA version of the 6847 VDG, and I 
went through the data sheet looking all the various graphics modes.
The CoCo E clock I think is in the order of 890 KHz or there about, 
rather than 2MHz so that is the rate of the video graphics and text 
ASCII code access.
I might have made a mistake about halving the CPU clock rate.

I think Gary has the native mode clock rate as an option in his 
CoCo3FPGA design so that he can run the FPGA version at normal speed.
I'd have to check the schematic, but I think the pixel clock is in the 
order of 14MHz or so, at least that is the minimum clock rate require 
for getting at least
80 characters across the screen with a 16KHz horizontal line rate. In 80 
character mode, with an 8 pixel wide character generator you would have 
to access
a text character 14MHz/ 8 = 1.75MHz which is roughly twice the CPU clock 
rate. you have to access the character ASCII code from memory
and use it to index the character generator ROM, which is, as you say, 
built into the 6847 VDG.
The VDG I think might have only supported 64 characters which only 
requires 6 bits. You might be able to do other things with the other 2 bits.
In Graphics modes you have various options to use the video bytes 
accessed from memory by the VDG/SAM and multiplex them into various
graphics blocks with some bits used to specify the colors of the 
graphics, and possibly text, if you can have colored text characters.

What I wasn't clear on, was that in 80 character mode, you have to 
access the characters at twice the CPU clock rate if the CPU was running 
at 890KHz.
In text mode, if you have a line character buffer, you only have to read 
the character ASCII code from memory every 12 scan lines.
Since the CPU is accessing memory on alternate cycles, it doesn't matter 
if the VDG, reads the same ASCII code for every scan line,
in fact it makes the hardware design easier, because you don't need a 
line/row buffer. If the CoCo3 runs the CPU at 1.75MHz in 80 character mode
then there is no problem. Otherwise you'd have to read 40 characters 
into a row buffer during the first scan line, then read the second 40 
characters
on the next scan line, then you would have to read back the scan line 
through the character generator at the full 14MHz to generate the full 
80 characters.
As William was saying, you have 12 scan lines / character in order to do 
things.

The VDG has a number of pins that control the graphics and text modes 
and the various combinations of colors.
These pins can be connected in different ways to the RAM data bus during 
phase 1 of the CPU E clock.
In 2 pixels per byte graphics mode there are more bits for controlling 
the color of those 2 pixels, i.e. 4 bits per pixel or 16 colors.
The range of colors are traded off against the  resolution of the 
graphics pixels.
In lower res mode you have more bits for more colors. 4pixels / byte 
you'd have 2 bits / 4 colors per pixel.
8 pixels / byte you's only have 2 colors. if you had a color palette you 
could specify what those colors where.
There are different structures to the graphics modes. Some modes have 
the pixels across the screen where as other have the pixels in rows and 
columns.

I would imagine most people on the list who have programmed the graphics 
would be fairly familiar with the byte layout in the different graphics 
modes.

The 14MHz is divided down by the SAM/VDG to produce the E and Q clock 
phases for the CPU.
I assume the 14MHz is divided by 2 to produce a symmetrical clock then 
divided by 8 to generate the CPU clock phases.
I think the SAM actually generates the address for the VDG memory.
When you set the SAM base address you do so by reading and writing the 
memory address for each address bit because I don't think the SAM actual has
the CPU data bus connected to it. All it knows is the CPU address that 
is on the bus and the state of the read/write control line.

I think there is a pin that resets the VDG scan line counter that allows 
the VDG to be synchronized to the address generated by the SAM.
The VDG takes the data from memory at the address generated by the SAM.
It does not generate it's own video memory address like the 6845 CRTC 
that was used in the early IBM PC CGA graphics cards.
That's my reading of the data sheet and CoCo schematic.

I would imagine the  GIME in the CoCo3 was backward compatible with the 
SAM and VDG in the CoCo2 and 1, so I'd imagine they took the SAM and VDG
design, enhanced it with MMU and added other features and put it in the 
GIME chip.

I'm sure most people on the list know all this.
I'm reasonably familiar with the chips in the CoCo 1 & 2, although I'm 
not really up with all the registers in the GIME chip.

I'm sorry to bore members of the list with all this, but i was wanting 
to point out that I am reasonably familiar with the structure of the chips.

John.


-- 
http://www.johnkent.com.au
http://members.optusnet.com.au/jekent