Here is a collection of notes from the AA project. Some of these bugs have been
fixed.

Known AA bugs:

o Blitter problems in 7 bitplane 35ns modes. The cause of this is unknown, but
there are no software ramifications. It's a pure Chip bug.

o VBlank seems to be starting one line too early, and finishing one line too
early. This has to be proved to be a Chip bug by the chippies, but it does
appear to be so.  The problem only exists for programmed Beam Sync modes.
Leaving this problem unsolved causes a few problems:

1) A single line at the bottom of the display which is in colour 0 of the
highest screen in the display (ie, the colour set up in copinit).

2) The top line of one of these displays is not visible, but is hidden in the
vertical blanking region.

Both of these are cosmetic problems.

3) Because of this, the WaitTOF() code seems to be confused into thinking vblank
has finished when in fact it hasn't. For example, switching from a NTSC
interlaced screen to a VGA Productivity screen can cause the display to be
blank, even though an examination of the copper lists shows no problems. I have
sort of worked around this by altering the characteristics of the monitor in the
monitor's TOOLTYPES to start vblank one line early (the last line of the
display), and finish one line early. However, I consider this to be a temporary
kludge, especially as this seems to cause problems when some of the monitors are
used in interlaced mode.

[THIS WORKAROUND IS STILL IN PLACE, AS THE BUG WAS NEVER FIXED]

o FMode not reset at power up. This is relatively harmless, as all AA systems
will ship with 3.0 which resets the fmode properly. However, anyone with a AA
system that decides to power up into 2.0 (eg with an old devs:kickstart) will
get two pointers.
[I THINK THIS WAS FIXED]

o BPRUN problems: With R1 of Alice, 16 and 32 cycle modes (Hires 4x, Lores 2x
and Lores 4x) were holding the internal BPRUN line for too long. In the 32
cycle, this ran on through to the next line and confused the internal chip
state machine (the chippies could tell you better than I can what the problem
was). This they have 'fixed' in the R2 Alice by terminating BPRUN after the 16th
cycle of the 32 cycle for the last fetch. However, this does not fix the other
problem which is this - When horizontally scrolling a large screen that is
overscanned all the way to the far right, I need to set the DDFSTOP value to
0xd8 in the 16 cycle, and 0xc8 for the 32 cycle. Taking the 0xd8 case, if BPRUN
were to end after the 16th cycle (as it currently does), then BPRUN runs through
until cycle number 0xe8, which is greater than the magical number 0xe2, the
number of cycles in a standard NTSC or PAL display. This confuses the chip's
state machine. However, if BPRUN were to end after the 8th cycle (which is all
that's needed to fetch all the data), then BPRUN finishes at cycle 0xe0, which
is legal. This is similar for the other case. The consequence of not being able
to set the DDFSTOP value as far as I need is that in a scrolling NTSC screen
overscaned to the far right, at certain horizontal positions, a vertical bar of
the background colour is displayed instead of the bitplane data. This is
visually ugly, and may have software problems if some gadgets are in that area
which the user is unable to see. There are 5 possible solutions:

1) Ignore the problem, and live with it.

2) Restrict the overscan value of Lores 4x and 2x modes, and Hires 4x modes.
This is not very acceptible for people using Amigas for Video work and would
really like the extra colours and/or bandwidth.

3) Sniff out when the screen is in one of these 'bad' positions, and coarse
scroll. This is ugly, and not very useful for animators.

4) Drop the bandwidth at those positions. We are already doing this at certain
positions to hide a similar problem at the left hand side, only we are greatly
enhancing the possibility of having to drop the bandwidth invisibly on a user.

5) Fix Alice.
[ALICE FIXED IN REV3]

o Because of the way the datafetch engine works, when displaying a ViewPort in
a high bandwidth, I have to set DDFSTRT earlier than I used to with the the ECS.
This causes the following problems and solutions:

1) NTSC/PAL 16 or 32 cycle - when overscanned to the far left, and at certain
positions (such as when horizontally scrolling) I would need to set DDFSTRT
earlier than 0x18, which I cannot do.  This leaves a band down the left hand
side of the background colour. The solution to this is to drop the bandwidth at
the appropriate time to give me finer control over DDFSTRT.

2) Programmed BeamSync modes - for all resolutions in 2x or 4x modes, AND 70ns
and 140ns 1x modes (ie ECS too!), we have a similar problem to part 1).
However, here we cannot always drop the bandwidth.  For example, a 8 bitplane
Productivity screen MUST be 4x, and so the bandwidth cannot be dropped.  The
solution here is to coarse scroll the ViewPort horizontally so that the blank
band is never seen, which looks ugly and doesn't feel as natural as the fine
scrolling.

These two problems could be even greater in an 8x system, in which even a
Productivity screen of a default size and positioned as far right as possible
may not be able to display all the pixels.
[STILL EXISTS]


o In Alice R2, setting the H0 bit of DIWHIGH (bit 11) will cause the display
window to remain open through to the bottom of the screen. This limits our
ability to close the display window horizontally to a 70ns resolution instead of
the intended 35ns resolution.

[From Bill.T]		I think I know what happened.   We only changed
bit 3(start value) of DIWHIGH---apparently we should have changed bit
11 also(stop value).  Since bit 11 is tied the vertical window stop
comparator, when you set bit11 high the comparator never matches and
doesn't stop the display.  Surprised we(DESIGN ENG.) didn't notice that
bit11 should have been disabled also.
[FIXED]


Wed Apr 22 12:10:18 1992
------------------------
Latest status of AA bugs:

1) Sprite colour problem turned out to be s/w! The default 'NULL' sprite was not
set up properly for 4x sprites.

2) 7 bitplane BBUSY problem - a solution has been found on the motherboard and
appears to work.

3) VBlank problem - confirmed CHIP bug. I need to sit down with Bob and find a
satisfactory work around.




---------------------------------------------------------------------------------
VBLANK:

Return-Path: <grr@cbmvax>
Received: from cbmvax.cbm.commodore.com by sleeponit with
   Amiga SMTPd#00783; Fri, 15 May 1992 15:42:40 EST
Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore 2/8/91)
	id AA01489; Fri, 15 May 92 15:45:15 EDT
Date: Fri, 15 May 92 15:45:15 EDT
From: grr@cbmvax (George Robbins)
Message-Id: <9205151945.AA01489@cbmvax.cbm.commodore.com>
To: bthomas, raible
Subject: Interlace Problems Explained
Cc: chrisg, daveh, spence

Looks like we've finally nailed this one...

implemented completely in Paula and occurs when the RGA codes (strobes)
indicate start of vertical blanking.

This has a number of consequences:

1) In interlace mode were VBSTRT is set the same as VTOTAL+1, the
   start of blanking strobe only occurs on the long field, so VBLANK
   interrupts only occur on long fields.

   This tricked the software types into believing that LOF wasn't
   toggling, since they only looked in the VBLANK interrupt routine
   and therefore only on one field.


   and the LOF flip-flop toggles between the last line and the first
   line, the sense of LOF that the software reads flips when VBSTRT
   occurs before or after the last/first line.

   This is why there was confusion about which modes required copper
   lists to be flipped field-for-field and also perhaps which modes
   showed the problem in the first place.

   Also, there is a potential problem in that when the VBLANK interrupt
   service is delay by blitter activity or other distractions, it will
   occasionally read VPOSR after it has flipped and pick the wrong field
   intermittently.

   To guard against this, the sofware must invert the sense of LOF when
   they would expect it to have the pre-last/first line value but the
   vertical position bits in VPOSR indicate that they didn't actually
   read it until a few lines later.

I don't know if there are any other issues involved or explained by
these details.  I still think that the hardware implementation is
bogus, since it doesn't track LOF for interlace, but it looks like
there should't be any serious problem with the copper list kludge.

I'm a little confused about the Copper action - I though it maintained
interlace operation without processor intevention, but it appears that
that processor needs to stick alternating copper list addresses in
COPJMP1 once per field to make things work right.

In any case, the copper restart occurs after the last line of the
field and is not influence by VBLANK issues.  On the other hand,
missing VBLANK interrupts would inhibit the software from providing
the alternate address, causing an apparently non-interlaced display.

						George
Return-Path: <grr@cbmvax>
Received: from cbmvax.cbm.commodore.com by sleeponit with
   Amiga SMTPd#00784; Fri, 15 May 1992 16:34:13 EST
Received: by cbmvax.cbm.commodore.com (5.57/UUCP-Project/Commodore 2/8/91)
	id AA05549; Fri, 15 May 92 16:36:59 EDT
Date: Fri, 15 May 92 16:36:59 EDT
From: grr@cbmvax (George Robbins)
Message-Id: <9205152036.AA05549@cbmvax.cbm.commodore.com>
To: bthomas, raible
Subject: oops, on interlace...
Cc: chrisg, daveh, spence

Oops, I edited away a line of the message -

it should start by saying:

The "Agnus Frame Interrupt" aka VBLANK interrupt...

Anyway it's kind of amusing -

Of the three "Agnus" interrupt sources, Blitter, VBLANK and Copper,
only the Blitter interrupt is implemented in Agnus, with the
interrupt request reflected on the "INT3" line going to Paula.

The VBLANK is done in Paula off RGA strobes, the "Copper Interrupt"
is done by copper programming setting a "reserved" bit in the
interrupt request register.

Means "Read the Fine Print" I guess...

Chris also explained the automatic copper list switching to me.
One of the instructions in each copper list loads the starting
address of the other in the COP1LC pointer so that the copper
restart will automatically alternate between the two.  All the
software has to do is kick them off the right way when a new
copper list has been provided.

This means that a number of the concerns I mentioned aren't
causing us problems...

					George

