Black BElt Video
HIM
There has been some talk on the net about an expanded Video adapter from
BLACK BELT. Well, I gave them a call today and they are for real. developer
units are hoped for in January , and the commercial right after (the FCC).
They asked me as a favor to post the following.
Too bad it is so long, but Ill take the flames in light of how important
this thing could be to the Amiga community in general.
AND the fact that I have gotten 5-10 request for it a day for 3 days now.
***********************************************************************
****************************************************************************
"Perfume and leather baby , you and me together baby,
what good is living in paradise, if you don't let yourself once or twice."
-Tiffany
Kenneth J. Jamieson ---- THE BOSS at Xanadu Enterprises Inc.
UUCP: tr...@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1
Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568
****************************************************************************
-----
Club : AMIGA ZONE Sec: 2
Date : 12/21/89 21:20 Num: 58,633
Theme: HAM-E VIDEO UPGRADE
To : ALL By : CAPT*VIDEO
Title: BLACK BELT DEVICE
-----
Black Belt Systems is pleased to announce the forthcoming release of
our new HAM-E graphics system for all Amigas from the early a1000's, on
up to PAL version 2500/030's and all models in between. The HAM-E is
inexpensive, extremely compatible, and it offers more performance for
your dollar than any other graphics system for the Amiga.
We'll start at the top: The HAM-E provides you with two new graphics
modes in addition to all of the original ones you already have in a
standard Amiga - and it does so in an extremely compatable and
interference free manner.
*** REG Mode:
The first mode is 256 simultaneous colors from a palette of 16,777,216
colors (24 bits, 8 bits/gun). Resolutions available are 320x200,
320x400 (interlace), the normal overscan options both horizontally and
vertically, and equivalent PAL resolutions. Additional features include
the capability to color cycle any or all of the 256 color registers,
fully Genlockable, sliding/overlapping front-back screens, no CPU
overhead to maintain the image (unless you want to color cycle or
glow... and even then it's minimal), completely IFF compatible. You can
have 256 levels of grey scale in this mode if you are involved in image
processing and so on.
*** HAM-E Mode:
The second mode is the Extended HAM (Hold-And-Modify) mode. This mode
provides 236 24-bit color registers in four banks of 59, and full 18
bit HAM capability. You can have 262,144 colors on screen at one time
(in exactly the same way "standard" HAM allows you to have 4,096) and
instead of having 16 color registers available to enhance "fast-edge"
color changes, you have 236.... which are accurate to 24 bits (16
million colors).You use this just like you use HAM mode, but you get...
(1) More than a quarter-million more simultaneous colors than standard
HAM mode (or any "normal" Amiga mode) can provide;
(2) You have much better sharp edge color changes because you have 59
immediately available color registers you can use to load the R, G and
B guns with no delay or HAM artifacts to a precision of 24 bits (16
million colors);
(3) You have the ability to change anywhere in the picture to a new set
of 59 color registers - the cost is one pixel that does not change at
all from the previous pixel. Obvious "good" places to do that are at
the beginning of a scan line, or in an area of an image that is not
currently changing (say, the contour of a cheek). Remember, it only
takes one pixel and there is no processor overhead involved, no
interrupts, no blitter. It's all directly dependant on the pixel data
in the image.
The HAM-E mode is Genlockable; it exists on a sliding, front/back
standard Amiga screen; it's fully IFF compatible; and supports color
cycling of any of the 236 color registers, regardless of bank.
Resolutions available are 320x200, 320x400 (interlace), the normal
overscan options both horizontally and vertically, and equivalent PAL
resolutions.
Some General Information:
The HAM-E device attaches to any Amiga by simply plugging it into the
DB-23 connector that is the RGB port using a supplied cable, and then
plugging your monitor or genlock into the other DB-23 connector on the
HAM-E. Then you plug it's AC cord into a wall outlet. That's all there
is to installation; no need to change your system software in any way,
or to add libraries or devices.
At this point, you turn your Amiga back on, and use SuperView (or any
other show or slideshow utility that understands standard 640
resolution images) to view your first HAM-E images (supplied on a demo
disk from us). When you're not viewing an image that uses one of our
new modes, for instance, if the WorkBench(tm) is pulled halfway "over"
a new mode image, the normal screen (in this example, the WorkBench)
looks just as it usually does, and the portion of the new mode image
looks exactly as it should also.
The point we're making here is that the new mode images act exactly as
if they had been designed into the system from the very start of things.
One very important difference between the HAM-E product and other,
competing display adapters is that our images are maintained in the
Amiga's normal "chip" memory, and so you can use the blitter on them;
that means that animation and page flipping does not require the direct
attention of the CPU... a critical point for those of you using
standard animation utilities.
Something else worth noting at this point is that the output from the
HAM-E hardware is quality 24 bit RGB (or 12 bit when a normal Amiga
screen is showing, and only for the portion that is showing) rather
than composite video - composite is very difficult to process in many
ways, especially for studio work. You can always turn RGB into
composite or S-VHS, but not the reverse.
Some things to keep in mind:
The HAM-E works by operating on the video data coming out of the Amiga
RGB port. For this reason, in a system using a flicker-fixer (tm) the
new enhanced modes will not be visible on the flicker-fixer's output
monitor - only on a monitor connected to the HAM-E. This is a video
tool and as such does not at this time support deinterlacing. You can
always have both monitors attached, of course.
Think of the output port on the HAM-E hardware as if it were the DB-23
jack on the Amiga; all the same signals are there, on all the same
pins, and they work as they always have under the same conditions. For
this reason, external genlocks, composite and S-VHS adapters, and
monitors all will continue to function normally. It really is as if the
Amiga magically "grew" three great new video modes.
Here is a concise list of features for the HAM-E graphics enhancer:
* 256 thousand simultaneous colors on screen , HAM-E mode
* Up to 236 directly usable color registers in 8 bit HAM mode
* 256 simultaneous colors out of palette of 16 million, REG mode
* Complete "color cycling" capability for 59 or 236 color registers
* All color registers are 24 bit accurate (8 bits/color-gun)
* Both modes can be animated using standard anim type tools
* Both Modes are completely IFF compatible
* Both modes supported by existing show and slideshow tools
* Both modes may be overscanned horizontally or vertically
* Both modes may be interlace or non-interlace
* High rez menuing capability
* No "CPU" overhead involved in maintaining the image
* No "BLITTER" overhead involved in maintaining the image
* All normal Amiga modes pass thru unaffected
* Amiga modes are still Genlockable
* Both new modes are Genlockable
* Image memory is BLITTER and CPU accessable
* Screens are fully "vertical slide", "overlay" & "front/back".
* Works with ALL Amigas - a1000, 500, 2000, 2500, 2500/030, PAL, etc
* Attaches to Amiga RGB connecter only - no internal connections
* Quality RGB output - not composite
* Externally powered, no load on Amiga system
* FCC Approved
Best of all...
* Affordably priced - less than half the cost of other solutions
About support programs:
Currently, we have talked to Impulse (Silver), NewTek (Digipaint),
MicroIllusions (Photon Paint II), Electronic Arts (DPaint, Deluxe Photo
Lab) and ASDG (Professional ScanLab, ScanLab 100) about the HAM-E. All
were enthusiastic and interested, and all have already ordered units
from the developer run. Support has been promised for format conversion
for the various 24 bit file formats that are out there, and we have
barely scratched the surface as of yet.
We will be supporting the HAM-E directly with our AVT (Amiga Video
Terminal) product which is marketed by AEA corp.
We fully expect the sales of the HAM-E to positively explode as soon as
we make units available (Jan-Feb of 1990), and are planning production
accordingly. There is nothing available for the Amiga that even comes
close to the flexibility, compatability, and color resolution for
anywhere near the planned retail of this unit, which is in the $300.00
range (subject to change as we get a better handle on production costs,
of course).
Black Belt Systems - technical products for the Amiga Computer
398 Johnson Road, Glasgow, Montana, 59230
Voice and FAX: 406-367-5509, 8am to 5pm, MST.
---------------------------------------------------------------------
CAUTION!!! Getting Really Technical:
---------------------------------------------------------------------
By now, if you're a technical type, you may have picked up on the fact
that both of the new modes use an 8-bit word for each pixel. Also,
these pixels are maintained in the Amiga's chip memory, and not on (in)
the HAM-E device. It is well known that the maximum number of bitplanes
the Amiga can support is 6, and that must be in "lo-res", that is, at
the 320 pixel/line rate. All of this is true.
What we are doing is creating a "normal" 4 bitplane 640 pixel/line mode
of one type or another, interlace or non, overscan or non. Then, at the
RGB connector, as these pixels are emitted 1 at a time at a 640/line
rate, we combine each pair into a single 8 bit pixel, which the HAM-E
hardware then processes as appropriate for the mode it's currently in.
In the top scan line of the new-mode image, there resides a 16 pixel
long sequence at the beginning of the scan line. Recognizing this
sequence "triggers" the HAM-E hardware into one of it's two new modes.
We refer to this trigger data with a smile as the "Magic Cookie". Our
Cookie resides in the top line of the IFF image as data, so when
viewing images, the "show" software needs to do nothing in order to
display the image properly.
Once triggered, the HAM-E stays triggered until (1) vertical sync, (2)
a new code is enccountered, or (3) The Amiga emits color zero for more
than one entire scan line.
If you drag an new mode screen down, the trigger data is not
encountered until the top of the new mode screen is emitted - that
means that you can vertically drag the screens with normal results.
When an overlapping screen begins, several lines of color zero are
emitted, and this turns off the trigger - meaning that overlapping
screens switch immediately back into the correct mode. This is why the
value zero is reserved in the color register lookups... if you were to
have an entire line of this, the HAM-E would un-trigger. You may, if
you are careful, use the value zero, as long as there is some other
value somewhere on the scanline. This applies to both REG mode and
HAM-E mode.
On the line where the 16 pixel code resides (presumably the top line in
the image), there follows 384 pixels which contain the color register
information for the display, if it's REG or HAM-E. This data is
arranged as 64 sets of RGB triplets, each 8 bits wide. To load the
extra banks of 64 registers, you simply put a second, third, and fourth
trigger line at the top of the screen - each successive trigger line
loads another set of 64 color registers.
There are some interesting implications here. If there is only 1 new
mode screen active, you only need to do this once - the color register
rams are static, and will hold this data until new trigger lines are
encountered. If you have more than one new mode screen up, then you'll
need to maintain as many trigger lines as there are sets of color
registers being used.
In addition, in interlace, a trigger line is required for each field,
so two lines are required for 64 registers, and 8 for 256. An
interesting thing to note here is that the color registers for the odd
and even fields can be different, and so you have 472 24-bit color
registers you can work with. This goes for REG mode as well, of course;
in interlace, the odd field has it's own set of 236 registers, as does
the even field.
We do not take our pixel information from the Amiga on the linear RGB
lines. Instead, we use the IRGB lines. New Mode images must have a
particular set of values loaded into the Amiga color registers, so that
the IRGB lines will set themselves to 16 discrete states. This is no
hardship, as the Amiga color registers are otherwise unused for the
duration of a new mode image.
False triggering is extremely unlikely. First of all, the trigger data
is 16 pixels, or 64 bits, long. That means there is a one in 1.8 to the
19th power chance of hitting it accidentally. But that's not all.
because we take our data from the IRGB lines, the Amiga's color
registers must also be set to values that create 16 discrete
combinations on the IRGB pins - the number of color combinations that
do this are a very limited set of those you can create. Next, the data
rate coming from the Amiga must be 640, and there must be 4 bitplanes
because otherwise you can only make 8 (or less) color combinations. So
an "accidental" trigger can only happen in a 640 rate screen with a
particular (Amiga) color palette and a particular sequence of data in
the first 16 pixels. It's very, very safe.
Here is a general diagram of how the HAM-E mode compares against the
standard HAM mode; it may help clarify things for you.
Standard 6-bit HAM works like this:
00xxxx - the 4 x's pick a color register - R, G and B load up.
01xxxx - the 4 x's go to the red gun for this pixel.
10xxxx - the 4 x's go to the green gun for this pixel.
11xxxx - the 4 x's go to the blue gun for this pixel.
HAM-E uses an 8-bit data word, and works like this:
00xxxxxx - the 6 x's pick a color register, 1-59 are valid #'s,
the color registers load 24 bits of data, 8 bits
per RGB gun - accuracy is 16 million colors.
00111100 - Select bank 0 of color registers - no gun changes
00111101 - Select bank 1 of color registers - no gun changes
00111110 - Select bank 2 of color registers - no gun changes
00111111 - Select bank 3 of color registers - no gun changes
01xxxxxx - the 6 x's go to the most significant 6 bits of the
red gun for this pixel - the least sig two bits are
zeros..
10xxxxxx - the 6 x's go to the most significant 6 bits of the
green gun for this pixel - the least sig two bits are
zeros..
11xxxxxx - the 6 x's go to the most significant 6 bits of the
blue gun for this pixel - the least sig two bits are
zeros..
Let's sum up: Let's say you use SuperView (a standard show utility) on
a newmode formatted IFF image. First, the IFF image data represents a
four bitplane image, with a particular set of color registers. The data
for the first 1 to 4 scan lines will contain the Magic Cookie, followed
by data for 64 color registers. The rest of the image body will contain
scan lines formatted as four bitplanes, each bitplane arranged as 320
pairs of bits per scan line. When this is displayed by SuperView, the
line containing the first Magic Cookie triggers the HAM-E hardware and
it then loads the color registers from the rest of the trigger line. If
there are succeeding trigger lines (up to 4), it loads more sets of 64
color registers. Any line that is encountered that does not have a
trigger in it is processed according to the mode selected by the Magic
Cookie type (There are two types, one for each mode). If the WorkBench
is visible, say it's pulled up over the bottom third of the image, then
the HAM-E system un-triggers when it see's the presence of the c0
(Color zero) bit for longer than one scan line.
************************************************************************
The above came from a local BBS...the Amiga Blue BBS (804) 748-9853
Kermit // Capt*Video
Larry Phillips
>There has been some talk on the net about an expanded Video adapter from
>BLACK BELT. Well, I gave them a call today and they are for real. developer
>units are hoped for in January , and the commercial right after (the FCC).
>
>
>Currently, we have talked to Impulse (Silver), NewTek (Digipaint),
>MicroIllusions (Photon Paint II), Electronic Arts (DPaint, Deluxe Photo
>Lab) and ASDG (Professional ScanLab, ScanLab 100) about the HAM-E. All
>were enthusiastic and interested, and all have already ordered units
>from the developer run. Support has been promised for format conversion
>for the various 24 bit file formats that are out there, and we have
>barely scratched the surface as of yet.
Ben Williams, designer of the HAM-E board, and VP/Engineering of Black Belt,
has posted a correction to the above on Compuserve. I asked him if he'd like
to have the posting here corrected, and he said yes, so here it is.
NewTek has changed their mind about supporting the HAM-E product, giving the
reason as (paraphrased) "we have been working on a similar board for some time
now". This change of heart came about two weeks after they received the specs
on HAM-E and expressed interest in supporting the Black Belt product.
Because of the discussion that ensued on Compuserve in response to this news,
and because of NewTek's reaction to same, both by telephone, email, and public
messages, I feel that I am forced to include here, the following statement:
Disclaimer: I am repeating the gist of the messages, one from Ben Williams, one
from Tim Jenison of Newtek, that were posted in the public message base on
Compuserve's Amigatech forum. I have no business affiliation with Black Belt
Systems, newTek, Ben Williams, or Tim Jenison, and I refuse to enter into any
public discussion of the possible motives of either company or the people who
represent them.
-larry
--
"Cavett Emptor - Let the talk show host beware!" - Evan Marcus
+-----------------------------------------------------------------------+
| // Larry Phillips |
| \X/ lphi...@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
| COMPUSERVE: 76703,4322 -or- 76703...@compuserve.com |
+-----------------------------------------------------------------------+
Adam Kao
I thought the rumors were totally bogus, but these guys really know
what they're doing!! AND IT'S NOT EVEN A KLUDGE! (imho)
I want to give these people a million thanks and three hundred bucks!
Adam
PS does anyone know why the limits are 59 and 236 instead of 64 and 256?
HIM
I am more inpressed with the elegance of the solution the more I reflect on
it.
In addition , th info in the article is sufficienbt that I have already
begun an output converter for 24bit Progressive Peripherials Framegrabber
files to the new IFF format.
Gary Oberbrunner
because a few of the other slots are used to change to shadow banks of
color registers, giving you even more flexibility (but it's going to be
real interesting to write optimal HAM encoding s/w for the beast!) It's
just too bad that it only supports 320-wide (lo-res) images, but that's
about all you can do without getting into external frame buffers and
that'll up the cost severely. A fine box, from what I've heard. Count me
in.
- Gary Oberbrunner
Thinking Machines Corporation
245 First St
Cambridge, MA 02142
ga...@think.com
--
As always,
Gary O
-----------------------------------------------------------------------------
Remember, Truth is not beauty; Gary Oberbrunner
Information is not knowledge; Beauty is not love; {ames,harvard}!think!garyo
Knowledge is not wisdom; Love is not music; ga...@think.com
Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265
Robert J. Kudla
>just too bad that it only supports 320-wide (lo-res) images, but
>that's about all you can do without getting into external frame
>buffers and that'll up the cost severely. A fine box, from what I've
>heard. Count me in.
Count me out... I'll wait for NewTek's box. Maybe it'll support the
Flicker Fixer. But, even the Black Belt is closer to what I personally
want than the ECS will be, so I can't really complain.
(By the way... seeing as how the idea of the box is to not require any
other special hardware or graphics drivers, and it depends on the
Amiga's maximum horizontal resolution to be able to double down the 4
bit pixels into 8, to have a 640-wide HAM-E mode would require
defeating its own purpose.....)
--
Robert Jude Kudla <ku...@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Anderson
Neil Weinstock
>>just too bad that it only supports 320-wide (lo-res) images, but
>>that's about all you can do without getting into external frame
>>buffers and that'll up the cost severely. A fine box, from what I've
>>heard. Count me in.
>
>Count me out... I'll wait for NewTek's box. Maybe it'll support the
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA!!!!!!!!!!!!!!!!!!!
Hoooey, that was a good one.
________________ __________________ _________________________
//// \\// \\// \\\\
\\\\ Neil Weinstock //\\ att!cord!nsw or //\\ "Your hair is so... ////
//// AT&T Bell Labs \\// n...@cord.att.com \\// lustre-laden." - Moss \\\\
\\\\________________//\\__________________//\\_________________________////
Don White
>In <25a12198:3611comp....@tronsbox.UUCP>, tr...@tronsbox.UUCP (HIM) writes:
>>There has been some talk on the net about an expanded Video adapter from
>>BLACK BELT. Well, I gave them a call today and they are for real. developer
>>units are hoped for in January , and the commercial right after (the FCC).
>>
>> [ lengthy specs deleted ... ]
>>
>>Currently, we have talked to Impulse (Silver), NewTek (Digipaint),
>>MicroIllusions (Photon Paint II), Electronic Arts (DPaint, Deluxe Photo
>>Lab) and ASDG (Professional ScanLab, ScanLab 100) about the HAM-E. All
>>were enthusiastic and interested, and all have already ordered units
>>from the developer run. Support has been promised for format conversion
>>for the various 24 bit file formats that are out there, and we have
>>barely scratched the surface as of yet.
>
>Ben Williams, designer of the HAM-E board, and VP/Engineering of Black Belt,
>has posted a correction to the above on Compuserve. I asked him if he'd like
>to have the posting here corrected, and he said yes, so here it is.
>
>NewTek has changed their mind about supporting the HAM-E product, giving the
>reason as (paraphrased) "we have been working on a similar board for some time
>now". This change of heart came about two weeks after they received the specs
>on HAM-E and expressed interest in supporting the Black Belt product.
>
This is interesting. About two years ago, I had a talk with Tim Jennison.
I had a HAM paint program started. Since NewTek only had Digi-View and no
hint of a paint program, I decided to run it by Mr. Jennison. In our
conversation, I said that I had this program that would be an excellent
complement to thier only current product. (i.e. Digi-View). All I needed
was information about the format of their pictures both the old format
which was just a bitmap dump and the newer IFF stuff. Tims' response
was that HAM was far too slow for a paint program and if I wanted to
pursue it I should bug Electronic Arts. It's a heck of a coincidence that
about seven months later they came out with Digi-Paint. Hmmmm.
Now, it appears that they were given specs and came across with positive
statements about HAM-E then two weeks later announced that they had 'been
working on a simialar board for some time now'?
I may not understand the situation clearly, but it sounds prudent not
to include Mr Jennison in conversations about new products.
Don White
Box 271177 Concord, CA. 94527-1177
zehntel!donw
sullivan - segall
Registers 60,61,62,63 invoke a change to a new register set (0, 1, 2, 3).
They could have cheated and used 60 registers per bank, but that would mean
that you couldn't select bank 0, if bank 0 were already selected. That
would be bad news considering that you might not know which bank was selected
at the beginning of the page.
-ss
sullivan - segall
>>just too bad that it only supports 320-wide (lo-res) images, but
>>that's about all you can do without getting into external frame
>>buffers and that'll up the cost severely. A fine box, from what I've
>>heard. Count me in.
>
>Count me out... I'll wait for NewTek's box. Maybe it'll support the
>Flicker Fixer. But, even the Black Belt is closer to what I personally
>want than the ECS will be, so I can't really complain.
>
long that I'd buy just about anything *but* a video toaster. In effect
it stops development in the industry by getting weak minded buyers such
as yourself to wait 4 years for a nonexistant product while real developers
can't get people to purchase their own *real* products. Btw: ever notice
how the price of the toaster has changed over the years?
-ss
Robert J. Kudla
From: n...@cbnewsm.ATT.COM (Neil Weinstock)
>Count me out... I'll wait for NewTek's box. Maybe it'll support the
^^^^^^^^^^^^^^^^^^^^^^^^^^
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA!!!!!!!!!!!!!!!!!!!
Hoooey, that was a good one.
OK, to wait for Newtek to release a new product is sort of like
waiting for Kate Bush to release an album, but to me, flickerfixing is
more important than this 24-bit kludge. (Elegant as it is.) Since it
presently doesn't work with a flickerfixer, it presently is no
candidate for inclusion into my system (not that I have a flickerfixer
just now either... I have a 500).
Which reminds me- Why hasn't anyone come out with a box similar to
this one that buffers alternating lines from an interlaced screen and
sends 'em out noninterlaced to a Multisync monitor? Sure, the frame
rate would kind of suck, but it seems an obvious and semi-easy
hardwarewise way to de-interlace Amiga screens on the way out.
Robert J. Kudla
NewTek's box (ie: The Video Toaster) has been about to be released for so
long that I'd buy just about anything *but* a video toaster. In effect
it stops development in the industry by getting weak minded buyers such
as yourself to wait 4 years for a nonexistant product while real developers
can't get people to purchase their own *real* products. Btw: ever notice
how the price of the toaster has changed over the years?
Yes, it's gotten progressively more expensive. It doesn't matter; I've
never been in the market for one of those. What I want (and what the
early rumors of ECS had told me they were going to be like) is (1)
noninterlaced 640x400 with color specs as they are now for interlaced
640x400 and (2) 24-bit color a'la the Mac II. The former can be done
with Flicker Fixer; the latter can be done with Black Belt. Both
cannot be used together, though, and thus Black Belt is not of use to
me. Yes, NewTek has a habit of making mondo vaporware, but when I said
I'll wait for NewTek it meant that at least there was a possibility
that their product might support de-interlacing.
Michael Portuesi
>>>>> On 8 Jan 90 00:04:40 GMT, ku...@pawl.rpi.edu (Robert J. Kudla) said:
robert> OK, to wait for Newtek to release a new product is sort of like
robert> waiting for Kate Bush to release an album, but to me, flickerfixing is
robert> more important than this 24-bit kludge. (Elegant as it is.)
Same here. I would much rather see the Black Belt capabilities in
improved Amiga chip set or other sanctioned Commodore upgrade, rather
than an add-on device that is not likely to win universal software
support. At least deinterlacing can be done in a software transparent
matter, and is much less of an upgrade/compatibility issue
robert> Which reminds me- Why hasn't anyone come out with a box similar to
robert> this one that buffers alternating lines from an interlaced screen and
robert> sends 'em out noninterlaced to a Multisync monitor?
Because at that point the signals are analog, not digital. You would
need to sample the output digitally, then store the results in a frame
buffer. Apparently the Black Belt device does this, but it doesn't
try to solve the deinterlacing problem.
--M
--
__
\/ Michael Portuesi Silicon Graphics Computer Systems, Inc.
port...@SGI.COM Entry Systems Division -- Engineering
Blair MacIntyre
>this one that buffers alternating lines from an interlaced screen and
>sends 'em out noninterlaced to a Multisync monitor? Sure, the frame
>rate would kind of suck, but it seems an obvious and semi-easy
>hardwarewise way to de-interlace Amiga screens on the way out.
Well, for one, it would be more expensive due to the ram required for
buffering.
But heck, why stop there? Why not allow up to 6 frames to be buffered
and allow a 1280x600 screen? Or a 640x600 in this neato 24bit mode?
:-)
--
-- Blair MacIntyre, Professional Leech on Society ( aka CS Graduate Student )
-- bmacintyre@{watcgl, watdragon, violet}.{waterloo.edu, UWaterloo.ca}
-- Date, verb: prearranged socializing with intent.
Darren New
>But heck, why stop there? Why not allow up to 6 frames to be buffered
>and allow a 1280x600 screen? Or a 640x600 in this neato 24bit mode?
Isn't this already done? I thought this was the way hedley (sp?) mode works.
-- Darren
HIM
>>has posted a correction to the above on Compuserve. I asked him if he'd like
>>to have the posting here corrected, and he said yes, so here it is.
>>NewTek has changed their mind about supporting the HAM-E product, giving the
>>reason as (paraphrased) "we have been working on a similar board for some
>>time
> Now, it appears that they were given specs and came across with positive
> statements about HAM-E then two weeks later announced that they had 'been
> working on a simialar board for some time now'?
Yup .. that sounds like New-Tek!!!
Hehehe -- its too bad because when I spoke with the guy at B-Belt , he said
that they DELIBERATELY put enough infor in the announcment that someone on
the ball could reverse-engineer it so that no one would think it was a hoax.
Further he said that it would give THEM (BB) a little kick in the but to
have the competition!
And now a company like New-Tek is gonna try and steal it ...
Jeeez ..
****************************************************************************
Everything I say is (c) 1990, except the stuff I stole from someone else
and the stuff I don't want responsibility for.
Kenneth J. Jamieson: Xanadu Enterprises Inc. "Professional Amiga Software"
c60a...@web-4b.berkeley.edu
Firstly, I would like to thank you people for commenting on the Power
Window 2.5. From all the comments, I gathered that it is quite a good
investment to get a copy of it since it will save me a lot of time and
effort to build a user interface. However, one of you pointed out
that the code generation could be buggy at times. Anyway, it's still better to
rectify the code than to start everything from scratch.
I will place the order tomorrow...
Thanks guys.
Johnson
Jamie Purdon
> This is interesting. About two years ago, I had a talk
> with Tim Jennison. I had a HAM paint program started.
> Since NewTek only had Digi-View and no hint of a paint
> program, I decided to run it by Mr. Jennison. In our
> conversation, I said that I had this program that would be
> an excellent complement to thier only current product.
> (i.e. Digi-View). All I needed was information about the
> format of their pictures both the old format which was just
> a bitmap dump and the newer IFF stuff. Tims' response was
> that HAM was far too slow for a paint program and if I
> wanted to pursue it I should bug Electronic Arts. It's a
> heck of a coincidence that about seven months later they
> came out with Digi-Paint. Hmmmm.
Yes, this IS interesting. (BTW: Didn't you mean THREE years ago?)
Now please consider the following:
The spring of 1986 was when I first saw DigiView. I went to a local
(is "in the next county" local?) Amiga dealer's for a demonstration.
I was impressed. I bought a disk (remember when dealers would sell
just *one* floppy?) and saved rgb file samples and some HAM pictures
to try on my new "ham editor" (paint program).
In June (or was it July?) of 1986, I talked with Tim Jennison about
marketting my paint program. He turned me down. But that didn't stop
me from finishing my effort. I split my time between finishing the
code and organizing a (self) marketting effort. You may even have
seen my advertisement for a program named HamBone. It was in Amazing
Computing, (1986) Volume 1 Number 8 on page 39.
Months later, in early-September, Tim Jennison called me back. By the
end of the month, we had worked out a mutually agreeable arrangement
for development and marketting. I don't know what one thing convinced
him to reconsider selling my program for me. It could have been any
of a number of things. As I (also) recall, he had grave doubts as to
the speed potential of any code written to use HAM mode. However, he
did see a working demo of my program.
(After my agreement with NewTek, I cancelled all arrangements for
HamBone marketting. The Amazing advertisement shouldn't have been run
- a deadline was missed. In any case, "HamBone" is no longer
available.)
One of my points is: DigiPaint is *my program*. I was working hard
on this product before NewTek became involved. Most of the original
version, and all of DigiPaint3, was coded entirely by me. The
internal algorithms were all designed by me, Tim should get credit for
the graphical user interface. Steve Kell (NewTek) helped with the
original version's coding. Steve Speier (NewTek) helped with debugging
DigiPaint3. I do not know Don White, nor do I think I ever talked to
a Don White about a paint program. I resent Don White's "gee what a
coincidence" implications.
> Now, it appears that they were given specs and came
> across with positive statements about HAM-E then two weeks
> later announced that they had 'been working on a simialar
> board for some time now'?
So what? Why not consider "similar board" to mean "video adapter" and
leave it at that? I've been working with NewTek for over three years.
We take great pains to NOT use other peoples' ideas. If/When NewTek's
"similar board" should go on the market you'll find that it is very
different from (and probably much more elegant than) the HAM-E design.
Why should NewTek tell anyone about their designs or research? I
consider BlackBelt quite lucky to have found out that NewTek is even
working on something similar.
> I may not understand the situation clearly, but it sounds
> prudent not to include Mr Jennison in conversations about
> new products.
Again, I resent your implication. I'd suggest the opposite: If
you're working on an idea that's "up NewTek's alley" - then by all
means contact them. (Although this does sound like a sneaky way to
try to find out what they're currently researching..;-)
Jamie Purdon
DigiPaint Author
Blair MacIntyre
Sort of ... the short answer is yes. But, the neat thing is that if
you made a box like the Black Belt thing, you could have something which
is totally separate to
a) the version of the Amiga
b) the monitor
The implications are interesting. For example, have the thing do nothing
more than collect quadrants for the frame buffer, but in color. You
could output color or black and white. Etc etc ...
Sound cool?
John Sparks
>> Now, it appears that they were given specs and came across with positive
>> statements about HAM-E then two weeks later announced that they had 'been
>> working on a simialar board for some time now'?
>Yup .. that sounds like New-Tek!!!
>And now a company like New-Tek is gonna try and steal it ...
>Jeeez ..
If Black Belt is smart, they have patented the box, and if NewTek comes out
with one too similar, they can sue them.
The only problem is that NewTek will probably come out with a box that is
sufficiently different as to not be a patent infringment. Or incorporate
Black Belts HAME ideas into their video toaster (now we can wait another year
for it).
And since
NewTek already has a reputation for graphics, digitizing, and has several
products out in the market that they can make to work with their box,
they are probably going to steal Black Belts market share.
Too bad. It's dirty pool IMHO. big business, blech!
--
John Sparks | D.I.S.K. 24hrs 1200bps. Accessable via Starlink (Louisville KY)
spa...@corpane.UUCP <><><><><><><><><><><> D.I.S.K. ph:502/968-5401 thru -5406
Take my advice... I'm not using it :-)
Bill Cavanaugh
> long that I'd buy just about anything *but* a video toaster. In effect
> it stops development in the industry by getting weak minded buyers such
> as yourself to wait 4 years for a nonexistant product while real developers
> can't get people to purchase their own *real* products. Btw: ever notice
> how the price of the toaster has changed over the years?
FYI, Newtek's set up a conference on BIX devoted to the Toaster... As of
last
night it was empty, but it shows that >>something's<< happening...
uunet!tronsbox!bleys bcavanaugh on BIX...
"The perversity of the universe tends to a maximum"
Finagle's First Law
Bill Squier
Over the last few days there has been some discussion as to whether
NewTek has or hasn't decided to steal Black Belt's HAM-E, and whether or
not they'll steal their market share. I think everyone's missing
something pretty fundamental. You see, no one has to worry about
NewTek, they never release ANYTHING they say they will. ;-)
--
Bill Squier - Stevens Inst. of Tech | // "Only Amiga makes it possible"
Bitnet: u93_wsquier@stevens | \X/
Internet: u93_w...@vaxc.stevens-tech.edu
Temporary Inet (Please use until Jan. 13): ...uunet!tronsbox!dsoft!groo
Mark Vange
> This is awesome! Brilliant! Really, really good!
> PS does anyone know why the limits are 59 and 236 instead of 64 and 256?
Probably because they don't want a lot of zero data running around (it would
switch off their special mode if, say, you had a line which relied
completely on 0'th registers) That doesn't explain it entirely, but there
may be some reserved bit in there as well.
--
Mark Vange ...uunet!mnetor!yunexus!xrtll!mark
PAS Systems - "Plain and Simple" Ph#:(416) 730-1352 mark@xrtll
8 Everingham Ct. North York "Every absurdity has a champion
Ont, Canada M2M 2J5 to defend it." - Oliver Goldsmith