Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!INGRES.BERKELEY.EDU!hatcher
From: hatcher@INGRES.BERKELEY.EDU.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: The LIVE Digitizer from A-Squared...
Message-ID: <8705290639.AA04316@ingres.Berkeley.EDU>
Date: Fri, 29-May-87 02:39:09 EDT
Article-I.D.: ingres.8705290639.AA04316
Posted: Fri May 29 02:39:09 1987
Date-Received: Sat, 30-May-87 08:04:48 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California, Berkeley
Lines: 38
Summary: Some further clarification

In article <149@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes:
>2. If it takes over the machine does this mean it WON'T work with my hard
>disk drive?

It *cannot* work simultaneously with a hard disk. It takes over the machine
because there are just *exactly* enough memory cycles available to read in
the video data at the same time that the screen display is maintained. The
only extra left over at all are the cycles available during horizontal and
vertical retrace, and accessing another peripheral during this time would
be difficult enough that it would have to be integrated with LIVE. The
thing has to use self-modifying code just to implement *menus*...that's about
as bandwidth limited as you get! (Note that this prevents its use on a
68020, since the cache on a 68020 prevents self-modifying code.) BTW although
people are usually down on self-modifying code (for good reasons), in this
particular case of supporting a real-time device, it was the only way to
get the job done, so more power to him for getting it to work at all.

And even if they did add a tightly coupled hard disk driver, supporting
a hard disk with very very lenient timing requirements, it wouldn't
really help, because you wouldn't have the bandwidth to push the incoming
video out to disk. Hmmm...unless you turned off the screen display...
then you'd at least have the memory bandwidth. But then you'd run into the
problem of designing a hard disk controller that could *accept* data that
fast. Certainly none of the ones currently available for Amiga's could
handle it (that I know of, anyway).

The intention of LIVE is to fill memory with video, and THEN dump it to
hard disk (or floppy...).

There is no competition to speak of between LIVE and DigiView; ideally
you'd want to have both. One for ultra-high quality stills (24 bits per
pixel input), the other for ultrafast video (15 frames per second at $300
is a real breakthrough). The area of overlap is that you can use DigiView
to grab a (slow) frame at a time from a videotape with a single-frame-advance
VCR, and you can use LIVE to get a bunch of (lower quality) frames and
then ignore all but one. Thus each one can poorly do the job of the other.
	Doug Merritt		ucbvax!ingres!hatcher
				hatcher@ingres.BERKELEY.EDU