Video output on a homebuilt computer

  Hi folks.  I've recently been buzzing with the urge to make a homebuilt
computer, and while I pretty much have the concepts down behind
interfacing a processor with memory and I/O devices and all that, I
want to learn more about video output.  I know basics about NTSC signal
generation, but not nearly enough to actually do it.

I did some digging on the old CGA graphics adapter, which I used myself
for many years, and found that the technology involved is pretty much
what I'm interested in.  CGA seemed pretty capable of outputting NTSC
inherently; CGA monitors ran at 60hz (same as NTSC), and there's
something to do with the 14.318mhz crystal of the original XT, dividing
it down to the color burst frequency or whatever.  So, upon learning
that the heart of CGA (as well as EGA and a few other computers) was
the 6845, I went ahead and found me an old one on Ebay pretty cheap,
for when I'm ready to work with it.

What I'm interested in learning for the most part is how exactly the
CGA card generated its pixels onto the screen/monitor.  I know that the
6845 is apparently used primarily for timing.  This means something
else is responsible for actually reading the video ram and determining
the pixel color, and outputting the appropriate "color burst" to
display the pixel on the screen, correct?  What kind of circuit(s)
exactly would be involved in such a feat?

I'm not really interested in using a computer monitor for a display as
of now, I just want complete composite output.  Theoretically, this
would allow for many more color capabilities than a CGA monitor would
allow, if I'm thinking along the right lines.  CGA monitors were just
RGBI, giving a maximum of 16 possible colors, where as with NTSC, you
can generate pretty much any color depending on the color information
you send with the signal.

Anyhow, I'm sure I'll just be starting with text output anyway, and
probably minimal colors (if any).  I mostly just want to learn the
basics of generating a terminal display on the television.  40x25
characters seemed to always look best on a TV, so that's probably what
I'm shooting for.

So if anyone can help point me in the right direction as to where I'd
get started with any of this, it'd be much appreciated.  Even some NTSC
basics (possibly relating to the 6845) are fine, since generally it's
easier to understand coming from a person than technical references!
And if anyone else has done any video output from their own homebuilt
machines, I'd be curious to know the methods you employed.

Thanks in advance!

 FyberOptic wrote:


CGA resembles NTSC because TVs were (and obviously are) everywhere. Meaning
  if you design, in 1980, a display system with that timing all the basic
parts are off the shelf items (CRT, horizontal/vertical deflection
coils/circuits, etc). Strip out the RF stuff, since it's direct connected,
and you not only save money (if you're manufacturing one) but the
resolution increases because you don't have to scramble the signal into
NTSC/composite.

Poor man's version is to use a TV set, with the limitations of NTSC. But
you didn't have to buy a separate monitor.


Boy that's an oldie. What are you planning to connect it to?

At any rate, the data sheet has, as the saying goes, everything you need to
know.

http://www.alldatasheet.com/view.jsp?Searchword=684



Close. The 6845 provides the timing, addressing, and 'character code' that
is to be displayed. You then just add RAM and a character ROM, which has
the dot definitions for what a code 'A' should look like, and a bit of
glue. In the industrial world that was also used for "character graphics"
since you could make code 'A' look like a letter sized valve, for example,
if you wanted to by putting the right dot pattern in the character ROM. And
since all of ASCII fits in 128 codes you had another 128 to play with. Make
some as vertical/horizontal/diagonal lines and you could make all sorts of
"character graphic" diagrams. Color the bad ones red, the good ones green.
Flash the ones needing attention. SUPER COOL!



There is no "color burst." It's not a broadcast signal, the lines are
connected directly to the monitor. TTL levels, in fact. RGBI (Red, Green,
Blue, Intensity)



Then you're going to need an RGB to composite encoder. The IBM CGA adapter
had one, for connecting to a TV set (either composite or RF adapter) but I
don't recall what they used. Most people didn't know it was there since the
main point was the better resolution with a monitor.


Well, you're half right but probably for the wrong reason. Composite, and
analog RGB (like modern monitors) have the *capability* to display an
infinite number of colors but whatever is telling them what to display has
to be able to, well, tell it to display them. And without doing tricks, the
6845 doesn't have the 'brains' to do that.

Got to put yourself back in 1980, or so. Memory, by today's standards, was
incredibly expensive so you weren't going to make 'personal' video display
cards with multi-Meg memory banks. Heck, the whole bloody PC maxed out at
640k ao there just aren't any 'bits'... no storage... to do hundreds, much
less millions, of colors. At least not directly.

There were a lot of tricks used back then but one was the color pallet: A
set of registers that held the 'code' for up to x (depending on who was
doing it) colors, each of which could be any color the register code could
create.

Say it's a bank of 16 bytes (since that's what the 'original' color coding
supports). A byte can do 256 codes so that's 256 possible colors, although
you would only have 16 of them at any one time. So, for example, what had
been the color "bright red" can select register 10, which contains the code
for whichever of the 256 colors you put in it. (not saying the IBM CGA
worked this way, just describing one of the old tricks)

Now, one trick you *could* do with the IBM CGA adapter is use that
composite output almost no one knew about and take advantage of how lousy
NTSC is in order to 'fool' the composite monitor. As it turns out, the 640
dot 'high res' (640x200) graphics mode sent the dots at pretty close to the
color burst frequency (remember, the thing that isn't there?) and that
fools the monitor into *combining* multiple dots into one, with color. You
end up with 160x200 dots and 16 colors (if you're lucky because combining a
whole 4 dots is a bit iffy) because the chroma decoder thinks those dots,
since they shift at the right frequency, are color information.

Doesn't sound like much but it's an improvement over the 4 colors in
'proper' (RGBI direct connect) 320x200 graphic mode, but at half the
resolution. Hey, you can't get 'more data' than is in the memory. You
either use it for dots or color.

That 'trick', btw, is how the AppleII created color on a composite monitor,
by shifting the dots out at the color burst frequency, and lead to the
misimpression it could do 4 colors at 640 resolution. It's 640 mode, all
right, but the dots are combined in twos to cause the color so it was 320
dots, in 4 colors.



That's because it's NTSC/composite. Note that, at 8 bits per character
(because it's a hell of a lot simpler to shift whole bytes than pieces of
them), 40 characters is 320 dots. If you try to do 80 characters, meaning
640 dot horizontal, you'll likely get garbled characters, but colorful ones
;) because it, again (like the above examples), fools the chroma decoder
into thinking it's color information (depends on how good the TV set is and
modern ones are harder to fool).

 
David Maynard wrote:

My first PC-compatible was an old IBM Portable PC on its last leg,
which anyone who knows anything about computers from that time period
knows it was far from "portable" by today's standards, unless a 30
pound suitcase fits your definition!

But yeah, it had an amber screen in it, hooked onto the composite pins
of the CGA card, which also happened to have a composite jack on the
back of it as well.  I learned early on that televisions weren't very
fond of 80x25 from there, even though the amber display was beautifully
crisp.



I found a couple copies of the datasheet already, but as with most
of'em, they expect you to already have a good understanding of the
principles behind part of its operation, so some of it didn't make a
lot of sense to me, which is why I ended up posting here.

As for what I planned to connect to it, I've tossed around a couple of
options.  I have an old 6507 processor pulled from a dead Atari 850 I/O
box which I considered using as the brains, since the address and data
lines are all seperate.  The downside is that the 6507 is rather
stripped down compared to the 6502, leaving it with no IRQ/NMI lines,
and only 8k addressable memory.  Not to mention, a 1mhz clock.

Since I'm fond of all the 8088's I used over the years, the 8088 chip
is of course a more tempting direction, especially when I already know
assembly for it (having written a boot loader and such to better
understand how the PC works at that early stage).  The downsides to
this chip though are that I need at least one latch (since the data
lines and first 8 address lines are multiplexed), and that it wants a
33% duty cycle from the clock (though I understand at 4mhz and less it
can manage at 50%).  This means more parts I'd have to try and acquire,
and shipping is generally much more than the parts, unfortunately.

As far as memory goes, I noticed there's 32k srams on some 486
motherboards I have laying around that I could borrow.  T'was their
cache memory, I believe, so it should be plenty fast for either system
and/or video memory.  And I ordered me a 256k flash eeprom to mess
around with for rom code.  Though I might need a second of those as a
video rom.



I'm not quite understanding the routine that the 6845 goes through to
do this though, and how much of it it actually handles itself.  I know
that it has address lines, but it doesn't actually read the data from
the display memory, does it?  My understanding so far is that it just
acts as a pointer, for external circuits to fetch the appropriate byte
from video memory, and then associate that with the appropriate pattern
from the character ROM, which then gets shuffled into some other
hardware to actually be displayed.  Correct me if I'm wrong, or missing
some steps there.

The datasheet also mentions the use of a shift register, and I'm not
clear on the use of that, either.



I'm also not entirely clear on where the RGBI signals are coming from.
They're obviously not coming from the 6845 (aside from
vertical/horizontal sync).  The 6845 doesn't seem to have any concept
of color, so from what I can tell, it's just pointing to the proper
memory location of the character byte, after which seperate hardware
determines if the current pixel is on or off (based on the position in
the text character currently being drawn).  And then I assume (in the
case of CGA) that this on/off pixel value is passed on to other
hardware, reading the attribute byte associated with that pixel, and
outputting the proper RGBI pixel to the display.  Hopefully that wasn't
too confusing.

So my thinking was that instead of creating the RGBI and then going to
composite, why can't I just create the composite directly?  I don't
have a good enough understanding of creating color on NTSC yet
obviously, but black and white is apparently as simple as some timing
and sending an appropriate voltage between like 0.3 and 1.0 volts to
get levels of gray.  What might be the simplest way then of converting
the contents of the video ram directly into a white pixel on the
screen?

I've seen a guy use a PIC to generate display output entirely on-chip,
converting TTL into composite signals just by using resistors.  That's
processor-intensive though since it's all done in the same place as
your code.  But from what I hear, this is how the Atari 2600 worked,
too.

And I hear that with the 6845, I can somehow AND or XOR or something
the horizontal and vertical syncs in order to generate a composite
sync, or something along those lines.



I'm probably missing some particular detail, but I thought CGA's colors
were just limited because it only had 16k of video memory.  Why
couldn't one still run like 320x200 with 16 colors (like 40x25 text
mode is), except in graphics mode, as long as you had 32k of video
memory?

With EGA, for example, having more video ram allowed for more colors
and higher resolutions, and many EGA boards later on came with more ram
for this reason.  I've heard mixed info though as to whether EGA also
used the 6845.



lol I used CGA for way too long, I know all about how it can't handle
that many colors.  That locked palette of 4 colors was possibly one of
the biggest downsides, especially considering the colors chosen.  If
only the palette had been programmable out of the 16 possible colors.
Though I understand there's a "trick" to change the background color to
one of those 16, at least.

I have to admit though, having never truly understood how CGA worked on
a deep technical level until like a few days ago, I've come to
appreciate it a lot more.  Actual TTL output, driving each primary
color beam in the CRT, is really a rather great way of displaying
color.  Very simplistic, minimal interfacing electronics.  EGA monitors
were similar, but had some more intensity lines to give up to 64
colors, though even EGA video cards could still only display 16 at a
time I think.  As such, I still prefer the simplicity of the CGA
monitor.  If I had the workspace to set up one of the things to
experiment with, I'd definately be doing that instead of looking into
composite so much.

I bet if CGA could have displayed 16 colors in graphics modes, to take
advantage of the monitor fully, it might have lasted even longer than
it did.  The color limitations were probably the biggest reasons people
went to EGA, though even the early EGA cards couldn't even display many
colors in the high-res 640x350 mode, basically making it just a better
version of CGA for a little while, until they started putting more than
64k vram.



(snip)

Aha, so that explains why the high-res modes always had that color tint
on a television!

640x200 was a big enough pain to program in to start with, because the
screen was basically split in half in video memory.  I can only imagine
how 160x200 would have been.

So without keeping you tied to the computer for ages just to reply to
my long-winded posts full of questions, how exactly would one go about
generating color signals just over a normal composite line?  You don't
have to go into details, but apparently my thinking wasn't right on the
whole "color burst" thing I picked up somewhere.  I'm mostly curious
where it's inserted in the composite "stream", and what the colors are
"made of".  

And thanks!

 I spent some time reading back over the datasheet a few times and
studying the diagram of a generic arrangement, and parts of it are
making more sense.  I think I'm getting a lot better understanding of
what it does, and what needs to be done elsewhere.

Apparently my initial thinking was right; the 6845 doesn't read the
memory at all, it just uses its address lines on the video ram to find
the screen area currently being processed.  From that, the data is
grabbed by a latch for temporary storage.  The data itself (the ascii
character code to display, basically) is used as part of a set of
address lines, combined with the 5 character row address lines from the
6845, to find the set of bits from the character rom to be displayed.
Those bits are shuffled on down to a shift register, which then spits
out one byte at a time of whether a particular pixel is on or off.

All of this seems to be controlled by two different clock signals.  The
"outermost" clock is what I guess is called the bit clock.  It runs the
fastest, and pushes the data bits through the shift register and on to
some video processing to display it on the screen.  The character clock
is apparently what the 6845 itself runs off of, which is the pixel
clock divided by the width of the characters.  In my case, I'd be using
normal 8x8 characters, so my character clock should be the bit clock
divided by 8, as far as I can understand.

The clocks also trigger some other components, but I'm unsure as to
which clock speed triggers which.  The latch being one of them.  I
guess it would also trigger a data buffer to keep the data bus for the
video display seperate from the system data bus, but I'm kind of
unclear on how this part works, too.

For learning/testing purposes, I could probably just use a rom in place
of video memory, with some text already written into it, and forget
about needing any multiplexing or data buffering.  It'd be an entirely
enclosed circuit, so no worries of bus collisions or whatever.  I might
could just use a PC parallel port to talk to the chip in order to setup
the registers and such.  But I still don't really know enough to know
what frequency the clock would need to run at.

14.318 seems like a logical guess, since that's what the XT was
developed to produce, to share with the CGA board.  So the bit clock
would be 14.318, and the character clock would be 14.318 / 8?  Four
flip-flops should take care of the dividing, I guess.

Anyhow, I just thought I'd post my observations and assumptions,
possibly saving some explanation in response to my last post.  I did
some more reading on composite NTSC signals, but I still don't know for
sure how I'd take the horizontal and vertical syncs, and the on/off
pixel values, and turn all this into a composite signal.  But at least
I'm this much closer!

 FyberOptic wrote:


Right.


They give you a 9 dot/character example in the datasheet.


Like most engineering things it's isn't always so simple as it might seem
on the surface. If you've looked at the NTSC specifications you'll notice
that not all of the horizontal time period is available for video content
as some is taken up with sync (same for the vertical); meaning you can't do
something trivial like just multiply 320 times 15750 for a 320 dot
horizontal res display.

In addition, for composite, TVs are adjusted to over scan the image so any
misalignment from source to display won't leave black bars on the edges of
the screen. That's not a terribly big problem for 'moving pictures' but
it's a real bugger bear for a text display to have the edges off screen.
Dern hard to read what you can't see ;) So you have to scrunch the data
into a smaller section of the theoretically available area to insure it'll
all be visible, which is why the 'home computers', like Atari, had a 'blue
rectangle' (white text on blue background) on the screen with black bars on
all four sides. They were making sure the 'data' would always be visible.

Purpose built monitors intentionally *under* scan to ensure all the usable
video content is *on* the screen so even with the same bandwidth
limitations you can, at least in theory, get more on a monitor built for it
than on a TV set, simply due to over/under scan.


Depends on how many dots per character and how many characters per line you
decide on.

Usable luminance bandwidth on a TV set, to allow for color and worst case
demodulation characteristics, is about 3 to 3.2 MHz (3Mhz to play it safe).
Now, a 'hertz' is a cycle which, for pixels, would include an on and an off
(two 'on', or two 'off', in a row would be DC for that period). That means
two pixels per 'Hz', which means around a 6 to 6.4 Mhz pixel rate, and
clock. In the 'simple' math, that we've already discussed doesn't work,
that comes to roughly 380 to 406 pixels per horizontal scan period; minus
the horizontal sync time and over scan allowance. Which is how they come up
with 320 horizontal dot resolution and 40 characters per line in text mode
for home computers intended to run off TV sets.

Or course, you don't have to send them at the 'max' rate if you can get by
with less resolution.

(The 'conversion' I gave for bandwidth Hz to pixel rate isn't 'strictly'
correct but it works for this purpose)

As a side note, *really* cheap computers would use a 32 char by 16 line
display because binary wraps at 16 and 32 so you don't need fancy counters,
simplifying the video circuitry. Everything just 'naturally' wraps and
works at the right places, and it fits in only 512 bytes as well with no
wasted 'holes'.


Here ya go, an example of a one chip doit: MC1377

http://hardware.speccy.org/datasheet/MC1377.pdf