Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mfci!m3!genly
From: genly@bubble.multiflow.COM (Chris Hind Genly)
Newsgroups: comp.sys.amiga
Subject: Black Belt Video
Message-ID: <1182@m3.mfci.UUCP>
Date: 10 Jan 90 18:09:34 GMT
Sender: news@mfci.UUCP
Distribution: comp
Organization: Multiflow Computer Inc., Branford CT
Lines: 89


I'm posting these for Ben Williams of Black Belt systems.  He does not
have direct access to usenet.

======================================================================

In reply to Michal Portuesi:

We do not sample the analog signals at the RGB port at any time.

We _do_ pass them on, if we're not in one of our modes, but we 
never ever mess with them.

Ben

Amateur Radio Callsign is A A 7 A S


----------------------------------------------------------------------

To Wayne Knapp:

I would like to point out some errors in your thinking.

In hi-res, at a rate of 640 pixels/line, at 4 bits/pixel, you 
will find that there are 320 bytes per line, assuming no overscan.

We utilize 16 pixels as the cookie, which leaves quite a bit 
of data bandwidth (per line) left over.

On each line, we load 64 color registers - that means that at 
most, there would be four scan lines involved as register loads 
in non-interlaced, and 8 in interlaced _if_ both the odd and 
even fields are utilized for register loading.

As for having hardware to loan to people, you have to realize 
where we are in the development cycle - when we have hardware, 
we'll make it available.

Black Belt has a number of Amiga products it has already produced, 
including hardware with FCC approval and a great deal more complexity 
than this box... we know what we are doing, and intend to put 
out just what we say we are.

You are, of course, entitled to your opinions... but at least, 
if you're going to try and take technical pot shots, do your 
math right, ok? :*)

Ben

Amateur Radio Callsign is A A 7 A S


----------------------------------------------------------------------

In reply to Ed Hanway:

Your comments are both 100% on the mark - sprites are not happy 
in the HAM-E mode, though they act nicely in the REG mode.

The menu rez change can happen just as you describe it; we do 
like to call it a feature, since in normal HAM mode, menus mess 
up the image. Here, you have the same effect, but for your pain, 
you get hi-res Menus, which provide a denser menu structure. 
You can avoid this (if you want) but putting the cookie over 
the menu bar region.

Likewise, you can avoid the pointer kicking you out of a new 
mode by turning off the pointer based on it's position. Without 
this kind of minimal support, though, you will be able to produce 
artifacts.

We believe that for video use, animations, painting, and the 
like, that this is of little consequence... and since no one 
has any software that assumes sprites work here as far as applications 
go, we see no impending problems.

It looks like I'm going to have to figure out how to get on USENET... 
you guys are sure prolific. :*)

Ben

Amateur Radio Callsign is A A 7 A S

--
=======================================================================
Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090