ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (05/23/87)
Before I start, here's a copy of a sheet that was included with the
Amiga press kit at the 1985 SIGGRAPH show where the Amiga was introduced:
--------
Amiga Software
Developer: A-Squared Systems Group
Address: 7200 Sayre Drive, Oakland, CA 94611
[Current address is: 10 Skyway Lane, Oakland, CA 94619]
Name of Program: The Amiga Eye [Now called "LIVE". Ed.]
Publisher: Amiga
Program Type: Color Video Digitizer
Application: Digitizer of monochrome or color images.
Description: This software package comes with a digitizer "frame
grabber" device that plugs into the Amiga. After capturing
an image, it allows the user to vary hue, saturation, and
luminance as well as brightness over the computer's range
of 4000 plus colors. User can record up to one second of
imaging and replay the recreated images in "instant
replay," slow motion, stop action or high speed modes.
Special Features: Interfaces with other paint programs and is compatible
with any NTSC device.
Availability: Upon Amiga introduction
--------
Ladies and gentleman, Arthur Abrahams of A-Squared has been waiting
a year and a half to make the following announcement, and did so with great
glee at last night's BADGE meeting:
----====####>>>> TO ORDER THE LIVE DIGITIZER! <<<<####====----
Call:
(inside California) (everywhere else)
1-800-626-9541 ext. 1156 1-800-452-4445 ext. 1156
Do *NOT* call these numbers until after May 29 (1987), as they
won't be active until then.
And now for the second nuclear bombshell:
Price: ---===>>> $295.00 <<<===---
How did this miracle come about? According to Arthur, A-Squared,
with the help of -=RJ Mical=-, *bought back the rights* to manufacture and
distribute LIVE from Commodore. A-Squared now has rights to distribute
LIVE for the Amiga 1000 (suggesting that Commodore may still retain the
rights to the 2000 version, if there ever is one).
More information: LIVE is a SOTS (Slap On The Side) expansion box.
It does not pass the bus. LIVE software takes over the entire machine (no
flames on this; it's impossible for it to be otherwise and be cheap). LIVE
works with Genlock, and will do cheap chroma-keying with its help.
Information on how the hardware works and how to program it will be
published and readily available. PD software to utilize the LIVE box and
to post-process LIVE images is encouraged.
For those of you with expansion cages, there MAY or MAY NOT be a
Zorro-I version of LIVE in the works. If enough of you can convince
A-Squared that there's a market for it, they may be convinced to go to the
trouble of cooking up a Zorro-I version. (I can hear Perry dialing already
:-) )
SO! Go out and buy one. Arthur deserves fame and fortune. He's
already got fame, let's see if we can help with the fortune. Buy two!
They're small, and they're cheap.
(Sorry about the commercial nature of this, but I had given up on
LIVE a long time ago, and I'm sure you did, too. But it finally made it!)
The author believes the above information to be true and correct.
If this is not the case, please forgive him, and post a correction. Thank
you.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\
\_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac
O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack")
"Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctorscotty@l5comp.UUCP (05/25/87)
Leo, I guess I must be dumb BUT: 1. If it's slap on the side thingie how does having a rack help? 2. If it takes over the machine does this mean it WON'T work with my hard disk drive? 3. At $295 what do I get? A box? A box with minimal software? A box with software equal or better than Digi-view's? 4. How do I use this thing with my Alegra? And on a related item, does it work with other boards? Or does it overload the buss? 5. How much ram does it need? Just a few, but I think serious, questions. :) I post here rather than E-Mail Leo because I doubt Leo has all the answers. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
ewhac@well.UUCP (05/28/87)
Gee, this guy talks a lot.... In article <149@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >Leo, I guess I must be dumb BUT: > >1. If it's slap on the side thingie how does having a rack help? It doesn't. As I recall, what I said was that if enough people asked real nice, A-Squared might be convinced to create a Zorro-I version of LIVE suitable for cages. I'm an advocate of the cage-type expansion path, and would like to see a Zorro-I version of the card. As it is, I can't use it with my ASDG rack at the same time. >2. If it takes over the machine does this mean it WON'T work with my hard >disk drive? Hmmm. Good question. Why not call and ask them? >3. At $295 what do I get? A box? A box with minimal software? A box with >software equal or better than Digi-view's? A box with digitizing software to run the LIVE box. Since were talking about 15 fps frame rate (12 fps in color), the software doesn't have time to come up with a super-dooper picture, but it still does a respectable job, and you don't have to wait three minutes to get an idea of what it's going to look like. If you want high-quality stills, go with DigiView. If you require the level of interaction that LIVE provides, then you need that. Investigate, then decide. >4. How do I use this thing with my Alegra? And on a related item, does it >work with other boards? Or does it overload the buss? Don't know what its power requirements are. Since neither the Allegra nor LIVE pass the bus, you can't have both. >5. How much ram does it need? > LIVE works just great on a 512K Amiga. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Bike shrunk by popular demand, dual ---> !{well,unicom}!ewhac O----^o But it's still the only way to fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
hatcher@INGRES.BERKELEY.EDU.UUCP (05/29/87)
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
cjp@vax135.UUCP (05/30/87)
In article <8705290639.AA04316@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >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 >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...). I just hope they were sane about how they "take over" the machine. Ideally LIVE would be "wired" *only* while it was digitizing. I'd want to be able to keep other processes alive (tho frozen) while running LIVE. Anyone know if this is the case? Actually, I wonder if they could allow other tasks to run (at lower priority?) if the user were willing to select a *lower* frame rate. As an example, you might want to have a process that can get frames from RAM, examine or do stuff to them, and spit them back to the screen *while* LIVE is running. Have an option to turn off LIVE's screen during this scenario. This would allow people to roll-their-own Very Vivid / Mandala type programs. -- Charles Poirier (decvax,ucbvax,ihnp4,attmail)!vax135!cjp "The road to Hell is paved with good opinions."
keithd@cadovax.UUCP (Keith Doyle) (05/31/87)
In article <8705290639.AA04316@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >There is no competition to speak of between LIVE and DigiView; Except possibly in software. The DigiView software is excellent, the latest version has all kinds of great features, dithering, setting a fixed pallete, adjusting colors, number of bits/pixel, all kinds of stuff. The only thing I've heard from A-Squared is they don't want to get into the software business, sounded like an excuse to deliver hardware with minimum software. I've seen reasonable quality frame-capture with DigiView from still framed video, though *my* VCR isn't very good at it. A new version is supposed to be even better. Unless Amiga-Live! has software of the quality of DPaint II and DigiView, I wouldn't even begin to consider buying it instead of OR in addition to DigiView. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa Contel Business Systems 213-323-8170
hatcher@INGRES.BERKELEY.EDU.UUCP (06/03/87)
In article <1574@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: In article <8705290639.AA04316@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >>There is no competition to speak of between LIVE and DigiView; >Except possibly in software. The DigiView software is excellent, [...] >The only thing I've heard from A-Squared is they don't want to get into >the software business, sounded like an excuse to deliver hardware with >minimum software. Good point...the DigiView software is more flexible. I don't fault A-Squared, however, because they *cannot* do in real time what DigiView does at leisure. And although you might wish for post-pass image processing for the LIVE, DigiView would *also* benefit. You see, although it is pretty nice as a sort of "camera control" software package (i.e. making various global changes to the image), it is definitely *not* what I would call a full fledged image processor. With DigiView I am constantly wanting to say "up the brightness and decrease the saturation right *here* in this region only", but you can't do that. It's full screen or nothing. So I am interested in some reasonable image processing tools that are currently unavailable from any source whatever (e.g. Dpaint lacks the controls that DigiView has, otherwise I could use it to process regions; *everything* lacks HAM mode editing, specifically including PRISM, which is a piece of junk, and that public domain package would be nice for certain things if it did more than just black and white; haven't tried Butcher but it got bad reviews). Of course, I'm still waiting for a good sound processing package, too (hint, hint!). >I've seen reasonable quality frame-capture with DigiView from still >framed video, though *my* VCR isn't very good at it. A new version is >supposed to be even better. Unless Amiga-Live! has software of the >quality of DPaint II and DigiView, I wouldn't even begin to consider >buying it instead of OR in addition to DigiView. Good point. I've done this with DigiView 2, and results *can* be excellent. But it is far more tedious than one might think for a long series of frames, and even my excellent-consumer-quality VHS VCR will sometimes glitch up, making it necessary to stop and restart the process, losing synchronization. I suspect that 8 millimeter decks or Super VHS might avoid this altogether (or even tuning mine more carefully), but still it says that it becomes difficult to do what LIVE does with ease (although at lower quality, as you point out). Also, what looks good on TV often looks really bad on the Amiga, which is what makes postprocessing so important. I wish DigiPaint were out... Bottom line is that although I agree with everything you said, I want to let everyone know that it is a question of what is important for your particular needs. If quality is paramount, then DigiView is best. If ease in recording a long series of frames is important, then LIVE is best. If all you care about is functionality, and you don't mind buying the best consumer VCR available, and don't mind considerable inconvenience and associated "wasted" time, then DigiView *does* win. And I'm happy with mine. But I'm still considering LIVE (if and when budget permits!) Doug Merritt ucbvax!ingres!hatcher hatcher@ingres.berkeley.EDU
scotty@l5comp.UUCP (Scott Turner) (06/04/87)
In article <8705290639.AA04316@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >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 A person at C-A wrote me an E-Mail pointing out the obvious (I really WAS dumb) I can't use my hard disk because I can't plug it in. :( LIVE takes over the expansion port thus I have to unplug my hard disk BEFORE I can plug in LIVE. And obviously, if my hard disk isn't plugged in I can't use it. Needless to say, the people at LIVE will have to pry my cold dead fingers from my hard disk. ;) Viva Digi-view. >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 SCSI can be VERY tolerant of timing AFTER the initial connection. Once the command is started you can literally send 1 byte per HOUR and the controller will sit there quite patiently waiting for enough bytes to come in to form a block. On the OTHER end of the spectrum, the OMTI 5100 controller, and many others, are QUITE happy to have data sent to them at rates above 1 byte every 800ns. Using a interface that "auto-acks", like the C-Ltd, all it takes, after the command is setup, is a single move.b to send the byte along to the hard disk. >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... On the bandwidth side of things... I've tuned scottdisk.device to where it does read at 42,500 bytes per second (diskperfa 32K buffer) but writes are still down at 17,500 bytes per second. Seems to be some heavy blockage in the write channel of amigadog. I think I've about reached the limits of what I can do with scottdisk.device and amigadog. I figure that "auto-ack" should allow scottdisk.device to punch up above 50,000 bytes per second on READ but it'll still be stuck down at 20,000 for writes. The figures given by diskperfa for VD0: are VERY enlightening if you know how to read them. VD0 was done as a device driver rather than as a HANDLER. Thus is has to go through ALL the same internal stuff that a hard disk driver has to go through. VD0 by it's very nature has no latency delays etc to slow it down. Thus it's timings reflect what amigadog is CAPABLE OF. ie we can't go any faster than VD0 thru the device interface. Thus VD0 sets an upper limit, like the speed of light, beyond which we can't go. Thus my challenge with scottdisk.device was to crowd the "Speed Of Dog" as closely as I could. I figured that VD0 was using a tightly coded move.B loop to move data to/from it. Thus to match the speed of VD0 I had to come as close to possible at matching this data movement rate. The biggest problem is drive rotational latency. Scottdisk.device was not being called often enough to read sequential sectors without getting caught by this dreaded delay. So I put in a track buffer. Bingo, I got a nice jump. Then I fiddled and found that a buffer size of 2k to 4k seemed about right. But now I was double handling the data. I have to move.B it from the hard disk and then move.B it from the track buffer when the dog wanted it. I couldn't do anything about the first move.B, not until I can get my first Excalibur built up that is :), but for the second I employed a little carnal dog knowledge. We all know how the dog LOVES keeping things on long word boundaries... Well it didn't let me down this time either. The buffer that the track buffer is moved in and out of is long word aligned. SO I used move.L for the track buffer movement. Ergo I'm now topped out at 42,500 for reads or about 2/3rds SOD. But I suspect that with my use of carnal knowledge I have just bumped SOD. ie VD0 could be recoded to use move.L's too. Arthur jr though is up above 100,000 bytes per second for BOTH read and write so there IS hope for high bandwidth hard disks. Even on slug four parallel port SCSI interfaces like I'm using to test bed all this. Some "features" I noticed with MOUNT as I worked on the above: 1. buffers=0 is a no-no for disk devices. The Amiga guru's with an addressing error at the first I/O request to the device. 2. buffers set to less than 5 is bad news too. Performance really takes a SERIOUS dive. To see what I mean try buffers=1. :) 3. MOUNT has no security check that the device loaded is the actual device. A quick example: if the named file in devs is called scottdisk.device but the name actually coded inside it is weirddisk.device MOUNT nor anything else will catch it. Result? Nasty system guru on first access to the device. Frankly I'm not all worked up over this one, but I thought I'd pass it along. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
cmcmanis@pepper.UUCP (06/05/87)
In article <279@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >Needless to say, the people at LIVE will have to pry my cold dead fingers from >my hard disk. ;) Viva Digi-view. And if you have a MicroBotics hard disk you have to unplug it to use Digi-View sigh. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
kim@amdahl.UUCP (06/07/87)
In article <20462@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > > And if you have a MicroBotics hard disk you have to unplug it to use Digi-View > sigh. Hmmmmm ... MicroBotics advertises that the parallel port "is duplicated for simultaneous use with your printer". I always assumed they had some kind of "pass-thru" for the parallel port's signals. Is this: 1. not correct 2. correct, but it doesn't work 3. they don't pass/replicate *all* the signals (like +5v) If #3, then couldn't you provide a small interface connector to supply waht's missing (again, assuming it's only things like +5v)? Just curious ... I've often wondered how their "daisy-chaining" works. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
cmcmanis@pepper.UUCP (06/07/87)
In article <8085@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >Hmmmmm ... MicroBotics advertises that the parallel port "is duplicated for >simultaneous use with your printer". They duplicate the *output* pins and don't provide +5. If you talk to the parallel port directly you lose. What bothers me is that if you have two drives you can only use one of the parallel ports. They provide a replacement parallel.device. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
grr@cbmvax.UUCP (06/07/87)
In article <8085@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: > In article <20462@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > > And if you have a MicroBotics hard disk you have to unplug it to use > >Digi-View sigh. > > Hmmmmm ... MicroBotics advertises that the parallel port "is duplicated for > simultaneous use with your printer". > I always assumed they had some kind of "pass-thru" for the parallel port's > signals. Is this: > 2. correct, but it doesn't work > 3. they don't pass/replicate *all* the signals (like +5v) > > Just curious ... I've often wondered how their "daisy-chaining" works. I'm not sure of the exact circuitry, but what they do is pass through the signals needed to operate a printer and use one of the infrequently used control lines to strobe the disk instead of the printer. Digiview has its own ideas of which control lines to use for what and isn't compatible. Life can be rough... You can only make one port swing so many ways and still be compatible with the basic least-common-denominator devices that the user may want to attach. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
daveh@cbmvax.UUCP (06/07/87)
in article <279@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) says: > The figures given by diskperfa for VD0: are VERY enlightening if you know how > to read them. VD0 was done as a device driver rather than as a HANDLER. Thus ^^^^^^^ > is has to go through ALL the same internal stuff that a hard disk driver has > to go through. VD0 by it's very nature has no latency delays etc to slow it > down. Thus it's timings reflect what amigadog is CAPABLE OF. ie we can't go ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > any faster than VD0 thru the device interface. Thus VD0 sets an upper limit, > like the speed of light, beyond which we can't go. Assuming that in your "amigadog" sentence above, you're actually claiming that VD0 reflects the maximum speed of the DOS, maybe you should re-read the first sentence. VD0 is probably very close to all that you can do with the generic FileSystem handler. It says practically nothing about what the DOS itself is capable of with a faster handler. A tightly coded version of RAM: would be a good guess at this. Something that can handle the specifics of the device could scream, in comparison. You could read/write more than 512 bytes at a time, use knowledge of track layout to take advantage of the natural track caching of the floppies or just to avoid disk seeking, etc. > Scott Turner -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" BIX : hazy "These are the days of miracle and wonder" -P. Simon