| I didn't see this anywhere in this notesfile so I thought I'd drop it
here. As you can probably tell I pulled it from USENET. If it is
already posted, sorry bout that.
- - - - - - - - - - - - - - - - - -
Article 60453 of comp.sys.amiga:
Path: rust.zso.dec.com!bacchus.pa.dec.com!deccrl!decvax.dec.com!mcnc!mephisto!emory!swrinde!cs.utexas.edu!uunet!hsi!genly!chris
From: [email protected] (Chris Hind Genly)
Newsgroups: comp.sys.amiga
Subject: HAM-E
Message-ID: <[email protected]>
Date: 16 Sep 90 19:01:41 GMT
Organization: Eggplant Software Tools, CT, USA
Lines: 312
I'm posting this for Ben Williams of Black Belt Systems. He doesn't
have direct access to USENET. I'd be glad to forward replies.
* * *
\|/
* _______ --O--
____/ KC1VP \____ * /|\
* _____________/ (203) 389-8680 \_______________
______/ 95 Fountain Terr., New Haven, CT, USA, 06515 \_______
/ Chris Hind Genly [email protected] uunet!hsi!genly!chris \
----------------------------------------------------------------
==================================================================
From Ben Williams, VP Engineering, Black Belt Systems.
==================================================================
--- Replies to various messages that have floated thru the net recently ---
I've seen some recent UseNET msgs that describe the HAM-E device in a
most confused manner - one message requested:
>If anyone has definite information on these new video enhancement products,
>please set the net.record straight.
Ok, I have definitive information on the HAM-E. I designed it, I
should. :^)
Data Source
-----------
The HAM-E does indeed work by taking pairs of hi-res pixels from a 4
bitplane screen, and building an 8 bit pixel from these. This provides
up to 384 pixels per line of 8 bit data.
Mode 1
------
One way the HAM-E uses this data is to address 256 24-bit color
registers. This provides a pure 256 color mode, with a 16 million color
palette. Not too much to discuss or explain here.
Mode 2
------
The other way the HAM-E uses this data is to interpret it as a HAM
image. This has been designed to be quite different from the Amiga's
native HAM mode in capacity, but is similar to it most ways as far as
concepts go. The Amiga's HAM mode works with a 6 bit word; 2 bits are
used to control operations, and 4 for data. The 4 data bits can either
pick a color register, which loads the 12 bits in the color register
right to the RGB guns, or they can load into any ONE of the three RGB
guns, updating 4 of the 12 bits being output for any one pixel. With 12
total output bits, you get 4,096 colors.
The HAM-E, as I pointed out, has an 8 bit word, not a 6 bit word. We
use the most significant 2 bits for control, as the Amiga HAM mode
does. That leaves us SIX data bits. In the simplest case, you could
choose either any one of 64 color registers to load the RGB all at
once, or you could load 6 bits of data for any ONE of the RGB guns. The
total output resolution in mode 2 for the HAM-E is 18 bits 6:6:6, as
compared to the Amiga's 4:4:4, which allows 262,144 colors.
Since there are far more than the Amiga's 16 color registers, fringing
effects can be reduced way below what is "normal" for an Amiga HAM
image. And since there are far more colors, image contouring (banding)
problems go away, as does the need to dither.
Our mode 2 is a little more complicated than this explanation would
show, however. Although the obvious thing would be to allow you to
choose 1 of 64 color registers when the control bits say load register
(00, by the way - same as the Amiga), we don't (exactly) do that. If
you specify registers 0-59, that's what you get. A register. If you
specify 60, NO color change occurs for that pixel, instead the hardware
changes to a new BANK of registers (bank 0). Similarly, the values 61,
62 and 63 cause an immediate switch to banks 1, 2 and 3. There is no
extra system overhead incurred for the bank switch, but the pixel where
it occurs does hold all three of RGB values right thru. The end result
is that you can HAM (Hold-And-Modify) to a quarter million colors, and
you can use up to 240 registers (4 banks of 0-59) to "fix-up" any
fringing errors that occur. There are even some more things you can do,
but this describes the mode pretty well.
Modes for the modes (so to speak)
---------------------------------
The above two modes can be displayed as 320x200, 320x400, and with
either dimension as full overscan (up to 384x and 480/240y). On a PAL
machine, the overscan length is longer than 480/240, of course.
System compatibility
--------------------
The HAM-E plugs into your main 23 pin RGB port. There is another 23 pin
RGB port on it as the output, and you plug your monitor in there. When
either one of the HAM-E modes are operating, that's what you see. The
new mode screens pull up and and down, and can overlap and underlap
"normal" Amiga screens. All output is pure RGB, all the time. In short,
attaching the hardware gets you 2 new video modes, and does not
interfere with the operation of your system. Our system is 100%
compatible with PAL machines, too. it works with every Amiga made,
including (as of 2 weeks ago when we checked at CBM West Chester) CDTV,
the new "Baby". We only attach to the RGB port; DCTV attaches to both
your parallel port and the RGB port. Then again, if you want to
digitize, DigiView attaches to the parallel port, so there you go.
Although I hasten to point out that you can use any digitizer that
makes 24 bit files with the system... it doesn't have to be digiview.
The new ECS do NOT confuse the HAM-E hardware.
Genlocking
----------
The HAM-E should operate with any NTSC or PAL genlock with no problems,
both the two new modes, and all your "old" ones. Every signal that is
available on the Amiga's DB-23 connector is available on ours except
for the IRGB lines. For you genlock techies, we only watch the
composite sync line, so vsync and hsync signal manipulation by the
genlock don't affect our operation at all.
The HAM-E provides a genlock signal whenever color register 1 or color
register zero is being displayed. In english, this means that both
register zero and register one are transparent during genlock operation.
Supplied software
-----------------
We provide free with the system a real-time paint program (if it wasn't
real-time, it'd be pretty useless, we think), with features that are
similar to DPaint for the most part although some things are much more
powerful than those equivalant features in DPaint. We do real-time
blitted brushes, with Matte, Color, and Cycle capability; We provide
true ZOOM, as well as brush enlarge; We allow up to 10 color cycle
ranges instead of four, and they can be up to 256 registers long
(naturally). We allow a color cycle range to "pong", that is, bounce
back and forth. We have "glow" ranges, where a single color register is
cycled thru a list of up to 256 colors. We handle stencils, various
neat brush manipulations, color remapping, loading of all kinds of
"regular" Amiga images (DigiPaint ham, Photon ham, 24 bit RGB IFF, 2-32
color IFF, 64 color 1/2 bright IFF, RGB8 Impulse images) so that you
can incorporate them into your paintings; We have spare screens, undo,
stencils with range set, clear, and flip; Et-et-et-cetera. :^)
We also provide a renderer that can take a 24 bit file, data directly
from memory, or the buffers inside DigiView 4.0 while it is still
running and render to 256 colors or 256k colors. The renderer allows
you to specify that a certain number of registers be used so you have
some left to paint with; it allows an "NTSC limit" setting so that
images don't overdrive composite encoder systems; and there are six
_really_ different rendering techniques available.
Keen Developer Info
-------------------
You can call the renderer from within any application and use ANY of
it's features in your new whiz-bang render-gender-ware by simply
passing it the addresses of your internal RGB buffers and the
appropriate command line switches. If your application provides ARexx
(it should!) then commands to export the addresses of the RGB buffers
and the X:Y resolution of them are all you need for 100% support for
the HAM-E device. Since we provide the source code to the renderer, you
can just incorporate that if you like, but it's more reasonable to call
the renderer itself, that way you get the advantages of any
improvements we might bring out, or others might add, considering they
have the source code...
Looky here...
-------------
To cap things off, we provide the complete source code for both the
paint and the render software in Lattice C (Well, SAS C, now...). It's
available on our company BBS, which is an open system. Now there is
something you've not seen before, eh? :^)
Cost
----
The HAM-E is $299.95, including paint software, render software,
free software source code, and free updates to the paint software
indefinitely. You get everything you need to run.
DCTV vs. HAM-E
--------------
I saw a great deal of mention of DCTV, and some lines like:
>I'd like to see Ham-E too. But I think it is a bit more limited and I
>don't think it is a digitizer...
Right, no digitizer. You can use DigiView, which will give you true 18
bit resolution when used with the HAM-E. The DCTV digitizer is an NTSC
only, composite digitizer. That means you get all the features
composite offers, such as blurry reds and _very_ blurry blues. Using
DigiView with HAM-E, you've digitized an RGB image to an RGB system, as
opposed to a composite source image (yech) to a composite output system.
DCTV includes a digitizer, and is 500$ retail. You can add another 100$
is you want to see the output on your RGB monitor or genlock. $600
list. The HAM-E + Digiview will cost you around $400.00, and you can get
RGB images instead of composite. Should you NEED composite, you can
attach a composite encoder, like the VIP from DigiFEX, and there you
have it.
Real time performance. DCTV can animate frames, flipping pages. We can
animate frames too, but we are always 4 bitplanes, they (at reduced
resolution) can use 3 - that seems to give them a speed advantage.
However, we can animate regions, as our encoding is a lot more local
than composite compression is, and we can do color register animation,
which they can't do at all - which has very little overhead. So both
systems can animate, the HAM-E has more options as to HOW you want to
animate.
Output from the HAM-E uses your current monitor, HAM-E screens work in
your system just as you'd want them to. Output from DCTV is composite
unless you buy the extra $100 thingee. Which means (a) you buy another
monitor, or (b) you press the monitor switch, assuming that you have a
monitor that can display composite and NTSC, as many can.
About 24 bit claims
-------------------
Y'all might want to do some research on this term. It's getting thrown
about with some pretty wild abandon anymore. What it means is that a
system can produce 256 levels of grey, or any primary combination, or
256 levels on any combination of all three the RGB guns of a monitor at
one time; or digitize them likewise. There are 16 million various bit
combinations, which we (usually) call colors, I'm not going to quibble with
that here. The HAM-E is 18 bits overall in mode 1, or 24 bits out of 256
colors in mode2. Let's be REAL clear about that. DCTV is not 24 bit, if
for no other reason than NTSC can't DISPLAY 24 bit data, much is lost in
the attempt. If they are 24 bits internally, so what? If you can't see it,
what's the point?
Availability and etc.
---------------------
The HAM-E is shipping now, although there is a 2-3 week wait at this
point as we've sold all we had. It's class B FCC approved, so you can
legally buy it and use it at home. The power supply is UL approved,
too. Is DCTV shipping? Is it FCC/UL approved? We don't know. You can
find out easily, just call them at (916) 344-4825, or FAX them at
(916) 635-0475.
Advertising
-----------
Right, you have not seen any Black Belt Systems ads extolling the
virtues of the HAM-E, while DCTV is in AmigaWorld big-time. We were not
willing to place any ads until we were shipping. We felt the Amiga
community had had enough of that kind of behaivoir, and we were NOT
sure enough of manufacturing, testing, software availability and so on
to place an ad before we were ready - so we didn't. We're shipping now,
and so now you'll see ads. That's all there is to it.
Who ya gonna call?
------------------
Want a brochure? Call (800) TK-AMIGA and ask for one - we'll send you
a nice color flyer. You can FAX us if you prefer at (406) 367-AFAX. and
you can get onto our BBS to D/l the C source code and/or the actual
support software at (406) 367-ABBS. If you're out of the country, you
can't reach the (800) number, so call (406) 367-5513. If you want lots
of excruciating technical details, call Tech Support at (406) 367-5509.
Some interesting lines from UseNet:
-----------------------------------
>>Isn't DCTV the box which gets 256 screen colors by intercepting a 640x400
>>16 color screen and combining each pair a pixels (4 bits each) into one
>>8-bit pixel? I know there is a box like this. In this case, all well and
>>good, you get 256 out of 16 million (I think) colors, but only in 320x400
>>(or variations... not 640 mode at any rate). This could be a
>>consideration.
............
>No it isn't. That is Ham-E you are thinking of. DCTV is a Full NTSC
>color palette frame buffer. DCTV is reliant on Amiga's chip ram for it's
>display.
Ahem. :^) The HAM-E can display a quarter of a million colors, and do
them as a MUCH sharper image than DCTV can. If you need composite, then
use an encoder with the HAM-E and you'll get the same quality NTSC
output that DCTV offers, or better. The HAM-E also relies on the
Amiga's chip ram for it's display, but uses the data there entirely
differently.
> Absolutely none of these products offer a non-interlaced display (which
>is important for most real-world applications), absolutely none of them
>will work with standard Amiga applications, like the few DTP and CAD
>programs that are available for the Amiga. To make matters much worse,
>none of them will so much as even work with the Amiga's O.S. at all.
Oh boy, is this one off the wall. Both DCTV and the HAM-E offer non-
interlaced modes. The HAM-E will work with The Director, any show
program, AmigaVision, UltraCard, Turbo Silver, Sculpt, Caligari, The
Art Department, CanDo, and virtually any program that supports the
Amiga standard of 24 bit IFF. The HAM-E works within the screen
environment, pulling up n down, moving front-back and v-v. You can
render intuition gadgets including title bars, F/B gadgets, regular
image gadgets, and more. My main beef with this sender is that the
attempt is made to sound like an authority, when in fact events show
clearly that they have NO idea what they are talking about. My mom
always told me "if you don't know what you're talking about, shut up".
I also saw the term "proprietary" mentioned on the net. Theirs is, ours
isn't. Releasing the source code to everything can hardly be regarded
as "keeping things close to the chest", now can it?
You can do some editing in DPaint for HAM-E images. Turn grid on to 2
horizontally, 1 vertically, and DPaint will help you out quite a bit.
Our pixels are unique 8 bit entities in mode 1, and even in HAM mode
respond pretty well as blocks.
There is a rather authoritatively toned message on the net from an
individual who names themself "Radagast". I'd like to request that this
message be ignored, as it contains more misinformation in one place
than I've seen in quite some time. No offense, but that message is
really all wrong.
Some of you can see this thing easily - and compare
---------------------------------------------------
We'll be at the Anahiem AmiExpo, in the booth right next to the DCTV
people, and we'd be quite pleased to show you our device where you can
look at ours, and theirs just by turning your head.
=====================================
Ben Williams, for Black Belt Systems.
=====================================
|