tron1@tronsbox.UUCP (HIM) (01/03/90)
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: tron1@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*Videolphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/03/90)
In <25a12198:3611comp.sys.amiga@tronsbox.UUCP>, tron1@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. 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/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
chekmate@athena.mit.edu (Adam Kao) (01/04/90)
This is awesome! Brilliant! Really, really good! 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?
tron1@tronsbox.UUCP (HIM) (01/05/90)
>This is awesome! Brilliant! Really, really good!
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.
****************************************************************************
"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: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1
Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568
****************************************************************************garyo@prometheus.think.com (Gary Oberbrunner) (01/05/90)
This Black Belt thing does look pretty cool. The limits are 59 and 236
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
garyo@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; garyo@think.com
Wisdom is not truth; Music is the best. - FZ (617) 876-1111 x265kudla@pawl.rpi.edu (Robert J. Kudla) (01/05/90)
>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 <kudla@pawl.rpi.edu> "Famous? I'm not famous. People come up to me after a show and say 'Hey, Steve!'" -Jon Anderson
nsw@cbnewsm.ATT.COM (Neil Weinstock) (01/06/90)
In article <KQJ2{_@rpi.edu> kudla@pawl.rpi.edu (Robert J. Kudla) writes: >>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 \\// nsw@cord.att.com \\// lustre-laden." - Moss \\\\ \\\\________________//\\__________________//\\_________________________////
donw@zehntel.zehntel.com (Don White) (01/06/90)
In article <973@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <25a12198:3611comp.sys.amiga@tronsbox.UUCP>, tron1@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
bartonr@jove.cs.pdx.edu (Robert Barton) (01/06/90)
tron1@tronsbox.UUCP (HIM) writes: > 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. I didn't see any mention of a new IFF format. They claimed that it was IFF-compatible; presumably they actually meant to say ILBM-compatible. From the description given however this is not the case. Using parts of the BODY chunk for purposes other than bit-plane data makes it incompatible.
Sullivan@cup.portal.com (sullivan - segall) (01/07/90)
>This is awesome! Brilliant! Really, really good! >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? 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@cup.portal.com (sullivan - segall) (01/07/90)
> >>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. > 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? -ss
kudla@pawl.rpi.edu (Robert J. Kudla) (01/08/90)
From: nsw@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 Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonkudla@pawl.rpi.edu (Robert J. Kudla) (01/08/90)
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.
--
Robert Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonportuesi@tweezers.esd.sgi.com (Michael Portuesi) (01/08/90)
>>>>> On 8 Jan 90 00:04:40 GMT, kudla@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.
portuesi@SGI.COM Entry Systems Division -- Engineeringbmacintyre@watdragon.waterloo.edu (Blair MacIntyre) (01/09/90)
kudla@pawl.rpi.edu (Robert J. Kudla) writes: >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. 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.
new@udel.edu (Darren New) (01/09/90)
In article <19596@watdragon.waterloo.edu> bmacintyre@watdragon.waterloo.edu (Blair MacIntyre) writes: >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
tron1@tronsbox.UUCP (HIM) (01/09/90)
>>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, 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" UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
tron1@tronsbox.UUCP (HIM) (01/09/90)
>Author: [==> Robert Barton <==] > Subj: Black Belt Video > I didn't see any mention of a new IFF format. They claimed that it was >IFF-compatible; presumably they actually meant to say ILBM-compatible. From >the description given however this is not the case. Using parts of the BODY >chunk for purposes other than bit-plane data makes it incompatible. > I should have expressed myself better . There does NOT have to be a new IFF format . NON-BB Amigas will see a perfectly normal 640x400 IFF with some funny colors on it so there is NO incompatoibility. BUT , for the sake of consistensy , I am hoping to impliment a new IFF chunk type to support the board when I get one. **************************************************************************** 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" UUCP: tron1@tronsbox.UUCP BEST PATH ---> uunet!tronsbox!tron1 Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 ****************************************************************************
jamiep@NCoast.ORG (Jamie Purdon) (01/09/90)
> 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
bmacintyre@watdragon.waterloo.edu (Blair MacIntyre) (01/09/90)
new@udel.edu (Darren New) writes: >In article <19596@watdragon.waterloo.edu> bmacintyre@watdragon.waterloo.edu (Blair MacIntyre) writes: >>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 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? -- -- Blair MacIntyre, Professional Leech on Society ( aka CS Graduate Student ) -- bmacintyre@{watcgl, watdragon, violet}.{waterloo.edu, UWaterloo.ca} -- Date, verb: prearranged socializing with intent.
sparks@corpane.UUCP (John Sparks) (01/10/90)
tron1@tronsbox.UUCP (HIM) writes: >> 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) sparks@corpane.UUCP <><><><><><><><><><><> D.I.S.K. ph:502/968-5401 thru -5406 Take my advice... I'm not using it :-)
genly@bubble.multiflow.COM (Chris Hind Genly) (01/11/90)
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
waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) (01/11/90)
> I'm posting these for Ben Williams of Black Belt systems. He does not > usenet access. > To Wayne Knapp: > ... > We utilize 16 pixels as the cookie, which leaves quite a bit > of data bandwidth (per line) left over. > ... Yes I realise my error and that you only use 8 lines vs. the 24 lines I though (in the interlace mode). I already acknowledge my error your posting is late. Still there is a very real bandwidth problem when it come to doing real-time playback of animation in the Black Belt modes. The problem has nothing to do with the Black Belt box or the Black Belt data. The problem is that the Amiga is a dog in 16 color medium or 16 color high res.. Most programs run great in low or lace res. no matter the number of colors, but animation and real-time graphics programs really suffer in high res.. Most of the nice animtions so far have been done in low, lace or HAM modes. Often the Amiga is pushed to the limit to get 15 frames a second out. In the high res. modes there is a limited amount of time the processor can access the CHIP RAM. From my programming I've seen about a 60% reduction in graphics speed in high res. as compared to low res.. So this will make real-time animation hard to do or at least limited. ( Note: not only is there less time to update the CHIP RAM in high res. but there is also upto 4 times as much information to change. The speed can be a little better without overscan). Single-frame recording is always an option. The low resolution animation will look really nice, but if one has enough money to do single-framing why mess with a kludge solution like this anyway? Note I think that outside of animation uses the box will be nice. > 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. > I responding to what I was told by someone who called you directly in reguards to getting the box to use. He has access to several programs that are currently selling well as far as Amiga software goes and he could add enhancements to support the Black Belt box. However he was told that there are no price breaks for developers, that basicly Black Belt was too small of a company to try and support developers so they would just have to pay the $300 and wait for a box. Now you say you have other Amiga products out and I've never even heard of you before. Yet you except us developers to take a lot of time to change our code for this box. I say go jump in a lake and let the cold water wake you up. As far as I know I'm the only person that has a compressed 24bit file format that works well on the Amiga and it isn't released yet. Programs that produce 24bit color on the Amiga are far and few inbetween. It seems to be that 32 color programs are going to take a lot of work before there will really use this box well. I bet it will take a mouth to get a program like DPaint III all set up for the Black Belt mode. There are requestors, fonts, low level screen IO, blitter rountines, possible pointer problems, IFF changes and who know what else. It could be a big job. Then if you sell a few thousand of your boxes and a few hunderd of those people buy updates to the code the programer might break even. Seems like the programer is the guy who is most likely to lose in this deal. No Thanks! Maybe new code will support this box but I won't be updating my old code very soon. > 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 > Hey if you are going to flame me at least get yourself current with the news! I wasn't taking technical pot shots at your I was listing valid concerns I had about the Black Belt box and animation. Yes some of my math was in error (I don't know what I was thinking) but I think I listed valid conerns that deserve a reasonable response. However I will take a pot shot at you now. In the posting about how the Black Belt video works (a really nice posting by the way) there is detail about the 8 bit HAM mode. The posting states that over 260,000 colors are possible on screen. Well isn't that a bit hard with less than 40,000 pixels. (Should say something like > 30,000 colors out of 260,000 possible). Maybe we should all watch our math a little closer. Wayne Knapp
bleys@tronsbox.UUCP (Bill Cavanaugh) (01/11/90)
> 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? / 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
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (01/11/90)
The following message is from ben Williams of Black Belt Systems. He has asked that I post it to the net in response to Wayne Knapp's recent posting. I will add only one comment to this posting. Ben is capable, honest, and so far, has produced everything he has said he would produce, and usually in less time than he said he would. ------ begin forwarded message ----- To Wayne Knapp: Since you obviously read the part of the message that stated that I don't have usenet access, I guess your remark about my posting being late must refer to some documents we were to mail you? <grin> C'mon... sure it was late. I responded as soon as I saw it, that's all there is to it. Bandwidth problems: Yes - when you run 640 mode stuff with four bitplanes, there are very serious demands made upon the CHIP memory's bandwidth. Serious _moving_ animation might well require that the system doing the animation have a reasonable amount of fast ram for the program to reside in... there is a lot of data, no way around that at all. It has to be moved, and the only way you can ease that bottleneck is to do the movement from fast ram. That relieves half the problem. Keep in mind that 6 bitplanes of HAM data isn't a whole lot better in terms of bandwidth than 4 bitplanes of hires... And we still see nice HAM animations. Re costs of the unit: Yes, we charge $300.00 for the unit. For developers, for end users, etc. Yes, we can't afford to give the thing away - that's not a crime, you know. We're here to try and help the Amiga, to be a viable business, and so on. If we had scads of $$$ floating around, we'd be providing the units at a deep discount. We don't. It's not like there are 20 million Amigas around. As I said in my previous note, you are entitled to your opinions, and if you're not interested in the HAM-E, then there you go. It's only the least expensive and most compatible video display expansion device available for the machine. As for other developers being interested or not, it would seem that "us developers" are very willing to get involved with the box, change code, and so on. We see very little resistance from developers, $300 or not. We had to expand the intial run from 100 units to 250 to accomodate the developers who felt they _had_ to have an early box. I appreciate the "go jump in a lake" comment and decline with a smile. Sounds like you spent a lot of time carefully working out a well reasoned reply. :*) It's not often someone degenerates to name calling in the first round of messages... a rare pleasure to see such a show. Never heard of us? There's that not enuf $$$ issue again. We have not (yet) been able to advertise other than in Amiga Transactor... we designed (and got FCC approved, unlike most Amiga developers) the Amiga AVT system, a video transceiver. 55 SSTV modes, 9 G1 FAX modes, telephone interface, ARexx, etc, etc. Marketed by AEA in Lynnwood Washington, mostly to HAM radio operators, so far. It's only the most powerful system of it's type ever made, that's all. We did Board Master, a mid level interactive PCB CAD system... $99.99, not exactly "raping the consumer". Then there is CoComm, a network managment telecomm program. We did C Ltd's (may they burn in hades) SCSIdos 3.0... until they stopped paying us... We've done numerous PD programs such as the JakeBoard, a logical KBD for the handicapped; SetPri, a nice Intuitionized priotity utility; Crypt, an encryption utility; A whole buncha stuff. We know the Amiga. Been at it since day one of the a1000's release. As far as your 24 bit compressed file format goes, good for you. There is 24 bit IFF (which is compressed, of course, to some degree) and Impulse, Syndesis, and ASDG are all interested in working with file formats and etc with our system... I don't think we'll miss you if you decide to stand by and wait for whatever else you think is coming along. Re the # of colors available on screen at one time... You're quite right, and I've changed the file to reflect the exact meaning of the term... thanks for catching the error. The correct value, without getting into overscan issues which would increase it quite a bit, is 128,000 pixels - not 40,000 as you said in your reply. You really do need a calculator, I guess. :*) That's 128,000 out of 262,144 possible, or, if you want to notice that the color registers are 24 bits, out of 16 million or so. Wayne, not to be mean or anything, but thinking about it, seeing you do math twice and screw it up twice, I guess even if you _did_ have a 24 bit compression method, we would take a pass on it. Hate to find out there were only 64 colors in your files. :*) Looking forward to your next inept attempt to be mean and nasty. Bye! Ben Williams - AA7AS, for Black Belt Systems. ---- end forwarded message ------ -- "Cavett Emptor - Let the talk show host beware!" - Evan Marcus +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
portuesi@tweezers.esd.sgi.com (Michael Portuesi) (01/11/90)
>>>>> On 10 Jan 90 23:31:15 GMT, waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) said:
wayne> However I will take a pot shot at you now. In the posting about how
wayne> the Black Belt video works (a really nice posting by the way) there
wayne> is detail about the 8 bit HAM mode. The posting states that over
wayne> 260,000 colors are possible on screen. Well isn't that a bit hard
wayne> with less than 40,000 pixels. (Should say something like > 30,000
wayne> colors out of 260,000 possible). Maybe we should all watch our math
wayne> a little closer.
Indeed. My calculator (yes, I still use a real calculator) says:
320 * 200 = 64,000 pixels for a low-res noninterlace screen.
Wayne, I think you have a legitimate point, but mindless flaming like
the stuff you posted above isn't likely to advance your point very
far.
--M
--
__
\/ Michael Portuesi Silicon Graphics Computer Systems, Inc.
portuesi@SGI.COM Entry Systems Division -- Engineeringpeter@cbmvax.commodore.com (Peter Cherna) (01/11/90)
In article <5357@tekig5.PEN.TEK.COM> waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) writes: >> I'm posting these for Ben Williams of Black Belt systems. He does not >> usenet access. > >> To Wayne Knapp: >> ... >> We utilize 16 pixels as the cookie, which leaves quite a bit >> of data bandwidth (per line) left over. >> ... >Yes I realise my error and that you only use 8 lines vs. the 24 >lines I though (in the interlace mode). I already acknowledge my >error your posting is late. > (misc observations deleted) ... >However I will take a pot shot at you now. In the posting about how >the Black Belt video works (a really nice posting by the way) there >is detail about the 8 bit HAM mode. The posting states that over >260,000 colors are possible on screen. Well isn't that a bit hard >with less than 40,000 pixels. (Should say something like > 30,000 ^^^^^^ >colors out of 260,000 possible). Maybe we should all watch our math >a little closer. Brap. Strike two in the mathematics World Series. :-) Non-overscan, you can get 320x400 pixels with the BB product, which is more like 128,000 pixels. Did someone say overscan? Ok, how about 362 by 482 overscan, less 8 lines for the register data (4 per field). That's over 173,000 pixels. It turns out that in a screwy way there may be more than 260,000 possible colors. In HAM, each pixel can be a color register, or a modification of the previous pixel. If it's a modification, they get to change 6 bits of r, g, or b. But they may allow all 8 bits-per-gun (24) to be set from a color register. You'd be able to modify the top 6 only, but you could judiciuously set the bottom two from time to time. If that were so, and you allowed me to choose 64 of the color register values, I could get to _any_ color value in 24-bit space within four pixels. So their marketing types could go wild and say 24-bit color in HAM! But it would really be 18-bit with very awkward (basically incidental) control over the bottom two bits-per-gun. > Wayne Knapp Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer.
waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) (01/11/90)
In article <5357@tekig5.PEN.TEK.COM>, waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) writes: > is detail about the 8 bit HAM mode. The posting states that over > 260,000 colors are possible on screen. Well isn't that a bit hard > with less than 40,000 pixels. (Should say something like > 30,000 > colors out of 260,000 possible). Maybe we should all watch our math > a little closer. Oh no not again! Okay change 40,000 to 64,000 and the other statement to ( > 60,000 colors out of 260,000). I'm not trying to slander Black Belt. I just have too many things I'm working on and I trying to reply too quickly! Sorry, Wayne Knapp
waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) (01/12/90)
In article <9292@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: > Brap. Strike two in the mathematics World Series. :-) > > Non-overscan, you can get 320x400 pixels with the BB product, which > is more like 128,000 pixels. Did someone say overscan? Ok, how about > 362 by 482 overscan, less 8 lines for the register data (4 per field). > That's over 173,000 pixels. > Okay, but remember the point is that there is no way that you can get 260K colors on the screen at one time. I was just nitpicking because people were so hung up on these easy things that they are thinking about the real issues. So you work for commodore. Can you tell me is the 3000 going to do anything to fix the real problem of the Amiga -- the limits on the CHIP RAM? Say making it 32 bit wide and about twice as fast would go a longs ways towards making the Amiga really fast. Wayne Knapp
groo@dsoft.UUCP (Bill Squier) (01/12/90)
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_wsquier@vaxc.stevens-tech.edu Temporary Inet (Please use until Jan. 13): ...uunet!tronsbox!dsoft!groo
mark@xrtll.UUCP (Mark Vange) (01/13/90)
In article <1990Jan3.200455.7440@athena.mit.edu>, chekmate@athena.mit.edu (Adam Kao) writes: > This is awesome! Brilliant! Really, really good! here, here! > 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
genly@m7.multiflow.COM (Chris Hind Genly) (01/14/90)
This is posted for Ben Williams who does not have direct access to USENET. ====================================================================== To Wayne Knapp: >>40,000 to 64,000... and the other statement to ( >60,000 colors >>out of 260,000). >>I'm not trying to slander Black Belt No, certainly not. Who could possibly think so? Do you know, this it the _third_ time you've bungled the math involved? Let do it for you. No Charge. The HAM-E board produces pixels at a 320/line rate. It supports interlace. This provides a 400 line environment, in a US machine and without overscan. 320x400 = 128,000. If one counts overscan, which is one of those "things" we don't really like to argue about, because while your monitor might then we can do up to say, 360x480 pixels, a total of 172,800 on screen. If you look at PAL machines (which we support 100%) then the total goes up even more, as they have more vertical scan lines available. It's not relevent to US/NTSC claims, though. I'd say 172,800 (or even 128,000) is one _heck_ of a lot different from 60,000 or 64,000. I'd also say, without reservation now, you need to purchase a calculator... or if you've been using one, you need to get more familiar with the Amiga and it's graphics modes. Have a nice day. :*) Ben Amateur Radio Callsign is A A 7 A S ---------------------------------------------------------------------- To Joe Hutchins: Nah, I won't torch you... those are valid issues, and deserve a valid response. Unlike some things I've seen recently. :*) Kludge? Well, maybe. It was _designed_ to conform to what was there, and to meet the needs of those who wanted more color than they had for graphics use. It has a lot of compatability, re the screens slide and front/back overlay capabilities, as well as the IFF view/show/animate capabilities. More than that we didn't see how to provide; both modes, the REG and HAME modes, are 8 bit, and so for some operations can be made to work with the Amiga's graphics libs. Only some of them, though. We don't think of it as a kludge, though. It's an aftermarket design, working within certain (very rigid) constraints. Yes, the 2000's have a video slot. And, we could have used that easily. Which would have left the 500 and 1000 owners out in the cold. Not very nice, and marketing-wise, not very smart, either. There are an awful lot of those machines out there. And making a unit that works with them ALL makes it that much more likely to succeed, as _anyone_ who wants to can participate, and the only ones left out are those who want to be, for their own reasons... and they can always change their minds w/o buying a new machine. This device is meant to address the image/paint/animation people. It's not meant (the I wouldn't bet we wont see this) to be a workbench screen, or a DTP basis. For what we meant it for, it will work extremely well, and on all machines. Again, doesn't seem to be a kludge to _us_, anyway. You say the Amiga's biggest problem right now is that it's falling behind in display quality. I don't agree. It's a big problem, but nowhere near as bad a problem as CBM's abysmally poor attempts at marketing the thing. Maybe it's the second biggest problem. We'd like to see it addressed, too (graphics res). Dpaint.... you _can_ use DPaint, as it stands, with the box. It's pretty weird, but you can do it. First, you take a brush (which we provide) that is one scan line long. It contains the magic cookie. You stamp this thing at the upper left of your image. You set DPaint's GRID to a 2 pxiel width. And you use 2 pixel-wide brushes to draw. It works. What can I say? :*) Now, EA (who produce the thing) has indicated that they are interested. At this point, that's all that is appropriate for them to say. THey hav not (yet) seen the thing (few have) but are on our notify list for the intial product run at their request. They have told customers on the phone that they are "eagerly waiting" to get the unit... call them and pest them a bit... see what they say to you. I can't speak for them. You have to remember that not everyone thinks of this as a kludge, including users, dealers, distributors, and developers in that. So for them, supporting it may not BE "supporting a kludge". Which makes all the difference in the world for support in general. Try looking at it this way. It's highly compatible. It's easy to install. It works automatically. It provides many more colors and much greater sharpness (at the same time) than any other Amiga graphics mode. It works on all machines, 500 -> 2500/030. And it's inexpensive. To most people it's all this, and it's a "box", never mond how it works. So to most people, the word "Kludge" never enters their minds. Ben Amateur Radio Callsign is A A 7 A S ---------------------------------------------------------------------- To Wayne Knapp: >>Summary: Great, but where do you get the IFF pictures in the >>first place? Ok, valid question. In another message, I described how we are using the _current_ version of DPaint to generate IFF drawings. Any program that produces 18 (or more) bit IFF files is a canidate for this box, right now. That includes things like digitizers (DigiView comes to mind immediately) Ray tracers (Silver) and Scanners (ScanLab from ASDG, for instance). Users, IE the programmer community as opposed to the "developer community" have a long history or writing whatever they need. We expect to see some very interesting software items that support the board in unique ways. Steve Tibbet has some great ideas, and says working on it now. There are others as well. EA and others are interested, and you may see 100% support at the paint program level, but that is in the future. We will probably provide as much of the PD stuff as we can on the release disk with the commercial unit. These are valid concerns, but they have been addressed as much as possible. I think you are missing something here... although this IS a new format, and so is mcuh weaker in the "supported" area than other current modes, it (by virtue of the IFF level compatability and the screen level compatibility) has a MUCH better running start than say, an external board would, even given software libraries to automatically move (most) of the rendering to the new board's output. Ben Amateur Radio Callsign is A A 7 A S ---------------------------------------------------------------------- To Jon Anderson: >I wonder why no one else has seen this.... It's certainly a >kludge Ok, I'll byte. _Why_ is it "certainly a kludge"? It works with all Amiga models... it was _designed_ to. It provides 256 colors, and color registers to go with them. It provides >256 colors, more than 4,096 colors, using what you aptly described as "nasty stuff". It'll come in a nice box, FCC approved, UL approved, quality RGB cable supplied. It doesn't require an extra monitor. What is kludgey about this? Notice this isn't a flame... I'm just asking, since you, and a few others, have made the assertion. Back it up now... that's all. THen, if you have insufficient justification, why THEN I'll flame you. :*) Ben Amateur Radio Callsign is A A 7 A S -- ======================================================================= Chris Hind Genly, N1GLZ - Multiflow Computer - mfci!genly (203)488-6090
kudla@pawl.rpi.edu (Robert J. Kudla) (01/14/90)
In <1188@m3.mfci.UUCP> genly@m7.multiflow.COM (Chris Hind Genly) writes:
(for Ben Whatshisname from Black Belt)
-> To Jon Anderson:
Hoo hah. I've been called many things in my time, but never have I
been mistaken for Jon. What a compliment, even if it is a
misinterpretation of my .sig. :)
Me>I wonder why no one else has seen this.... It's certainly a
Me>kludge
-> Ok, I'll byte. _Why_ is it "certainly a kludge"? It works with all
-> Amiga models... it was _designed_ to. It provides 256 colors, and
-> color registers to go with them. It provides >256 colors, more
-> than 4,096 colors, using what you aptly described as "nasty stuff".
-> It'll come in a nice box, FCC approved, UL approved, quality RGB
-> cable supplied. It doesn't require an extra monitor.
-> What is kludgey about this?
Let's see. It's on a strictly hardware level. Thus, it won't support
Intuition and graphics.library functions in a normal way (what happens
when you draw a box with one-pixel-wide lines, or better yet, a
one-pixel-think circle?), it requires nonstandard (to IFF) data to be
present (the cookie), and it requires data on every line or it'll revert
to normal screen mode. Therefore, unless programmers specifically
support it, if their program upens up a window on a HAM-E or even REG
screen it'll look like something the cat brought in. I'd call that
"nasty stuff".
I grant you, it'll be a real nice box for programs that do support it,
and pictures (can't wait to convert Gifs to REG mode) and anims oughta
be real interesting. It should also be great for digitizing, of
course. But that doesn't change that from a programmer's standpoint,
it presents some rather unique obstacles. I plan to buy one anyway.
-> Notice this isn't a flame... I'm just asking, since you, and
-> a few others, have made the assertion. Back it up now... that's
-> all. THen, if you have insufficient justification, why THEN I'll
-> flame you. :*)
Flame me now, if you want. I've been flamed by Clay Bond before. After
him, you're about as warm as a Video Toaster. :)
--
Robert Jude Kudla <kudla@pawl.rpi.edu>
"Famous? I'm not famous. People come up to me after a show and say
'Hey, Steve!'"
-Jon Andersonifarqhar@mqccsunc.mqcc.mq.OZ (Ian Farquhar) (01/15/90)
In article <5364@tekig5.PEN.TEK.COM> waynekn@tekig5.PEN.TEK.COM (Wayne Knapp) writes: >So you work for commodore. Can you tell me is the 3000 going to do >anything to fix the real problem of the Amiga -- the limits on the >CHIP RAM? Say making it 32 bit wide and about twice as fast would go >a longs ways towards making the Amiga really fast. > Or how about dual-porting CHIP RAM, thus pulling contention from both sides of the bus? The CPU could access CHIP RAM at the same speed as FAST RAM, and would only need to differentiate when it needs to place a structure or data that needs to be accessed by the Terrible Trio. (:-) On the other side of the bus, Agnus would no longer have to arbitrate between the processor and the custom chips, which would mean (theoretically) a doubling of the bandwidth of that channel. This could be used for all sorts of nice (and desperately needed) things: Giving all sound channels 16 bit resolution Giving the new "productivity" graphic mode a decent number of bit planes. etc... etc... etc... Yes, I do know that dual porting RAM is not easy, but then CBM does have its semiconductor group to solve problems just like these. Just a simple suggestion, folks. "A cynic is what an idealist calls a realist." Sir Humphrey Appleby (Patron Saint of Public Servants) Yes, Minister. Yes, Prime Minister. +-----------------------------------+-------------------------------+ | Ian Farquhar | Phone : (02) 805-7420 (STD) | | Microcomputer Support | (612) 805-7420 (ISD) | | Office of Computing Services | Fax : (02) 805-7433 (STD) | | Macquarie University NSW 2109 | (612) 805-7433 (ISD) | | Australia | Also : 805-7205 | +-----------------------------------+-------------------------------+ Den "A cynic is what an idealist calls a realist." Sir Humphrey Appleby (Patron Saint of Public Servants) Yes, Minister. Yes, Prime Minister. +-----------------------------------+-------------------------------+ | Ian Farquhar | Phone : (02) 805-7420 (STD) | | Microcomputer Support | (612) 805-7420 (ISD) | | Office of Computing Services | Fax : (02) 805-7433 (STD) | | Macquarie University NSW 2109 | (612) 805-7433 (ISD) | | Australia | Also : 805-7205 | +-----------------------------------+-------------------------------+ D
C503719@umcvmb.missouri.edu (Baird McIntosh) (01/16/90)
In article <5357@tekig5.pen.tek.com>, waynekn@tekig5.pen.tek.com (Wayne Knapp) > [lots of punches back and forth in a 'discussion' that is rapidly > degenerating into something a bit warmer.] > >However I will take a pot shot at you now. In the posting about how >the Black Belt video works (a really nice posting by the way) there >is a detail about the 8 bit HAM mode. The posting states that over >260,000 colors are possible on screen. Well isn't that a bit hard >with less than 40,000 pixels. (Should say something like > 30,000 >colors out of 260,000 possible). Maybe we should all watch our math ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >a little closer. ^^^^^^^^^^^^^^^^ Seems to me, being a Math/CS major :-), that in 8 bit HAM mode the BBV will allow about 64,000 (320 times 200) simultaneous colors on a lo-res screen. Double that to 128,000 (320 times 400) for lo-res interlaced screens. For lo-res overscanned interlaced screens you can probably display upwards of 150,000 colors out of the 262,000 total possible. And, of course each of those colors is out of the palette of 16 million. You can post and correct/flame me OR post and flame the BBV some more, but maybe we oughta wait till the thing gets produced/distributed. The original post was, after all, merely a product announcement and stated clearly that the release was imminent in the *future*. After all, if what you want out of this discussion is a cookie...well, wait for the BBV's release; Black Belt has designed 'cookies' into their video format. :-) :-) > Wayne Knapp # Baird McIntosh (2nd yr CS/MATH) -- "Sure, *sue* me; you WON'T get Ami!" :-) # # INTERNET: c503719@umcvmb.missouri.edu <-or-> BITNET: c503719@umcvmb.bitnet # # "You can keep your toy soldiers to segregate the black and white, but when # # the dust settles and the blood stops running, how do you sleep at night?" #
wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) (01/16/90)
. Wayne, not to be mean or anything, but thinking about it, seeing you
. do math twice and screw it up twice, I guess even if you _did_ have a
. 24 bit compression method, we would take a pass on it. Hate to find out
. there were only 64 colors in your files. :*)
.
. Looking forward to your next inept attempt to be mean and nasty. Bye!
.
. Ben Williams - AA7AS, for Black Belt Systems.
I'm not trying to be mean and nasty. I'm not sure about you though. As far
as your implied comment about me not have a good compressed file format for
24 bit color - all I have to say is more people have seen my work than have
seen your new video box.
Wayne Knapp bdb@becker.UUCP (Bruce Becker) (01/17/90)
In article <5384@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne Knapp) writes: |. Wayne, not to be mean or anything, but thinking about it, seeing you |. do math twice and screw it up twice, I guess even if you _did_ have a |. 24 bit compression method, we would take a pass on it. Hate to find out |. there were only 64 colors in your files. :*) |. |. Looking forward to your next inept attempt to be mean and nasty. Bye! |. |. Ben Williams - AA7AS, for Black Belt Systems. | |I'm not trying to be mean and nasty. I'm not sure about you though. As far |as your implied comment about me not have a good compressed file format for |24 bit color - all I have to say is more people have seen my work than have |seen your new video box. | | Wayne Knapp OK, you kids settle down RIGHT NOW or we're coming in there! Seriously, even though this is the Usenet where the custom all too often is to fling shit instead of ideas, you guys shouldn't be going on like this. There's too much to be done, and we need each other's cooperation a lot more than we need the satisfaction of a good inslut. None of this reflects well on your products either... -- ,,,, Bruce Becker Toronto, Ont. w \$$/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `/c/-e BitNet: BECKER@HUMBER.BITNET _/ >_ "Money is the root of all money" - Adam
bartonr@jove.cs.pdx.edu (Robert Barton) (01/17/90)
tron1@tronsbox.UUCP (HIM) writes: > There does NOT have to be a new IFF format . NON-BB Amigas will see a > perfectly normal 640x400 IFF with some funny colors on it so there is NO > incompatoibility. "Some funny colors" = incompatibility.