© Attila Tarpai (tarpai76 gmail)
We're talking about cards from the glorious 90's, when the PC graphics market was hot, full of different chip makers and were getting more and more interesting every week. So the answer is yes - but after hours and hours of trial and error and frustration. I had to modify both boards, soldering, making cables, lots of programming. And I'm not an electro engineer either, just a programmer with a shitty soldering iron and a cheap digital multimeter. But it basically worked!
PC consumer demand was always high for video solutions, playing MPEG-1 files, display analogue video sources, watching TV on the PC in a window or full screen. This required a little more bandwidth than ISA buses could do, processors were barely enough to decode motion video and pump raw data through the PCI bus for the graphics chip. Video digitizer chips appeared on the market mainly from BrookTree, Phillips and ITT, on the other side graphics chip makers like ATi, S3 integrated hardware support in their chips to accept digital video input from these digitizers, defined formats and pinouts etc. These video digitizer chips (eg. Bt819, SAA7110) were either soldered on the graphics card itself or onto an add-on card, which connected directly to the graphics card through some kind of Feature Connector. Different solutions existed for overlay, shared frame buffer, proprietary connectors and pixel buses.
I owned that time an ATI-TV ISA card. ATI-TV ISA was a companion digitizer card to some ATI chips, like Rage II. Powered by a BrookTree Bt829 chip, the card only needed power from the ISA slot and pumped digitized video through the AMC connector's ribbon cable without CPU intervention. That fascinated me in 1996, in the age of 486DX-es.
+----------+ | FB RAM | +----------+ in| |out | | | | +-----------+ +------------+ ~~~~~~| digitizer | ------> | CON CRTC | -------> monitor +-----------+ | | | VIDEO | | chip | | | +------------+ | | ------------------------------------------------- PCI bus ------------------------------------------------- | +-------+ | CPU | +-------+ | +-----------+ | MAIN RAM | +-----------+
CON is a physical connector, a bunch of pins on the video chip that can receive digital video data. It' called AMC, ATI Multimedia Connector for ATi chips, and LPB, Local Peripheral Bus for S3 chips (the two I know about).
I was interested in video digitizers that don't connect to the PCI bus and to the CPU, like Bt829, Philips SAA7110/SAA7111, cards. They can be controlled only through the video chip and the I2C bus. As for the S3, higher-end video digitizer combo cards existed and was made by the German SPEA and Miro (later Diamonds). During this little project I bought 2 of these cards from eBay, both based on S3 Trio64V+ so only the programming is necessary to do without any hardware hacks before modding any ViRGE-cards. Programming the SPEA board was helping me a little, but it has its own challenge. There also existed add-on video digitizer- or decoder boards connected with a ribbon cable, but I've found no solutions for ViRGE at all. Maybe because it was ment to be on the market as a 3D-accelerator - but we all know how this went down.
I'm testing these hardware on an ancient PC to see how they could have been performed with software without restrictions. This is a Dell Optiplex GX1 with a 400 MHz Celeron, integrated 3Com NIC with PXE boot ROM. Basic I/O through the serial port and putty or similar on the host machine. The Dell has a rising card with 2 x PCI and 2 x ISA slots.
Earlier I wrote a small, mono boot kernel for x86 in C. Very simple software multitask, uses 32-bit flat memory model and unrestricted access to the machine's hardware (non-protected mode). ISA interrupts, messages, semaphores, malloc, and some others. It communicates with the host machine through the serial port and booted from floppy. Exactly for bugging and programming different hardware, mainly video chips (S3, ATi, Cirrus, SiS). I modified to PXE boot and use it with the excellent TFTPD.
I took a few hi-res photos and started to discover the board's connections with a digital multimeter.. for hours.. and reading data sheets.
By looking at the ATI-TV ISA board there are quite a few IC-s, components and connectors:
My ATI-TV ISA has 2 clocks: one 35.47 MHz and another 27 MHz. It's PAL-version, there is no NTSC 28.64 MHz clock on it. The 27 MHz clock is for the Teletext decoder IC - through a hand-soldered wire of some kind, but placed as clock-2 for Bt. NUMXTAL is unconnected leaving one source clock only for Bt829.
Bt829B and other IC-s on ATI-TV ISA use the 2-wire I2C-bus for reading/writing registers. The AMC connector has also 2 pins for SDA and SCL (pin Z7 and Z12), indeed connected to Bt pins.
Bt829B has 4 analogue inputs. On ATI-TV ISA these are connected as:
Bt Pixel output is 8-bit on ATI-TV ISA. Only VD8..VD15 are connected and leads to AMC Y1..Y8.
Bt has a bunch of video timing signals: VRESET, HRESET, ACTIVE, FIELD, DVALID, QCLK.. It turned out quickly that none of them reach the AMC connector! ATI-TV ISA is a digitizer card designed to connect to earlier ATI chips, like Rage II, with a ribbon cable through the 40-pin AMC connector. Bt829 is set to 8-bit stream mode conforming ITU-R BT.656. No sync pins required, certain YCbCr values code vsync/hsync and field. Bad news for ViRGE and for this little project: ViRGE cannot read this format. It needs VSYNC, HSYNC, LCKL and data connected to the LPB connector. FIELD, VRESET, ACTIVE and QCLK from Bt ends on one side of that 4-row double pad (circled). The other side leads up to the AMC connector pins, but is unconnected, most likely through a missing 330Ω SMD resistor network (except that CLKx2 is connected instead to AMC connector Y9):
Bt829B OE# pin is connected, i.e. not fix enable the outputs. The PCF8574A is an I2C 8-bit I/O expander with I2C slave address 0111 xxx0 (xxx hard-wired through 3 pins). It has one register and through the 2-wire I2C-bus it can drive 8 outputs, P0..P7:
On ATI-TV ISA the I2C slave address is 0111 xxx0 (0x70) and one of the outputs (P7) drives OE# - which is high on reset. That's why I didn't get any output first. By writing '0' to bit7 enables the Bt (I just write 0 for the whole register):
+--------+ | |----> | |----> | |----> SDA ----->| |----> SCL ----->| |----> | |----> | |----> | P7|----> OE# iic_write_byte(0x70, 0); +--------+
My ViRGE/DX board was not really built for LPB peripherials:
But all the tracks and connections are present on the board itself, so after figuring all these out let's solder!
The CD4052B channel multiplexer is missing from the board. We extend the I2C- bus a little.
The other problem for ViRGE is CLKx2, which is connected to the AMC connector. If PAL and 8-bit mode, CLKx2 runs @ 35.47 MHz.
Bt using PAL clock source:
35.47 MHz 17.5 MHz | | | | CLKx2 CLKx1 | | OSC ----->---+---/2-----+ 35.47 MHz PAL
The 8-bit mode uses CLKx2. That might be too tight for ViRGE. According to the original ViRGE 325 Data Book, the LCLK Tcyc should be in the range of [30..200] ns. A 35.46895 MHz clock has a period of ~28 ns:
<--------> ~ 28 ns PAL <------ NOW THIS MIGHT BE A PROBLEM: ViRGE 325 LCLK Tcyc [30..200] ns ____ | |___ 1/35.46895 = 0.028
OK, what about NTSC, which clocks a little slower? 8-bit mode NTSC 28.64 MHz:
<--------> ~ 35 ns NTSC <------ This should work: Tcyc [30..200] ns ____ | |___
Maybe my ViRGE/DX could handle it, but to be sure and eliminate another factor, I decided to switch the clock to NTSC and ordered a pack of 28.636 MHz crystal oscillators:
At this point I had no idea which Bt-pins I should use exactly for sync and whether they will be connected correctly to ViRGE. Furthermore, to experiment programming both Bt829 and ViRGE in the dark was a little frustrating. First I kept CLKx2 and used VRESET and ACTIVE. VRESET comes between each field of digital video data (active low). ACTIVE is like HRESET, approximately, just wider (meaning both H/V sync polarity stays active low in ViRGE MMFF20 register). On the unsoldered pad-row, I've connected VRESET and ACTIVE from Bt829 up to the AMC connector (well, not something I'm proud of, but with my soldering iron..):
There was a picture, finally, but the video just didn't scale, looked awful and the results were quite disappointing...
I almost gave up the whole thing. I read the Bt829 data sheet again and realized something important: HRESET, VRESET and CLKx2 runs always at a fix frequency: QCLK detones CLK cycles when valid pixel is output in the sync window (see the Bt notes page). So I've connected QCLK too - but first removed the resistor connecting CLKx2 to the same path. At this point the 3 pins go right up to the AMC connector without any SMD resistors and/or capacitors. I was anxious to see how this goes: and no picture at all. That made no sense, QCLK should be pulsing when CLKx2 was pulsing. The LPB just doesn't want to kick in.
I've connected DVALID to LCLK and an image appeared:
Disastrous image - but promising! DVALID gates CLKx2 to produce QCLK. So what's the difference?? Bt829 data sheet again: ACTIVE also gates CLKx2 by default, but this can be turned off, leaving QCLK running free in the sync active periods. I turned off gating QCLK with ACTIVE (0x1B — Video Timing Control retgister): and voila, finally the correct image! Seemed ViRGE needs a running clock in sync active times too to sense valid video data. This is not in the data book!
Connecting ATI-TV ISA AMC to ViRGE/DX LPB connector
Through composite-video and set to NTSC
Make some LPB - AMC cable from a floppy cable
ViRGE can be an I2C bus master through bit-banging MMIO register MMFF20, but before connecting the two boards there were som issues:
The digital multimeter confirmed that tracks and connections are there, so lets start soldering!
Trio64V+ or ViRGE can be an I2C bus master by driving pins 206 and 207.
The first thing to do was getinng in touch with these components, read registers
hook up the ATI-TV ISA board with 2 wires to the ViRGE/DX board and ViRGE can be an I2C bus master (), but this is a little tricky because of the missing CD