Conference hydra::amiga_v1

    the only real solution is one of these new hardware frame do-dabs
    (love those tech terms ;-)....but
    
    try either adjusting down the brightness (basically what those filters
    do for you) or playing with the color combos so the change in
    brightness level isn't as great...the colors on the vt100/200 interlace
    screen (from the init file) aren't too bad for text, but I never
    could find a set of 4 I'm happy with for the wokbench.
    
    scott.
    

    There's a third option, still rather expensive...
    
    Electrohome makes a fantastic long-persistance monitor that can
    be had for around $750.  The Software Shop also stocks a long-pers.
    monitor whose name slips my mind right now.
    
    I've seen the Electrohome, and there's no trace of flicker in 400
    line mode, even using the default (high contrast) colors.
    
    I used to have a file from PLINK that include a half dozen or so
    color settings that minimized 400 line flicker.  It worked fairly
    well, but some of the colors were a bit much, like red text on a
    green background, etc.
    
    One hint for selecting colors:  All the color sliders for each color
    register (0-3) should be hovering within the center 1/3 of the slider
    range.  This ensures that no one color will be in severe contrast
    with any other.
                                            
    Ed.

Re: .0

I tried one of the screen filters for a while.  I decided it wasn't
a practical approach.

The reason why you see flicker on a 400 line Amiga interlaced display but
not a 200 line Amiga display has to do with the workings of your eye.  Both
the 200 line display and the 400 line display are rapidly pulsing on and
off, but in the case of the two hundred line display the monitor is
redrawing it before your eye can react to the decayed image.  In the case
of the 400 line display, it takes the monitor twice as long to redraw
the same line of the display, and your eye has time to notice that the
line has gone dim.

Different individuals eyes work at different rates.  Thus, some people
violently object to flicker that others find only a slight problem.
Under different conditions, the same person may have a greater or lesser
sensitivity to flicker.  If your eyes are dilated, they gather more light,
and react more slowly to changes in light.  Thus dimming the monitor,
wearing glasses, using a screen filter, all cause your eye to dilate,
and notice the flicker less.  Unfortunately, this also causes eye strain.

The workable alternatives seem to speed up screen refresh (ala FlickerFixer)
or to slow down the decay of the image on the screen (by using a long
persistence phosphor).

Re: 1224.7

>    The whole topic of a display stealing buss bandwidth is a bit
>    confusing.  For example, would a Mac ][ using a 640 x 480 x 8 plane
>    (256 colors) run slower than the same Mac ][ using a single bit
>    plane?

Not necessarily.  For example, an Amiga displaying a 640 x 200 x 1
images is not slower that an Amiga displaying a 640 x 200 x 2 image.
However, an Amiga without expanded memory is displaying a 640 x 400
x 4 image is slower than an Amiga displaying one of the previous
resolutions.  The answer to your question depends on the architecture
of the machine.

There are actually two different limits being discussed here.  The
first is total memory bandwidth.  This is the total amount of memory
that can be accessed for any purpose during some given unit of time.
If in order to display a certain resolution you need to consume memory
faster than the total bandwidth, you just can not display that resolution.

The second limit is how much memory bandwidth is reserved for the
use of the video display system.  This number requires a longer
explanation.  The Amiga's memory system runs at twice the speed
of the 68000.  This means that in between every access of memory by
the 68000, you could have some other piece of the Amiga hardware
access memory and the processor would never notice--the memory
would still be available to the 68000 every time it wanted it.
The Amiga display hardware is other major consumer of memory
bandwidth in the Amiga.  Normally, it accesses the memory in
those "in-between" times when the 68000 cannot access the memory.
This means that most Amiga resolutions do not slow down the
machine at all.  On the other hand, other resolutions require
so much memory that the Amiga video hardware can not access it
all in video hardware's reserved time slots.  So, in order to
drive the display, the video hardware steals cycles from the 68000.
So, if the video hardware is cycle stealing, and the 68000 tries
to access chip memory, the 68000 will stall waiting for a free
memory access slot to become available.

>            Or is this issue unique to the Amiga with it's dual buss
>    design...

The above discussion isn't unique to the Amiga.  Every computer
with a bit mapped display system has to solve the problem of
how to make memory available to the display system and the
CPU fast enough that both are able to run.  For example the
Atari ST has the same basic design here:  Memory runs at twice
the processor speed and the video system accesses memory in-between
68000 accesses.  However, the ST avoids the problem of cycle stealing
by not supporting any resolution that would cause cycle stealing.
The Amiga people instead invented the dual bus design to make
cycle stealing not a problem.

The Amiga designers wanted to support resolutions that cause cycle
stealing, but they didn't want to slow down the 68000 when cycles
were stolen.  So they added a second memory bus to the machine that
could not be accessed by the video system hardware.  This second
memory bus is were the expanded memory or "fast" memory of the
Amiga lives.  Since the video hardware can not access this bus,
it can never be in contention with the 68000 for access for this
memory: the 68000 can run at full speed regardless of what the
display is doing as long as the 68000 isn't accessing chip memory.

There is another solution to the general problem of memory bandwidth
for the CPU and bandwidth for the display.  There is another type
of ram available called "video ram."  Video ram is dual ported,
and allows two different accesses simultaneously.  Thus the CPU
and the video hardware can both use the memory without locking
each other out.  The problem with video ram is that it is expensive,
and typically you would only find enough video ram in a system
to hold one screen's worth of information.  You couldn't do the
Amiga style page flipping or double buffering.  This is where you
have two (or more!) displays' worth of information in memory and
cause one to be displayed as opposed to the other by simply
altering a pointer that tells the  video hardware where to
get its information from.

I believe that (at least some) of the Mac ][ display cards use
video ram.  I have seen announcements of VGA cards based on video
ram.  Its price relative to normal ram has been falling.

A next generation Amiga is a good candidate for using video ram.
The Amiga with its distinction between chip ram and fast ram
means that it could make judicious use of video ram.  A high
end Amiga could have all of chip ram be video ram and thus support
higher resolutions without having to use video ram everywhere 
in the memory map.

There is yet a third way to get memory bandwidth for the CPU and
display.  Increase the bus width.  The Amiga has a 16 bit bus.
The Mac ][ has a 32 bit bus.  This means that even if they used
the same speed memory chips that the Mac ][ would have twice the
memory bandwidth because it is delivering twice the number of bits
in parallel.  The memory bus game is a popular one for high
performance CPUs:  It is not unusual for a high performance 32 bit CPU
to bring in a 128 bit chunk from memory for each real memory access.
Then if the next memory access is to bytes in the same chunk,
the memory is already cached, and the memory box need not be
accessed.

    Thanks Randy.  As usual, your explanations are crystal clear, with
    no flicker whatsoever.
    
    Ed.

    another cheap flicker fixer method is to adjust the colors and then
    put the keyboard in your lap (1000 & 2000 only).  From 3 to 4 feet
    away from the screen doesn't flicker.
    
    -dave

    Thanks to All for your answers.  Randy, your tutorial on display
    memory is terrific.  Did you ever consider writing a book on AmigaDOS?
    Like maybe something in-between the beginner books and the developer's
    manuals?...just an idea.
    
    ...Tim ;^)

Re: 1237.0

>Question:
>     Are we doing anything to change our resolution which is currently 640
>X 400 interlace?
>
>Answer:
>     What we have going, which you will see real soon, is 640 X 400
>non-interlace.  We are aware of at least the general publics' desire to go
>beyond that. There were many things shown at Comdex.  
>There were other types of monitors and technologies shown by third
>parties.We are definitely working on it, but I have nothing to tell you
>specification wise.

Well, it looks like I have may been to quick in writing off non-interlaced
400 scan lines.  However, all the stuff in 1227.4 still holds, and allows
us to make some predictions about a 400 line non-interlaced display.

Here's a table showing how much memory bandwidth is being consumed by
the Amiga video hardware in various interesting resolutions:

Resolution	Colors	Bits/Frame	Cycle Stealing?
-------------	------	----------	---------------
320 x 200 x 4	 16	256000		no
320 x 200 x 5	 32	320000		yes
320 x 200 x 6	HAM	384000		yes
640 x 200 x 2	  4	256000		no
640 x 200 x 4	 16	512000		yes

Note that use of a 400 line interlaced display does not increase the
number of bits per frame that need to be fetched since the interlaced
display is really two 200 line frames.

The hardware reference manual states that the 320 x 200 x 6 resolution
steals 50% of the CPU's memory slots during video display time.  The
640 x 200 x 4 resolution steals 100% CPU's memory slots during video
display time.  (The CPU still gets a crack at chip memory during non-
display time, however.)

Thus, the 640 x 200 x 4 resolution is using the Amiga's memory bandwidth
to the maximum.  This means that no Amiga display mode can consume more
than 512000 bits to display a frame.

Lets look at the numbers for 400 scan line non-interlaced displays:

Resolution	Colors	Bits/Frame	Cycle Stealing?
-------------	------	----------	---------------
320 x 400 x 2	 4	256000		No
320 x 400 x 3	 8	384000		Yes (50%)
320 x 400 x 4	16	512000		Yes (100%)
640 x 400 x 1	 2	256000		No
620 x 400 x 2	 4	512000		Yes (100%)

So, the Amiga does have enough memory bandwidth to support non-interlaced
400 line displays, but the cost would be a great deal of chip memory
contention for the more interesting graphics modes.

I had thought that Commodore wouldn't go for non-interlaced 400 line
displays because the most interesting display modes are 640 by 400,
and that means you have a choice of only two levels of color support:
1 plane (two colors) and 2 planes (four colors).

The 640 x 400 x 1 display mode is no sweat in bandwidth (its the same
resolution as the Atari ST's high res).  However, very few Amiga
applications open one bitplane displays  (in fact, screen blankers
are the only ones I know of!).

The 640 x 400 x 2 is a very interesting display mode--its equivalent
to a 400 line Workbench screen.  However, it eats 100% of the memory
cycles during display time.   I thought that it was a pretty heavy
price to pay for what might become the most popular display mode.
On the other hand, due to the two memory bus design of the Amiga,
a machine with extended memory would allow the 68000 to run at
full speed from fast ram.

Note that only Amigas that have true extended memory would get the
benefits of the two bus structure.  The Amiga 500 upgraded to 1 meg
and the Amiga 2000 with its standard of 1 meg have no fast memory.
In those machines, the other 512k is really chip memory masquerading
as fast memory until the finial version of the fat Agnus comes out.
All of that meg of memory is on the chip bus, and thus suffers from
chip memory slowdown during cycle stealing.  Any memory above that
one meg, however, is on the processor bus, and immune to the slowdown.

    Re: .8
    
    Two more questions:
    
    1) I'm not sure of the relationship between the discussion of the
    upcoming "Fat Agnes" chip and the 640x400 interlaced/non-interlaced
    display.  Isn't the "Fat Agnes" supposed to allow addressing more
    than 1/2 meg of chip memory?  I've got 1 meg in my A500, so I guess
    I'll be able to get a "Fat Agnes" if I want it (her?).  Why would
    I want to do this?
    
    2) Kind of related to 1) but more specifically: I take it that whether
    interlaced/non-interlaced/"Fat Agnes"/"Slim Agnes", these enhancements
    won't get me 640x400 without flicker (even in two-color mode)? 
    I'm still using a 1080 monitor (which I dare not even >>think<<
    about upgrading.
    
    ...Tim 8^)

    re: .8
    
    Your analysis assumes that the screen is refreshed directly from
    memory.  If, instead, the high resolution monitor contained a 640
    by 400 by 12 bit dual-ported frame buffer, it could refresh itself
    from that while loading it from the CPU at the CPU's speed.  This
    is similar to using a long-persistence phosphor, but instead of
    an exponential decay curve you have a cliff.
        John Sauter

    I believe that this is the approach used by Mimetics and others
    in their RGB 'Truevision' frame buffers.  These frame buffers allow
    a 24-plane 640 x 480 image, similar to video boards for the Mac
    II.  By the way, Sculpt 3D will render images of this type; of course
    they can't be displayed using standard Amiga video hardware.
    

    re .-?
    
    Randy implies that you won't take a performance hit if you're running
    out of fast RAM even if you are using 100% of chip RAM bandwidth.
    
    That's not quite true, because devices like the blitter will also
    be blocked, and they have to use chip ram. Disk operations go through
    chip RAM as well (because they use the blitter). So even if the
    program is completely in fast RAM, you will take a performance hit.
    
    I would hope that the A3000 will use 32 bit RAM, and interleave
    it. Interleaving is a technique whereby accessing adjacent locations
    'hits' different banks of memory, so each one has more time to
    'recover'. (DRAMs are kind of like people -- you can work them
    fast but they need quite a bit longer to recoup for the next one!)
    
    Lots of applications don't do well with interleaving, because when
    two accesses in a row happen to hit the same bank, you are out of
    luck, and have to wait 'til the RAMs are ready. But video has beautiful
    properties that way -- you always know the next location wanted,
    and can therefore get it ready in advance.
    
    By the way, I would describe the Amiga screen modes in a more general
    way. The Amiga can support up to six bits per dot in 320 wide mode.
    This is true whether you're talking 64 colors (32 colors, each of
    which can be "halfbrite" or not) or dual playfield mode (where one
    set of 4 colors "covers" a screen behind it, for applications like
    a fixed instrument panel over a moving scene (a la flight simulator).
    
    In hires mode (640xwhatever) you can only get up to 4 bits per pixel.
    
    And when 100% of bandwidth is used, the time remaining is during
    horizontal refresh (the few microseconds when the electron beam in
    the CRT is moving back to the left and down in preparation for the
    next scan line and the much longer vertical refresh (the milliseconds
    it takes for the beam to move back to the top of the screen).
    
    If you've been using MOREROWS or any program that uses overscan
    beyond the standard (320 or 640) x (200 or 400) you will reduce
    the amount of free time the bus has still further. I don't think
    it would be very pleasant to use the Amiga in that fashion.
    
    Basically, for ultra-hires screens, the Amiga isn't going to be
    doing much animation. At least, not using the 68000 and existing
    blitter.
    
    dov

Re: .10

>    Your analysis assumes that the screen is refreshed directly from
>    memory.

Yes.  My analysis was based on the idea of an upgrade to the custom
chips.

>        If, instead, the high resolution monitor contained a 640
>    by 400 by 12 bit dual-ported frame buffer, it could refresh itself
>    from that while loading it from the CPU at the CPU's speed.

Yep.  This is what the FlickerFixer and the 1008 x 800 Commodore monitor
do.

Re: .11

I was going to mention that floppy disk DMA is done to (from) chip memory,
and that the blitter then decodes (encodes) the raw MFM flux changes,
but I ran out of steam.  I am not sure how many memory cycles are allocated
to the special chip DMA ports.  It is possible that you could input
and output the MFM without penalty, but get hit in the blitter encoding
decoding.

Of course, DMA hard disks would be unaffected because they have their
own DMA channels that speak to fast ram, not chip ram.

>    If you've been using MOREROWS or any program that uses overscan
>    beyond the standard (320 or 640) x (200 or 400) you will reduce
>    the amount of free time the bus has still further. I don't think
>    it would be very pleasant to use the Amiga in that fashion.

Yep.  Some of the people using MoreRows have pushed the bitplane DMA
cycle stealing past the 100% number.  This causes the video refresh
to eat into sprite DMA time.  Thus, they can't use all the hardware
sprites.

>    Basically, for ultra-hires screens, the Amiga isn't going to be
>    doing much animation. At least, not using the 68000 and existing
>    blitter.

True.  That is why I was dubious about 400 scan line non-interlaced
displays.  But then again, it doesn't seem so bad sitting in
DeluxePaint with 100% cycle stealing.  But then I don't have
lots of text scrolling in windows (a blitter intensive operation)
while sitting in DP either.

Re: .9

Agnus is the Amiga special chip that among other things is responsible
for managing non-extended memory.

The Amiga address map reserves the first two meg as "chip ram."  However,
no Amiga (not in a Commodore lab, at least) can have that much chip ram.

When the Amiga 1000 came out, Commodore announced that although they
were reserving up to two meg for chip ram, the current model of the
Amiga would only be able to address 512k of chip ram.  This 512k limit
is a consequence of the original Agnus chip in the Amiga 1000.

When the Amiga 500 and Amiga 2000 model B came out, a slightly improved
Agnus chip was released.  Although this chip could actually manage
one meg of memory, because of limitations in its design, only 512k of
that memory could really be used as chip memory.  The other 512k was
not accessible as chip memory, but could be used my the 68000 as
general purpose memory.

That other 512k is pretty interesting.  It is controlled by Agnus, is
on the chip memory bus, but can not be used as chip memory.  And unlike
memory that lives on the processor bus, that non-chip memory does
experience a slow down during cycle stealing.  It is sometimes referred
to as "half-fast" memory or "slow" memory.

The workbench utility "SlowMemLast" is designed to alter the Amiga's
memory allocation strategy so that half-fast ram is the last to be
allocated by the system.  If you have true fast ram (by buying a
two meg board, for example), this utility will cause the operating system
to try allocating non-chip memory from the true fast ram first before
allocating the half-fast ram.  This allows you to make maximum use
of Amiga's dual bus structure in order to avoid as much memory contention
as possible during memory intensive display modes.

The Agnus chip in the 500 and B2000 is called Fat Agnus, although that
name was originally coined for an Agnus that would allow you to address
more than 512k of CHIP ram.  Even though that Agnus doesn't fully do
that job, the name stuck.  I don't know what people call the real
Fat Agnus; maybe they call it "the real Fat Agnus".

It has been unofficially acknowledged by Commodore that the fake Fat 
Agnus will be upgraded to the real Fat Agnus in Amiga 500s and Amiga
2000s model B.  When that happens, the 512k of half-fast memory will
be relocated to the chip memory addresses, and will become true fast
memory.  The Amiga 2000 even has a jumper on the motherboard to
accomplish this task.

Unfortunately, the Amiga 1000 and the Amiga 2000 model A will probably
not be able to upgrade to the true Fat Agnus.  The skinny Agnus in the
1000 is a different size and shape from the fake Fat Agnus in the 500/B2000.
(The Amiga 2000 model A was a model sold for a very short time in
Europe.  All American 2000s have always been model Bs.  All the European
2000s since spring have been as well.  Its easy to tell a model A
because it has a memory card stuck in the processor expansion slot.)

Why get upgrade to a true Fat Agnus?  Having one meg of chip ram
means that you can do more of the things that require chip ram
simultaneously:  open more screens, have more windows, AddBuffer
more floppy buffers.  Since once I got extended memory, I haven't
run out of chip ram, I don't think that this is too big a deal.

Anyway, simply having a fatter Agnus doesn't do a thing about
interlace flicker.

If a future version of the Amiga chip set supports a 640 x 400 x 1
non-interlaced display, you won't have flicker but you will run slow.

>    I'm still using a 1080 monitor (which I dare not even >>think<<
>    about upgrading.

Probably any method of getting a 400 line non-interlaced display
would require a multisync type monitor.  Sigh.

    re .15
    
    > 640 x 400 x 1
    
    will not cause any contention. This is the same bit rate as
    640 x 200 x 2 (the standard workbench screen). I think what Randy
    meant to say was 640 x 400 x 2 (60% contention).
    
    dov

    After reading all the other answers, I would spend the $565 for
    a Flicker Fixer!  (I did and it works fine.)
    				
    						Cheers,
    						Rick Burwen

I just ordered a flickerFixer from Creative Computers.  I don't have the toll
free number handy but they always advertise in Amiga World.  Their toll number
is 213-542-2292.

They claimed they would beat any price, and they did.  The cheapest price I 
could find was Abel @ $378.  CC sold it to me for $375+ ($5 for UPS 2nd day)
shipping.  A total of $380.  Not bad.

I don't know how I did without it.  It looks fantastic.  

If you do order one, remember that the flickerFixer has a 9pin D type 
connector for output, and you'll probably need a new cable.  Some NEC's use 
a 9 pin, but most need a custom cable of some kind.  The flickerFixer has a 
decent book describing the connectors for a wide variety of monitors, so you 
can build your own.

Steve - no commission :^(

    
    > I don't know how I did without it.  It looks fantastic.
    
    I've been telling people this for two years now.  An Amiga with a FF
    and multisync monitor provides the best computer display you'll ever
    see.
    
    At these prices, anyone with an A2000 should consider this an
    investment in their vision.
    
    Ed.

    But we are talking about a card that costs as much as an entire 
    monitor!  That's where I have trouble justifying it.
    
    What is it on that card that makes it so costly?
    
    regards,
    dennis
    

Re: .20

>    What is it on that card that makes it so costly?

I think that at one time the card was expensive to build because
of the 256K of high speed ram on it for the frame buffer.  I think
the price didn't fall because the product has no competition.