Xref: utzoo comp.os.os9:1250 comp.sys.m6809:1317 Newsgroups: comp.os.os9,comp.sys.m6809 Path: utzoo!utgpu!watserv1!maytag!watdragon!skeppeljones From: skeppeljones@watdragon.waterloo.edu (Stephen Keppel-Jones) Subject: Re: CoCo 4 (TC9) Message-ID: <1990Oct31.065325.23183@watdragon.waterloo.edu> Organization: University of Waterloo References: <2989.272c8e83@cc.nu.oz.au> Date: Wed, 31 Oct 90 06:53:25 GMT Lines: 201 68070/VSC Specifications and Features ===================================== I hope I'm not rocking any boats, but alot of people are curious about 68070/VSC specs, and nobody "in the know" has revealed much. So I'm gonna blow the doors off the SIG and reveal all. Note: while I think every fact in this file is correct, I wouldn't bet $1000 on it! I place this file totally in the public domain... copy away! Matthew Thompson Ottawa, Ontario, Canada The SCC68070 festures: ---------------------- - Made by Signetics (Philips), uses CMOS tecnology (low 45mA current drain). - 99.9999% MC68000 software compatability. Exceptions: - Implements full bus recovery (like the MC68010), adding a measure of crash-proofing to the system. However it only stacks 17 words during recovery, instead of the 68010's 29 (which the 070 manual claims is redundant, anyways). - In the System State the 68070 stacks four words (like the 68010), instead of the 68000's three. - Other than that, they are identical. - Runs at 15 MHz, about twice as fast as standard 68000-based Amigas, Macs, and Ataris. - Cycle times for 68070 instructions are different than on a 68000, though. Most instuctions take more. But at 15 MHz, they're all faster than any of the above 68000 systems (heh heh). A Bus Cycle is 4 Clock Cycles, while a Machine Cycle is 3 Clock Cycles. Most of the handiest instructions have been cranked somewhat faster, such as MOVE. - Two high speed DMA channels, each capable of 2.5 Mega-xfer/sec I/O from/to RAM xfers (one channel at a time, of course). Channel 1 has a higher priority than channel 2, and channel 2 can also do 1.25 Mega-xfer/sec RAM to RAM block copies*. Xfers can either be in bytes or words. Supports daisy chaining to external DMA chips for more channels. The DMA ports on the 68070 are identical in register structure and function as the Motorola MC68430/40/50 DMA chips. All arbitration is handled by the 68070. *:Equivalent to copying thirty-nine 320 x 200 x 256-color screens per sec! - I^2C bus interface (I^2C is an industry standard ~100kbaud serial interface intended for el-cheapo chip interfaces. Instead of complex decoding chips and parallel bus wiring, any I^2C device (such as configuration EPROMS, time clock ICs, serial port chips, joystick control chips, etc., etc.) can all be hooked together by a couple common wires, and then everything is handled & figured out by on-chip arbitration circuitry. Major reductions in wiring and design complexity are achieved.). - On-chip serial interface. Features seperate baud rates for receive and xmit; can generate interrupt at any priority level; Odd/Even/No parity; 7/8 bits; built in CTS and RTS lines; full/half duplex operation; framing error detection; and more. Using an external clock of 4.9152MHz, you can get baud rates of 75, 150, 300, 1200, 2400, 4800, 9600 and 19200. Using a clock of 8MHz you can also get 31,250 baud (MIDI speed). - Also has built in MMU, with 8 descriptors on-chip, up to 128 with external bipolar RAM. Supports intermodule protection; stack overflow protection; and also controls read/write/execute/supervisor access to any segment of memory. OS/K wisely does not use the MMU, however, since like most MMUs on high-speed CPUs it throws in an extra wait-state, slowing the CPU by as much as 20 percent. - Three 16-bit timers on-chip. All have a programmable increment time down to a minimum of 6.51uS. One is a free-running counter with auto-reload. Two are capture counters, which are controlled by seperate I/O pins on the chip. They can generate pulses, or count the time between input transistions, or even count the number of input transistions. All timers can generate an interrupt to the CPU. - Built-in prefetch cache speeds things up a bit. - All this on just one 84-pin, square, surface-mount flat-pack chip. - Clearly designed with one single purpose in mind: to cram as much power on one chip at the lowest cost. Hence its use in our low-cost, but high performance, MM/1 and TC070 computers. The VSC chip features: ---------------------- - Real part number (hidden until now from Delphi members) is the SCC66470, (not 68470) and is a 124-pin flat-pack CMOS chip from Signetics (Philips). - Runs at up to 30MHz. - Max 768 by 560 resolution. - Max 256 colors at 384 by 560, 16 at 768 by 560, 256 at 768 by 560 if a second 66470 is connected in more-or-less parallel. I am not sure if such a piggybacking scheme will be officially supported for the MM/1 or TC070 (this is not the same as the palette board being offered). - Supports 31.5 kHz horizontal scan if your monitor can crank it. - Has on-chip DRAM and SRAM controller which supports bit, nybble, page and dual port RAMs. - Max 1 Meg video RAM, extra 0.5 Meg DRAM and 0.5 Meg SRAM supported. - Built in Blitter (PIXAC - PIXel ACcelerator). - Has all kinds of blitting features that make block and pixel blitting fast and easy. Each blitting operation affects a word value (ie up to 2 or 4 pixels depending on mode) at a time, and each word "takes less than 500nS to process." For instance, the 66470 can take a one-pixel- per-bit image definition (such as a font), convert those bits into nybbles or bytes of the correct foreground, and blit the result on the screen while masking the background using a transparent color, so that only those bits that were set affect the screen. On top off all this a programmable logic operation between the source and destination pixels can be thrown in for good measure. A 64 x 64 screen blit on a 16-color screen would only take (a guesstimated) 512uS or less. About the only way to blit faster is if all you want to do is a plain vanilla copy, thus the DMA could copy a 64 x 64 16-color block in about 45 uS. Anything else would require a fancy CPU algorithm that would take mega time. And while the VSC is blitting, the CPU can do other things. The VSC blitter can also allign source nybbles to destination nybbles, so that any pixel boundary can be used. - Block blit functions include COPY (raw), PATCH (raw with xparent masking), EXCHANGE (switch two image areas), SWAP (switch with xparent masking), COLOR1 (take all non-xparent source pixels and turn destination into foreground color), COLOR2 (like COLOR1 except xparent pixels -> background), BCOLOR1 (like COLOR1, except performs bit-to-nybble or bit-to-byte expansion), BCOLOR2 (combo of COLOR2 and BCOLOR1), COMPARE (compare pixels, set flag if match), and COMPACT (compare pixels, create a table of flags). - The reccommended color sceme is RGBI for 16-color screens, and RRRGGGBB for 256-color screens (blue is less noticeable hence it is allotted two bits of resulution). - Also supports smooth scrolls and virtual windowing. - Can also shrink or zoom by a factor of two independently in the horizontal and vertical directions during all blits. Instant multisize fonts! - The Amiga's blitter is a "monochrome" blitter. To affect a mutlicolor screen it has to blit each Amiga bit plane seperately. The VSC uses a nybble/byte scheme and does all color computation in one access. The Amiga's blitter is also so complicated to program that the current release of the operating system uses the CPU to blit text, because it takes so long to set up the blitter that it would actually take longer. The VSC was made for blitting text, and for all kinds of block copies and exchanges. The Amiga's blitter may still be faster at one-pixel-wide operations, like random-angle diagonal lines, or curved lines. I won't know till I see the bottom lines for the two machines. - Pixel and block testing, making collision detection in games and etc. incredibly fast. - On average 3 to 8 times as fast as a 68000 alone, even more. - Can cut algorithm sizes by up to 98%. - Genlock and frame grabbing support with some extra logic and a PLL, and for frame grabbing, a flash-ADC convertor. Real-time, 60 frame-per-second image digitization is easily possible. - Based on the specs for this baby, we ought to see some impressive graphics games, like Microsoft Flightsim V4.0 out running on a 320 by 200 by 16-color screen at a frame rate of, oh, say... 10 per second!? - Also has built in reset ciruitry, eliminating more discrete parts. - Support for watchdog timer. - Designed with one purpose in mind: to crank the graphics speed to the max at the lowest cost. And since it is designed to work hand-in-hand with the 68070, it's the obvious choice for a gfx chip for the TC070 and MM/1. Note that the MM/1 and TC070 only go to 480 vertical resolution max because to get 560 you have to use a 625-line 50Hz-scan standard like PAL (but the flicker would be bad). NTSC is 525 lines at 60Hz. The max horizontal is 720 for similar reasons. Also, note that normally the 66470 arbitrates between itself and the 68070 as to whose turn it is to look at RAM. It does this in the single-board version of the MM/1. But both the full MM/1 and TC070, which support over 2 Meg (way beyond the 66470 DRAM controller), obviously have seperate DRAM controllers and semi-seperate buses. The VSC gets a Meg to itself, the CPU, gets the rest to itself, and they both crank along at maximum, zero-wait-state speed. The 68070 doesn't have to wait for the VSC to grab a video word, and the VSC no longer has to wait for the CPU to be finished to get or put a blitting word. So they BOTH speed up (despite some kidding on the forum!). The 68070 can still access the video RAM, of course, but it might have to wait (a VSC bus access is 4 clock cycles, the same as the CPU). Put it this way: With these two chips at the heart of the MM/1 and TC070, it will quite some time before the competition gets as much speed and features for as low a cost as either system! -- Brian White (Using a friends account)