Re: Videx Videoterm 80

[Michael J. Mahon <mjmahon@aol.com>]

Marc S Ressl <mressl@macgui.com> wrote:
> Following the format of the previous posts, I'll continue describing old
> Apple II peripherals. And as before, this will soon be available in
> OpenEmulator :-).
> 
> Today we'll be describing the Videx Videoterm 80. The schematics are quite
> straightforward, nevertheless there are some important details that must not
> be left aside.
> 
> The card is composed of:
> 
> * 1K of ROM memory
> * 2K of static RAM memory
> * An MC6845 CRT display controller
> * Logic to control the whole thing
> 
> Memory is mapped as follows:
> 
> * $C300-$C3FF is mapped to $0300-$03FF of the ROM (the latest firmware only
> supports slot 3)
> * $C800-$CBFF is mapped to $0000-$03FF of the ROM
> * $CC00-$CDFF is mapped to RAM. It is banked, meaning that what is visible
> in this range can be either $0000-$01FF, $0200-$03FF, $0400-$05FF or
> $0600-$07FF of the RAM
> * $CE00-$CFFF is used to disable $C800 memory
> 
> The I/O range is mapped as follows:
> 
> * All I/O accesses talk directly to the MC6845, but also change some
> flip-flops
> * Address bit 0 selects the address or data register of the MC6845
> * Address Bit 1 does something undocumented that will be explained later :-)
> * Address bits 2 and 3 define the RAM bank that is visible in $CC00-$CDFF
> 
> Now to the more exotic facts:
> 
> * The MC6845 uses a 17.430 MHz crystal for generating the video clock
> source. This is a bit faster than the Apple II one (14.31818 MHz), so the
> video quality is a bit higher.
> * The 17.430 MHz video clock is usually divided by 9 to derive the character
> clock. Now to the undocumented part mentioned previously: by accessing I/O
> memory with bit 1 set, the character clock is divided by 8 instead, which
> allows for denser characters. Most likely nobody ever used this, but it is
> available on the card.
> * The cursor is generated by simply inverting the font's bits.
> * There are two font EPROMs that control the font for characters $00-$7F and
> $80-$FF. It seems that it was usual to have an ASCII font in the lower range
> and the inverse ASCII font in the higher (Visicalc 80 supports this).
> * The 9th font bit is replicated from the 8th font bit. This is important
> for inverse character sets.
> * Video RAM is accessed continuously from the MC6845 in order to show video,
> but the Apple II can also read/write from it. There is a circuit that
> multiplexes these accesses and gives priority to the accesses from the Apple
> II bus. When that occurs, the MC6845 does not display valid video
> information.
> * And now to the most interesting part. There is a *REALLY AWFUL AND LAME*
> (imho) circuit implemented with a diode and a 100 pf capacitor. It's
> function is to disable the video output for a short time after whatever RAM
> access from the Apple II bus. I find this so awful because it was done with
> an RC circuit :-), as it takes advantage of the TTL input-resistance. I
> checked the specs, and by taking an input resistance of 100 kOhm for U22
> (check schematics), one gets a time constant of 0.01 ms, which is approx.
> 174 video dots.
> * This last circuit is important because it disables video output while
> scrolling. Otherwise you see shadows of previous lines at the bottom.
> 
> So that's it! It really took some time to grasp the last part about video
> disabling, but I think it was worthwhile for truthfully emulating the legacy
> Videx Videoterm 80 card!
> 
> With the best wishes,
> 
> Marc.-

Thank you, Marc, for your thorough analysis of this card. 

I built myself a clone of this card in 1982, but was focused more on
construction than analysis. I remember having to trim the video generator
parameters in firmware to match the vertical sync more precisely to the ][+
so that I wouldn't have to tweak the monitor to avoid a slight "flagging"
of the first few lines of the raster. 

I remember being curious about how the card avoided "sparkle" during RAM
updates, since the design was clearly not dual-ported. Now that you've
explained the kludge Videx used to make the sparkle invisible, the mystery
is solved, but at the cost of my respect for their designers. ;-)  Counting
on TTL input loading as a timing component is really sleazy design. 

You've also made me curious about the "compressed character" mode...

Nice work!

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon