T.R | Title | User | Personal Name | Date | Lines |
---|
1578.1 | | LEDS::ACCIARDI | I Blit, therefore I am... | Fri Aug 05 1988 14:06 | 6 |
|
You must have seen the long-rumored Hedly monitor. I believe the
display used is 1008 x 800 pixels. I also think that it requires
the Enhanced Chip Set and v1.4 software.
Ed.
|
1578.2 | price? | STING::VISSER | | Fri Aug 05 1988 14:18 | 1 |
| ... and I thought it would be less than $200.
|
1578.3 | Mac this | WJG::GUINEAU | | Fri Aug 05 1988 15:57 | 6 |
|
Now Amiga can link to DECwindows... Will RS232 links be supported or ethernet
only?
John
|
1578.4 | | BAGELS::BRANNON | Dave Brannon | Fri Aug 05 1988 16:22 | 10 |
| re: .2
I suspect it will cost a lot more that $200. It is a 1008x800 display,
has a special board in the monitor to build the display, and clever
software in the Amiga to send the info to it. And there is no
competition for it in the Amiga market other than FlickerFixer,
which does non-interlaced 640x400 color (and requires an A2000 video
slot). That tearing sounds like they have some more work to do in the OS.
-dave
|
1578.5 | -sigh- | STING::VISSER | | Fri Aug 05 1988 17:22 | 4 |
| Yea, but...
I thought it was in this conference that I saw the old $189.
or so price, or maybe one of the magazines. Oh well.
|
1578.6 | The Hedly Monitor | TLE::RMEYERS | Randy Meyers | Sun Aug 07 1988 20:27 | 68 |
| The gray scale high res monitor has been covered in the Amiga developer's
newsletter. The monitor is similar to the "flicker fixer" in design: the
monitor has a frame buffer built in that combines several frames of Amiga
video into one frame for the monitor to display at a 60 frames/sec refresh rate.
The monitor is capable of displaying 1008 pixels by 800 lines by four shades
of gray. It can also be used in a 640 by 400 mode where it performs the
same trick the flicker fixer does: combine the two interlaced fields of
Amiga video into one frame of data output at twice the refresh rate.
The monitor does not require any update to the custom chips, and I believe
that it connects to the Amiga RGB port and so will work with all Amigas
ever produced. However, the Amiga must be running to special versions
of the system software. Commodore hints that the monitor will be made
available before 1.4, and so users of the monitor will have to use the
"ROM tags in RAM" (also sometimes called "Jumpstart") feature to replace
some of the ROM versions of libraries with versions loaded from disk.
When working in "extended mode" (1008 by 800), the monitor combines
either four or six "fields" of video information into one frame to
be displayed on the monitor at 60 frames a second. (A "field" is what
you would normally call one frame of video information from the Amiga.
Video types use the term field for part of the video information that
goes together to make up a complete frame. For example, a frame on
a television picture is interlaced and consists of two fields: a field
that contains the even numbered scan lines and a field containing the
odd numbered scan lines.)
Although the monitor is displaying frames at sixty per second, in extended
mode the Amiga can only update the entire display at 15 or 10 frames a
second. The reason is that the Amiga is outputting the fields that make up
the frame at sixty per second and it takes either for four or six fields
to make up a complete frame. The reason why the monitor supports the choice
of four versus six fields to make up a 1008 x 800 x 4 frame is to allow
the user to make the tradeoff between chip memory contention in the Amiga
and a faster complete update rate for the extended display.
If the user puts the system into four fields per frame mode, the Amiga
can update the entire display 15 times a second but will experience 100%
chip memory contention. At six fields per frame, the update rate drops
to 10 frames per second but the memory contention drops to zero. Many
of the boring business applications (spreadsheets, desktop publishing)
probably would be happy with the slower to update screens. By the way,
100% chip memory contention is not the disaster it sounds like. Fast
memory never experiences any contention. (Well, I am not counting
that half-fast "other half meg" in the Amiga 2000 and 500 as fast memory
because it is really chip memory waiting for the newer Agnus to come
along. Also, I am ignoring that various other non-chip devices like
DMA disk controllers that can cause contention for fast ram.)
This explains the tearing that the author of .0 noticed. If a window
straddles a field boundary, part of the window will appear to be updated
before the rest. This is unavoidable. It isn't all bad, however.
Effectively, the display is a four or six buffered display. That means
that complicated rendering that occurs entirely within one field will
appear to instantly happen. You will not be able to see any intermediate
stages in the drawing.
All of this happens fairly transparently. Most programs that use the
Workbench screen will be unaffected. Programs that will be affected
are programs that use more that four color screens or make use of
the copper. In extended mode, the copper spends most of its time
coordinating outputting the fields that make up the extended frame.
This means that in extended mode, you will not be able to drag down
a screen to display part of the screen underneath. In fact, even
Guru messages will not push down the current screen to display the
flashing red box: instead that guru box will be the only thing on the
display.
|
1578.7 | Made by Moniterm | PRNSYS::LOMICKAJ | Jeff Lomicka | Mon Aug 08 1988 12:16 | 11 |
| The "glossy sheet" on the monitor (which I finally found) agrees
completey with the description above, with the exception that the name
of the product is "The Viking 1 for the Commodore(R) Amiga(TM)", and is
made by "Moniterm". In the booth, I spoke to an Amiga engineer who
claimed to have worked on the gate array that is used in this, and
perhaps other monitors. If you want to find out more, such as price,
Moniterm can be reached at (612) 935-4151.
Since I own an Atari, not an Amiga, I'm not about to call them myself.
|
1578.8 | | LEDS::ACCIARDI | I Blit, therefore I am... | Mon Aug 08 1988 13:42 | 8 |
| >Since I own an Atari, not an Amiga, I'm not about to call them
myself.
That reminds me Jeff; when are you going to fix this deplorable
condition? :)
Ed - (who'd love an Amiga version of WHACK)
|
1578.9 | whack/tdsmp/life | VIDEO::LEIBOW | Michael Leibow | Mon Aug 08 1988 14:13 | 7 |
| This reply doesn't belong here...
I am including (slowly) some of Jeff's WHACK modules into Meshugena.
You'll probably see it by next year.
--Mike
|
1578.10 | Windows in Luck | NAC::PLOUFF | Beautiful downtown Littleton | Mon Aug 08 1988 14:17 | 4 |
| This must be the software implementation Dale Luck has been hinting
about on Usenet. As one of the original Amiga software gurus, he
should certainly have a quality product. Wonder if it will run
on an ordinary 640x400 screen?
|
1578.11 | Never heard of the X project being tied to Hedly | TLE::RMEYERS | Randy Meyers | Mon Aug 08 1988 18:18 | 5 |
| Re: .10
>Wonder if it [the X windowing system] will run on an ordinary 640x400 screen?
I'd bet yes.
|