[net.micro.amiga] interlace mode

daveb@amiga.UUCP (Dave Berezowski) (01/18/86)

<eat my line>

	There has been a lot of talk (and flak) about the apparent
'unusable' interlace mode of the AMIGA. I have seen a 640 x 400
screen that didn't seem to flicker at all and looked dynamite!
BUT the programmer did use a trick to accomplish this feat.

	The trick is to plot a pixel ON and ABOVE the line where the
pixel is to be placed. This still results in an effective resolution
of 400 lines BUT reduces the flicker to almost zilch. I saw this
implemented on a terminal program and a graphics display and they
both looked great on a 1080 monitor. Give it a try, the results
may surprize you!

	Regards, David Berezowski (CBM/AMIGA East Coast)

breuel@h-sc1.UUCP (thomas breuel) (01/18/86)

|	There has been a lot of talk (and flak) about the apparent
|'unusable' interlace mode of the AMIGA. I have seen a 640 x 400
|screen that didn't seem to flicker at all and looked dynamite!
|BUT the programmer did use a trick to accomplish this feat.
|
|	The trick is to plot a pixel ON and ABOVE the line where the
|pixel is to be placed. This still results in an effective resolution
|of 400 lines BUT reduces the flicker to almost zilch. I saw this
|implemented on a terminal program and a graphics display and they
|both looked great on a 1080 monitor. Give it a try, the results
|may surprize you!
|
|	Regards, David Berezowski (CBM/AMIGA East Coast)

Sure, if you use 640x400 as a 640x200 mode, then you won't see
any flicker, you won't have any higher resolution either, though,
and you'll waste a lot of memory.

The only thing I don't like about the AMIGA (apart from its
price) is the fact that it doesn't manage to produce 640x400
graphics. I have seen several demos in high-resolution mode,
and the flicker is really unbearable for any real work.

WHAT I WOULD LIKE TO KNOW IS: is Commodore/AMIGA planning on
releasing a version of the AMIGA in which this problem has
been fixed (e.g. in which the monitor can be run at either
60Hz or 70Hz)? Is there a hardware patch that can be applied
to current machines to solve the problem?

I find that for serious use as a desktop workstation,
a resolution of 640x200 pixels is just not enough.
The Mac is just barely usable (slightly lower horizontal
resolution and larger vertical resolution), and the LISA is
probably the only low-end work-station on which you can afford to
have two reasonably sized windows open at the same time.

						Thomas.

farren@well.UUCP (Mike Farren) (01/19/86)

In article <877@h-sc1.UUCP>, breuel@h-sc1.UUCP (thomas breuel) writes:
> |	The trick is to plot a pixel ON and ABOVE the line where the
> |pixel is to be placed. This still results in an effective resolution
> |of 400 lines BUT reduces the flicker to almost zilch. I saw this
> 
> Sure, if you use 640x400 as a 640x200 mode, then you won't see
> any flicker, you won't have any higher resolution either, though,
> and you'll waste a lot of memory.

    This isnt 640X200 mode.  You still have 400 (399, actually) vertical
pixel locations, it's just that each pixel is now 2 lines high instead of
one.  It's the same sort of thing that a lot of machines (specifically
Atari 800 and Apple II) did to avoid horizontal color aliasing when using
a standard NTSC type composite monitor.
 
> WHAT I WOULD LIKE TO KNOW IS: is Commodore/AMIGA planning on
> releasing a version of the AMIGA in which this problem has
> been fixed (e.g. in which the monitor can be run at either
> 60Hz or 70Hz)? Is there a hardware patch that can be applied
> to current machines to solve the problem?

  The necessary fix would be fairly expensive. The biggest reason for the
640 X 200 limitation on each field is to reduce the bandwidth requirements
of the coprocessor and the memory, and to allow the CPU more cycles. 
Maintaining the current hardware capabilities and adding the extra capability
you describe isn't an easy job. (Before I hear anything about the Atari ST
and its 640X400, 70Hz screen, let me remind you that that is a one-bit-per-
pixel monochrome screen.  It's ONLY color option is 320X200.  If you are
willing to accept THAT limitation, then the problem isn't too hard.  If you
want a color screen such as the Amiga's, at a reasonable cost, compromises
have to be made.)

-- 
           Mike Farren
           uucp: {your favorite backbone site}!hplabs!well!farren
           Fido: Sci-Fido, Fidonode 125/84, (415)655-0667

breuel@h-sc1.UUCP (thomas breuel) (01/20/86)

|||	The trick is to plot a pixel ON and ABOVE the line where the
|||pixel is to be placed. This still results in an effective resolution
|||of 400 lines BUT reduces the flicker to almost zilch. I saw this
||
||Sure, if you use 640x400 as a 640x200 mode, then you won't see
||any flicker, you won't have any higher resolution either, though,
||and you'll waste a lot of memory.
|
|    This isnt 640X200 mode.  You still have 400 (399, actually) vertical
|pixel locations, it's just that each pixel is now 2 lines high instead of
|one.  It's the same sort of thing that a lot of machines (specifically
|Atari 800 and Apple II) did to avoid horizontal color aliasing when using
|a standard NTSC type composite monitor.

This may do the trick for certain kinds of graphics. For a high-resolution
text display, it may make your characters look nicer, but it does not
allow you to display significantly more characters on the screen.

|  The necessary fix would be fairly expensive. The biggest reason for the
|640 X 200 limitation on each field is to reduce the bandwidth requirements
|of the coprocessor and the memory, and to allow the CPU more cycles. 
|Maintaining the current hardware capabilities and adding the extra capability
|you describe isn't an easy job. (Before I hear anything about the Atari ST
|and its 640X400, 70Hz screen, let me remind you that that is a one-bit-per-
|pixel monochrome screen.  It's ONLY color option is 320X200.  If you are
|willing to accept THAT limitation, then the problem isn't too hard.  If you
|want a color screen such as the Amiga's, at a reasonable cost, compromises
|have to be made.)

Yes, that is precisely the point. For word processing and program development
I vastly prefer high monochrome resolution to low colour resolution. That
is not a bad limitation, it is a reasonable compromise (between cost
and performance). What counts for those applications is whether you can
display one, two, or four usable windows on the screen at the same time,
not whether your menu bar is green and your pop-up menus are pink.

I guess we just have different applications in mind. For my purposes,
a machine with true 640x400 monochrome resolution is just superior to
one with 640x200 colour resolution because I can display more text
on the screen at the same time. Since I otherwise like the AMIGA,
I really regret that it doesn't have this capability. It is unfortunate
to hear that Commodore/AMIGA seems to have no intention of adding
a high-resolution monochrome mode.

							Thomas.

long@sask.UUCP (Warren Long) (01/21/86)

> <eat my line>
> 
> 	There has been a lot of talk (and flak) about the apparent
> 'unusable' interlace mode of the AMIGA. I have seen a 640 x 400
> screen that didn't seem to flicker at all and looked dynamite!
> BUT the programmer did use a trick to accomplish this feat.
> 
> 	The trick is to plot a pixel ON and ABOVE the line where the
> pixel is to be placed. This still results in an effective resolution
> of 400 lines BUT reduces the flicker to almost zilch. I saw this
> implemented on a terminal program and a graphics display and they
> both looked great on a 1080 monitor. Give it a try, the results
> may surprize you!
> 
> 	Regards, David Berezowski (CBM/AMIGA East Coast)


Doesn't this little trick drop the resolution down to 200 lines????
(at least for all intents and purposes.)

				 Warren Long
				 University of Saskatchewan
				 Canada

mykes@3comvax.UUCP (Mike Schwartz) (01/21/86)

There is little doubt in my mind that the Amiga could have had much better
resolution than it already does, but the tradeoff would have been non-NTSC
standard.  This means that not only could the Amiga not be plugged into
a TV and features like GENLOCK would be much more expensive.  A distinct
advantage of being NTSC standard is that not only can input from a video
camera be mixed in, but the output can be recorded on standard video tape.

Blame for the flicker in interlace mode should be placed on the NTSC standard,
not the Amiga.  NTSC is not exactly the best quality video standard anyway.

mjg@ecsvax.UUCP (01/21/86)

> 
> 
> 	The trick is to plot a pixel ON and ABOVE the line where the
> pixel is to be placed. This still results in an effective resolution
> of 400 lines BUT reduces the flicker to almost zilch. I saw this
> implemented on a terminal program and a graphics display and they
> both looked great on a 1080 monitor. Give it a try, the results
> may surprize you!
> 
> 	Regards, David Berezowski (CBM/AMIGA East Coast)


Doesn't this mean that the vertical positioning resolution is 400
lines but that objects can only be described to the nearest 1/200th
of the screen height.

Mike Gingell     ..decvax!mcnc!ecsvax!mjg

tynor@gitpyr.UUCP (Steve Tynor) (01/22/86)

>you describe isn't an easy job. (Before I hear anything about the Atari ST
>and its 640X400, 70Hz screen, let me remind you that that is a one-bit-per-
>pixel monochrome screen.  It's ONLY color option is 320X200.  If you are
>willing to accept THAT limitation, then the problem isn't too hard.  If you
>want a color screen such as the Amiga's, at a reasonable cost, compromises
>have to be made.)

Medium res (high res color) on the atari st is 640x200.

tainter@ihlpg.UUCP (Tainter) (01/22/86)

> you describe isn't an easy job. (Before I hear anything about the Atari ST
> and its 640X400, 70Hz screen, let me remind you that that is a one-bit-per-
> pixel monochrome screen.  It's ONLY color option is 320X200.  If you are
>            Mike Farren

WRONG!  The ST also has 640x200 color, albeit with fewer color choices.
--johnathan a. tainter

rb@ccivax (01/23/86)

> In article <877@h-sc1.UUCP>, breuel@h-sc1.UUCP (thomas breuel) writes:
>   The necessary fix would be fairly expensive. The biggest reason for the
> 640 X 200 limitation on each field is to reduce the bandwidth requirements
> of the coprocessor and the memory, and to allow the CPU more cycles. 
> (Before I hear anything about the Atari ST
> and its 640X400, 70Hz screen, let me remind you that that is a one-bit-per-
> pixel monochrome screen.  It's ONLY color option is 320X200. 

Minor Correction: you also get colors (4) in 640X200 mode on the ST!

> If you are
> willing to accept THAT limitation, then the problem isn't too hard.  If you
> want a color screen such as the Amiga's, at a reasonable cost, compromises
> have to be made.)

So how about this as an option (to get the best of both worlds!)!
Add 640X400 monochrome at 70HZ interlaced.  This would be ideal for editing
text and large draftings that end up getting sent to a 'monochrome' copier
for quick and cheap duplication (the majority of office documents). 
Then use the multicolor interlaced mode
for stuff that will be sent to the print shop for color printing.

From what I've seen in the Amiga Specs, it seems to have more than enough
bandwidth for this (mono 70HZ) mode and still have about the same CPU
bandwidth as it would in the 640X200X4 at 60HZ mode.  It might even be
a simple software change.

There are still a lot of situations where all you need is easy to read
black and white (like stuff for copiers).  Also, there is no reason why
you couldn't get 80x50 lines on the screen by using the same 'fonts' you
would normally use on the 640X200 screen (not to mention being able to
look at two documents at once).  Of course, if the 'monochrome' could be
put on a color display, you could still pick your choice of forground
and background colors from the color registers (White on Black background
is hard to do on any color monitor).

mykes@3comvax.UUCP (Mike Schwartz) (01/23/86)

The double height pixel trick for interlace mode yields 399 vertical 
positions that the top pixel (of the two) can be.  However, the OS does 
not take advantage of this trick, but a Mac-write style word processor
could.

farren@well.UUCP (Mike Farren) (01/23/86)

I wrote:
>>you describe isn't an easy job. (Before I hear anything about the Atari ST
>>and its 640X400, 70Hz screen, let me remind you that that is a one-bit-per-
>>pixel monochrome screen.  It's ONLY color option is 320X200.  If you are
>>willing to accept THAT limitation, then the problem isn't too hard.  If you
>>want a color screen such as the Amiga's, at a reasonable cost, compromises
>>have to be made.)
And Steve Tynor replied:
> Medium res (high res color) on the atari st is 640x200.

   Thanks for the information.  I hadn't realized there was a med-res mode.
It still doesn't change things, though.  The limitation is the number of
bytes you're shoving through the graphics hardware every frame, and I
would believe that med-res mode on the Atari cuts the number of colors
displayable in half?  Twice the resolution = half the colors = same number
of bytes/line.

   It might be possible, by limiting the bit-planes to one (or possibly 2),
to get the bandwidth you'd need to put out a 640X400 non-interlaced screen,
as someone else suggested.  The secondary problem that that brings up is
simple:  you need a different monitor.  A monitor that will handle 640X400
is forced to operate with a MUCH higher horizontal frequency, and would    
either be much more expensive (if color), or incompatible with the lower
resolution modes (rendering a lot of software incompatible), or both.
I'm pretty sure this is the reason the STs have two non-intermixable
monitors.

-- 
           Mike Farren
           uucp: {your favorite backbone site}!hplabs!well!farren
           Fido: Sci-Fido, Fidonode 125/84, (415)655-0667

dca@edison.UUCP (01/24/86)

> In article <877@h-sc1.UUCP>, breuel@h-sc1.UUCP (thomas breuel) writes:
> > |	The trick is to plot a pixel ON and ABOVE the line where the
> > |pixel is to be placed. This still results in an effective resolution
> > |of 400 lines BUT reduces the flicker to almost zilch. I saw this
> > 
> > Sure, if you use 640x400 as a 640x200 mode, then you won't see
> > any flicker, you won't have any higher resolution either, though,
> > and you'll waste a lot of memory.
> 
>     This isnt 640X200 mode.  You still have 400 (399, actually) vertical
> pixel locations, it's just that each pixel is now 2 lines high instead of
> one.  It's the same sort of thing that a lot of machines (specifically
> Atari 800 and Apple II) did to avoid horizontal color aliasing when using
> a standard NTSC type composite monitor.
>  
Huh? obviously I am missing something here.  It seems to me that by making
each pixel 2 lines high we have just created a screen that will hold only
640x200(virtual) pixels.  I would imagine that the 640x200 essentially does
exactly this, i.e. expands that pixel height.  Therefore it seems to me
that using the 640x400 strictly in this manner is equivalent to using the
640x200 mode except more memory (and cycle stealing) is utilized.  The
advantage I might see to this method is that the screen could use 640x200
equivalent mode for all parts of the screen for which it is unecessary to
have maximum resolution and thus minimize the flicker.

David Albrecht

gnu@hoptoad.uucp (John Gilmore) (01/25/86)

In article <511@well.UUCP>, farren@well.UUCP (Mike Farren) writes:
> In article <877@h-sc1.UUCP>, breuel@h-sc1.UUCP (thomas breuel) writes:
> > WHAT I WOULD LIKE TO KNOW IS: is Commodore/AMIGA planning on
> > releasing a version of the AMIGA in which this problem has
> > been fixed (e.g. in which the monitor can be run at either
> > 60Hz or 70Hz)? Is there a hardware patch that can be applied
> > to current machines to solve the problem?
> 
>   The necessary fix would be fairly expensive. The biggest reason for the
> 640 X 200 limitation on each field is to reduce the bandwidth requirements...

There is a technical fix for video memory bandwidth problems, called
"video rams".  These are ordinary dynamic RAM chips which also have a
second access port which scans out a row of 512 bits serially based on
an input clock.  While this scanning goes on, there is NO interference
with the normal memory access.  Once per 512 bits, you must do a special
memory cycle to load a different row of bits into the shifter.  This gives
the CPU something like 99.8% access and the video 100% access.

For example, each row might be a line of a 512-wide screen.  If you need
N bit planes, you use N chips.  (These are 256Kx1 RAMs anyway, so you will
have at least 16 of them in a 68K-based system).  This does place some
constraints on how video memory is allocated but they can be lived with.

While video rams are more expensive than normal DRAMS, in a system with
the price of an Amiga, the added features (large # of bitplanes in the
display with no performance degradation) easily outweigh the cost
difference.

Of course, these can not be retrofitted into an existing design like
the Amiga; they need to be designed in from scratch.   A lot of
designers are skeptical about video rams, as I was, until I saw them
used to halve the access time of a frame buffer and reduce its cost
too.

-- 
# I resisted cluttering my mail with signatures for years, but the mail relay
# situation has gotten to where people can't reach me without it.  Dammit!
# John Gilmore  {sun,ptsfa,lll-crg,nsc}!hoptoad!gnu    jgilmore@lll-crg.arpa

farren@well.UUCP (Mike Farren) (01/26/86)

In article <633@edison.UUCP>, dca@edison.UUCP writes:
> Huh? obviously I am missing something here.  It seems to me that by making
> each pixel 2 lines high we have just created a screen that will hold only
> 640x200(virtual) pixels.  I would imagine that the 640x200 essentially does

   (The discussion was about plotting 2-high pixels in the 640X200 mode)
   No, you don't have 640 X 200 virtual pixels.  You have 640 X 399 screen
locations which can hold a pixel, which pixel is two lines high. For example:

Screen lines -->  X.........   Note the pixels are composed of two dots (what
                  X..X......   are normally called pixels), and that adjacent
                  ...X..X...   pixels can overlap by one line.  This means 
                  ......X...   that the ONLY structures on the screen which
                               will lose resolution are those which are 
made up of only one vertical dot.  I would like to see someone construct
a high-res font which uses this principle - I think it would look GREAT!

-- 
           Mike Farren
           uucp: {your favorite backbone site}!hplabs!well!farren
           Fido: Sci-Fido, Fidonode 125/84, (415)655-0667

preece@ccvaxa.UUCP (01/27/86)

> Huh? obviously I am missing something here.  It seems to me that by
> making each pixel 2 lines high we have just created a screen that will
> hold only 640x200(virtual) pixels.  /* Written  8:27 am  Jan 24, 1986
> by dca@edison.UUCP in ccvaxa:net.micro.amiga */
----------
You have a little of each.  There are 399 possible pixel locations,
since the upper half of the double-height pixel can be on any line
except the bottom line. But, the screen is only 200 pixels high.
What you do about overlapping pixels has not been described in anything
I've seen here -- I suppose the later plotted pixel would overwrite
the earlier.  You could probably use this trick, with cleverly
designed fonts, to get 25x80 characters that were better than the
standard IBM color adapter but not as good as a Mac.  This might be a
reasonable compromise.  On the other hand, if I were designing a
text oriented program for a machine I knew to have 400 lines of
vertical resolution, I would want to use more than 25 lines of
text, sacrificing some text quality for quantity.  The main problem
with current text screens, on personal computers or terminals,
is that you can't get enough on them to make windowing really
useful.  The tall pixel idea really doesn't do anything to make
the Amiga better suited for answering that problem.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms

breuel@h-sc1.UUCP (thomas breuel) (01/28/86)

||Huh? obviously I am missing something here.  It seems to me that by making
||each pixel 2 lines high we have just created a screen that will hold only
||640x200(virtual) pixels.  I would imagine that the 640x200 essentially does
|
|   (The discussion was about plotting 2-high pixels in the 640X200 mode)
|   No, you don't have 640 X 200 virtual pixels.  You have 640 X 399 screen
|locations which can hold a pixel, which pixel is two lines high. For example:
|
|Screen lines -->  X.........   Note the pixels are composed of two dots (what
|                  X..X......   are normally called pixels), and that adjacent
|                  ...X..X...   pixels can overlap by one line.  This means 
|                  ......X...   that the ONLY structures on the screen which
|                               will lose resolution are those which are 
|made up of only one vertical dot.  I would like to see someone construct
|a high-res font which uses this principle - I think it would look GREAT!

It may look GREAT, but it will not solve the problem I posed originally:
you won't be able to get twice as many characters vertically in the
interlaced mode. To get lots of information on the screen, you NEED
640x400 without any constraints or tricks, and without any flicker.

						Thomas.

Felton.PA@Xerox.COM@caip.RUTGERS.EDU (01/28/86)

From: Felton.PA@Xerox.COM

> The limitation is the number of
> bytes you're shoving through the graphics hardware every frame, and I
> would believe that med-res mode on the Atari cuts the number of colors
> displayable in half?  Twice the resolution = half the colors = same
number
> of bytes/line.


	The above is incorrect. One of the things I have always liked about
changing word sizes is the fact that as you add digits linearly your
range of representable values grows geometericly. If you add one bit to
a three bit word you get a net gain of eight combinations (8
combinations for a three bit word and 16 combinations for a four bit
word). But, If you add one bit to a four bit word you get a net gain of
16 combinations (16 combinations for a four bit word and 32 combinations
for a five bit word).  The same effect is true for screen memory. Each
bit plane added to the screen memory doubles the number of colors that
may be display. This is true regardless of what percentage of the total
screen memory that one bit plane makes up. 
	 Resolution, on the other hand, does not work this way. Inorder to
double the resolution (display twice the number of pixels on the screen)
one must double the screen memory (not just add another bit plane, as
with doubling the number of colors).  In order to double the screen
resolution the size of the bit planes must be doubled. In order to
maintain the same display bandwidth (same screen memory size) this
results in the need to cut the number of bit planes in half.  With the
example sighted above doubling the resolution required reducing the
number of bit planes from 4 to 2. Lossing 2 bit planes means cutting you
color selection to 1/4 of its original size. Thus, the atari ST displays
16 colors in low resolution color mode and 4 colors in high resolution
color mode.
	 

John

p.s. Sorry if this simple minded discussion of bit planes bored you. As
for my self, I find it fascanating.

mykes@3comvax.UUCP (Mike Schwartz) (01/28/86)

In 640 x 400 mode, plotting pixels 2-tall yields 399 vertical positions.
Consider the following illustration:


 line1 | x
 line2 | x  x
 line3 |    x  x
 line4 |       x

 This illustrates positioning 3 2-tall pixels at different vertical positions.

 In order for there to be only 200 vertical positions, the pixels would be
 plotted like this:

 line1 | x
 line2 | x
 line3 |   x
 line4 |   x
 line5 |     x
 line6 |     x

 In other words, in interlaced mode, plot the pixel at the point you
 would normally plot, plus the point below (or above) it.

cem@intelca.UUCP (Chuck McManis) (01/29/86)

> ...
> some discussion about bits vs combinations etc
> ...
> 
> 	 Resolution, on the other hand, does not work this way. Inorder to
> double the resolution (display twice the number of pixels on the screen)
> one must double the screen memory (not just add another bit plane, as
> with doubling the number of colors).  In order to double the screen
> resolution the size of the bit planes must be doubled. In order to
> maintain the same display bandwidth (same screen memory size) this
> results in the need to cut the number of bit planes in half.  With the
> example sighted above doubling the resolution required reducing the
> number of bit planes from 4 to 2. Lossing 2 bit planes means cutting you
> color selection to 1/4 of its original size. Thus, the atari ST displays
> 16 colors in low resolution color mode and 4 colors in high resolution
> color mode.
> 	 
> John
> 
> p.s. Sorry if this simple minded discussion of bit planes bored you. As
> for my self, I find it fascanating.

You will note John that a common 'double' the resolution interpretation is
to double *both* X and Y resolutions. This actually displays 4 times the 
number of pixels on the screen. Now in the case of the Atari and the Amiga
they 'double' the resolution from 320 X 200 by only doubling the X direction
to 640. This does not help a lot of graphics applications that would really
like reasonably square pixels. The Amiga will display 640 X 400 (bringing 
it much closer to the 3:2 aspect ratio (or is it 4:3?) of the 'standard'
CRT, to a lot of people this is the only interpretation of the term when
applied to raster displays. Interestingly, the Amiga still displays 16
colors/pixel because it also cuts the bandwidth requirements in half.

--Chuck


-- 
                                            - - - D I S C L A I M E R - - - 
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}

farren@well.UUCP (Mike Farren) (01/29/86)

In article <889@h-sc1.UUCP>, breuel@h-sc1.UUCP writes:
 [ after a discussion of using two-high pixels in 640X400 mode]
> It may look GREAT, but it will not solve the problem I posed originally:
> you won't be able to get twice as many characters vertically in the
> interlaced mode. To get lots of information on the screen, you NEED
> 640x400 without any constraints or tricks, and without any flicker.

    Yes it will.  Example (two versions of a slash):

     ........                    ......X.
     ......X.   One high pixels  .....XX.  Two high pixels.
     .....X..        |           ....XX..  (Note - only ONE pixel
     ....X...   <----            ...XX...  height difference!)
     ...X....                    ..XX....
     ..X.....                    .XX.....
     .X......                    XX......
     X.......                    X.......
In short, there is NOTHING that says that the two-high pixels must start
on an even line. The only thing you have to do is to ensure that no pixel
"stands alone".

-- 
           Mike Farren
           uucp: {your favorite backbone site}!hplabs!well!farren
           Fido: Sci-Fido, Fidonode 125/84, (415)655-0667

ewhac@well.UUCP (Leo L. Schwab) (02/06/86)

x.UUCP>
Sender: 
Reply-To: ewhac@well.UUCP (Leo L. Schwab)
Followup-To: 
Distribution: 
Organization: Whole Earth Lectronic Link, Sausalito CA
Keywords: 


[ gulp! ]

	As a new poster to this newsgroup, I'm getting somewhat puzzled
by all this "discussion" on why interlace mode on the Amiga does/doesn't
suck rocks.

	Why don't you all just face it:  We all have different eyes and
perceive flicker (or lack thereof) to different degrees.  Yes, 640 x 400
on the Amiga flickers, but depending on who you are, you may not care.

	Personally, I say, "ICK!" to myself when I first turn on interlace
mode, but then after a few minutes, my eyes glaze over and I hardly
notice it.  This is just me though.  J. Random User may not think so (and
by the discussion going on here, it's obvious that everybody doesn't
agree).

	Personally, I like to think of 640 x 400 as being reserved for
"CAD only" type applications.  You know, the kind of application that
absolutely requires the highest resolution available.

	People also seem to complain about the character set being just
this side of unreadable.  Again, this is subjective, and when it becomes
possible to change the system font, it will become a moot point.

	Why don't we all just agree to differ on this point and move
on to more interesting things (like the Boing Wars :-)?

					Leo L. Schwab
					well!ewhac
					dual!unicom!schwab