[comp.sys.atari.st] TOS 2.05 bugfix

larserio@IFI.UIO.NO (LarsErikOsterud) (04/08/91)

While testing out my new MEGA STE i discovered a nasty bug in one
of the Xbios routines (I can't understand why no beta-tester has).

The XBIOS 5 call  setscreen(logadr,physadr,resolution)
is used to set screen adresses and change screen resolution.

However, calling setscreen with -1 as resolution doesn't change
the current resolution.  On monochrome many programs still call
the setscreen function with 2 (monochrome) as resolution and
this works OK on older ST's, BUT on the MEGA STE's TOS 2.05 
strange things happend :-(

The routine does NOT wait for vertical blank as it i supposed to
but resets the video in the middle of the screen, causing the
picture to wrap around the left edge of the screen in 50% of
the cases.  This does not look good (you get the edge of the
grapic screen in the middle of the monitor screen :-)

To get around this problem I have made a VERY small program that
hooks on to the XBIOS 5 if in monochrome, and always sets the
resolution parameter to -1 (no change).  Then things work OK !!

I would like an offical comment from Atari Corp on this bug !!!!
How i the world could this pass through the beta-testing ????
In only one day I found 10 programs that goes mad because of it.

table
 !"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 tos205fx.arc
M&@A43U,R,#5&6"Y04D< W    (@6$W98%/0    ,8#0 @#1 VL ) 0   &,#z
MBQ I01P:P3*0 ((+ !J8@> $#0,H  J8L1"#S[]_ !2 <<#@34@ !LP8^&$2y
M)807.OY9<U+G!P\ !)PXH?*( 1   LX0$'+&21 D>@#P\ D@@5,NCZ "P$#5x
MA%"L3%_\!!  !]483B/P@TF T A\ ' -'* @Q%J"#N+RW%!$ 0@05)Y, 2'#w
M!8P:(!PF$0P"<9LW;MZ,02/G39LR(,RDP=- @5\0O4 P"2-G3HLB<M*L 2%Kv
:#ITR<NJ0^1L$3FHV(&+DR!%C8 $]!@  &@! u
 t
end


 Lars-Erik  /  ABK-BBS +47 2132659  /   ____ ______ ________________________
  Osterud  /  larserio@ifi.uio.no  /   /___    /            The norwegian ST
__________/ ______________________/   ____/   /   Klubben,  user association

apratt@atari.UUCP (Allan Pratt) (04/12/91)

larserio@IFI.UIO.NO (LarsErikOsterud) writes:

>While testing out my new MEGA STE i discovered a nasty bug in one
>of the Xbios routines (I can't understand why no beta-tester has).

Maybe because it's not a bug.

>The XBIOS 5 call  setscreen(logadr,physadr,resolution)
>is used to set screen adresses and change screen resolution.

>The routine does NOT wait for vertical blank as it i supposed to
>but resets the video in the middle of the screen, causing the
>picture to wrap around the left edge of the screen in 50% of
>the cases.  This does not look good (you get the edge of the
>grapic screen in the middle of the monitor screen :-)

Thank you for starting a panic.  I think it is not a bug but a problem with
your Mega STe.  I can not reproduce the "bug" you report.  It might have
occurred to you that your Mega STe is to blame, not TOS.

Your lack of understanding of the reasons for the protection code in the
ROM has led you to a false conclusion.  To nip this in the bud, I'll
explain.  The shifter mode must not be changed during a critical moment
around vertical blanking.  Previously that was avoided by waiting for the
vblank interrupt, which ensures that the critical moment has passed.  The
new code uses another method: it checks to be sure that you are in the
middle of the screen someplace, not in vblank.  The upshot is the same: you
avoid the window of vulnerability.

If you had named the programs that caused trouble this would have been a
more useful bug report.  It is possible that there is an interaction
between those programs and the new code.  Please post or mail me the names
of those programs.

If this turns out to be a real live software bug, I will eat my words.

(Lars-Erik has responded to me in mail about the programs (e.g. Degas
Elite) and I have suggested that he return the machine to his dealer. This
posting is for everybody else, so you don't think we're totally out to
lunch when it comes to testing software.)

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt