BRENNER_%DULRUU51.BITNET@cunyvm.cuny.edu (11/29/88)
You should read this if your Amiga is a PAL Amiga
The following problem has haunted us European Amiga users for a long time
now. Approx. once in 30 times the workbench screen won't open to the
(normal for PAL) size of 640x256 pixels. This is annoying when one's
startup-sequence contains commands to open a new shell to the full screen
size and close the initial 640x200 CLI-Window and end with a blank
workbench screen. Some people of the Bitnet distribution list Info-Amiga
complained too, so it's no problem of my machine. Investigations in
the graphics library showed me where the bug lies. The graphics library
containes a routine which determines by several reads of the vertical
beam position if those extra 56 lines exist, and returns a value containing
the information if the machine is a PAL or NTSC Amiga. A listing of this
routine follows (The adress is valid for Kickstart version 1.2/33.180 only):
Listing: original routine to distinguish between PAL and NTSC
fcb058:4eb9 jsr $fc5e62 ;Get vertical beam position
fcb05e:2200 move.l D0,D1
fcb060:0c80 cmpi.l #$0000010e,D0 ;beam position greater than $10e ?
fcb066:6f04 ble.s $fcb06c ;no, ->
fcb068:7004 moveq #$04,D0 ;yes, set PAL bit
fcb06a:6028 bra.s $fcb094 ;and exit
fcb06c:4eb9 jsr $fc5e62 ;Get vertical beam position
fcb072:2200 move.l D0,D1
fcb074:7264 moveq #$64,D1
fcb076:b280 cmp.l D0,D1 ;beam position greater than $64 ?
fcb078:6ef2 bgt.s $fcb06c ;no, try again ->
fcb07a:4eb9 jsr $fc5e62 ;Get vertical beam position
fcb080:2200 move.l D0,D1
fcb082:0c81 cmpi.l #$0000010e,D1 ;beam position greater than $10e?
fcb088:6f02 ble.s $fcb08c ;no, ->
fcb08a:60dc bra.s $fcb068 ;yes, set PAL bit and exit
fcb08c:7032 moveq #$32,D0
fcb08e:b081 cmp.l D1,D0 ;beam position greater than $32 ?
fcb090:6de8 blt.s $fcb07a ;yes, test again for >$10e ->
fcb092:7001 moveq #$01,D0 ;no, set NTSC bit
fcb094:4e75 rts
* Load vertical beam position into D0 (here lies the BUG)
fc5e62:2039 move.l $dff004,D0 ;read VPOSR+VHPOSR as longword
fc5e68:e080 asr.l #8,D0
fc5e6a:0280 andi.l #$000001ff,D0 ;9-Bit beam position into D0
fc5e70:4e75 rts
The problem lies in the read of the longword from VPOSR+VHPOSR. This
SHOULD give a value between 0 and $1ff. But what if the beam is at the
rightmost position of line $FF when the longword is read? Perhaps the
high word containing the ninth bit of the vertical position is read as
0 and then, after the counter advanced to $100 the low word is read
as $00xx, the high byte containing the lower 8 bits of the vertical beam
position. So a total value of 0 is read for the position which will result
in a run thru adresses $fcb08e, $fcb090 and $fcb092 and an erraneous
set of the NTSC bit.
As an alternative I propose the following routine (hope Multitasking is
off during this time) which works fine now for some time.
* New PAL/NTSC - Testroutine for Kickstart 1.2/33.180
* Aztec-C Assembler V3.4a
* (the following three lines are for my Kickstart changer)
DC.W $4AFC ;Magic Word
DC.L $FCB058 ;Startadress
DC.L Ende-Start ;Length in Bytes
Start:
MOVEQ #$04,D1 ;PAL is default, set PAL bit
WaitLoop1:
JSR $FC5E62 ;Get vertical beam position
CMP.B #$20,D0 ;Position == $20 or $120 ?
BNE.S WaitLoop1 ;no, wait ->
AND.W #$100,D0 ;Position == $120 ?
BNE Ready ;yes, it's PAL, -> Ready
WaitLoop2:
JSR $FC5E62 ;Get vertical beam position
CMP.B #$1F,D0 ;Position == $1F oder $11F ?
BNE WaitLoop2 ;no, wait ->
AND.W #$100,D0 ;Position == $11F ?
BNE Ready ;yes, it's PAL, -> Ready
MOVEQ #$01,D1 ;no, it's NTSC, Set NTSC bit
Ready:
MOVE.L D1,D0 ;Return the video type
RTS
Ende:
Last note: The bug is still present in Kickstart 1.3/34.5!
-Martin
@ @ ----------------------------------------------------------------------
===V=== "This message still Beta testing - don't blame me for bugs!" //
!^! -Martin (BRENNER_M@DULRUU51.BITNET) Uni Ulm/F.R.Germany \X/AMIGA
^ ^ ----------------------------------------------------------------------
%SYSTEM-W-POWERFAIL, power failure occurredditto@cbmvax.UUCP (Michael "Ford" Ditto) (11/30/88)
In article <5714@louie.udel.EDU> BRENNER_%DULRUU51.BITNET@cunyvm.cuny.edu writes: >* Load vertical beam position into D0 (here lies the BUG) >fc5e62:2039 move.l $dff004,D0 ;read VPOSR+VHPOSR as longword That's funny; I had the exact same bug in the corresponding routine I wrote for Unix. I fixed it by reading the words individually (VHPOSR first, then VPOSR); I was just waiting for them to become zero. When I mentioned to Andy that the graphics library's bug might be the same, he said it didn't matter since 1.4 already has a completely different method of deciding whether to be PAL or NTSC. Oh well, all your detective work for nothing. :-) -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
kkaempf@rmi.UUCP (Klaus Kaempf) (12/01/88)
In article <5714@louie.udel.EDU> BRENNER_%DULRUU51.BITNET@cunyvm.cuny.edu writes:
: containes a routine which determines by several reads of the vertical
: beam position if those extra 56 lines exist, and returns a value containing
: the information if the machine is a PAL or NTSC Amiga.
But what is the 'line frequency' pin from the power supply good for ??
Doesn't the Amiga check that line to decide if it should display PAL (50Hz)
or NTSC (60Hz) ?
I know for sure that the line frequency is checked during boot-time, since
if you cut this line, your Ami won't boot !
Klauslphillips@lpami.van-bc.UUCP (Larry Phillips) (12/05/88)
> But what is the 'line frequency' pin from the power supply good for ?? > Doesn't the Amiga check that line to decide if it should display PAL (50Hz) > or NTSC (60Hz) ? I hope not. This would prevent PAL Amigas from being used in North America, and NTSC Amigas from being used in Europe. One of the common complaints from Europeans is that some (many?) programs developed in North America don't look right on PAL systems, but at least a few vendors have PAL Amigas to test with, and it has to help the situation a bit. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
kkaempf@rmi.UUCP (Klaus Kaempf) (12/07/88)
In article <1994@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes:
:
: > But what is the 'line frequency' pin from the power supply good for ??
: > Doesn't the Amiga check that line to decide if it should display PAL (50Hz)
: > or NTSC (60Hz) ?
:
: I hope not. This would prevent PAL Amigas from being used in North America,
: and NTSC Amigas from being used in Europe.
: Europeans is that some (many?) programs developed in North America don't
: look right on PAL systems, but at least a few vendors have PAL Amigas to
: test with, and it has to help the situation a bit.
:
: -larry
To clarify: PAL == 256 lines/frame, NTSC == 200 lines/frame.
PAL -> 50 Hz -> 25 frames/sec -> 6400 lines/sec
NTSC -> 60 Hz -> 30 frames/sec -> 6000 lines/sec
So both need about the same dma bandwith to display a standard picture. You
can't display 256 lines with NTSC, can you ??
By looking at the line frequency at boot-time, the amiga should decide
whether to display 200 lines (60 Hz, no dma-time for 256 lines) or
256 lines (50 Hz, no 200 lines please !).
Still puzzled,
Klausgay%elde.epfl.ch@cunyvm.cuny.edu (David Gay) (12/09/88)
In article <1329@rmi.UUCP> kkaempf@rmi.uucp (Klaus Kaempf) writes: >In article <1994@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) > writes: >: >: > But what is the 'line frequency' pin from the power supply good for ?? >: > Doesn't the Amiga check that line to decide if it should display PAL (50Hz) >: > or NTSC (60Hz) ? >: >: I hope not. This would prevent PAL Amigas from being used in North America, >: and NTSC Amigas from being used in Europe. The key phrase (I use an NTSC Amiga in Europe!). >:[...] >: -larry >To clarify: PAL == 256 lines/frame, NTSC == 200 lines/frame. > >PAL -> 50 Hz -> 25 frames/sec -> 6400 lines/sec >NTSC -> 60 Hz -> 30 frames/sec -> 6000 lines/sec > >So both need about the same dma bandwith to display a standard picture. You >can't display 256 lines with NTSC, can you ?? > No, therefore your NTSC Amiga in Europe (with line frequency = 50Hz) can't display 256 lines ... In the good (or bad ?) old days of 1.1, when the line frequency wasn't checked, the OS would suppose that it was 60Hz when you had an NTSC Amiga, thus the clock would be slow by a factor of 1.2. Of course, better that than trying to display 256 lines! >By looking at the line frequency at boot-time, the amiga should decide >whether to display 200 lines (60 Hz, no dma-time for 256 lines) or >256 lines (50 Hz, no 200 lines please !). > >Still puzzled, > >Klaus Trying to muddy the waters, David Gay GAY@ELDE.EPFL.CH, or GAY%ELDE.EPFL.CH@CLSEP51.bitnet
lphillips@lpami.van-bc.UUCP (Larry Phillips) (12/11/88)
> To clarify: PAL == 256 lines/frame, NTSC == 200 lines/frame. > > PAL -> 50 Hz -> 25 frames/sec -> 6400 lines/sec > NTSC -> 60 Hz -> 30 frames/sec -> 6000 lines/sec > > So both need about the same dma bandwith to display a standard picture. You > can't display 256 lines with NTSC, can you ?? NTSC is 262.5 lines per frame, 525 lines per field, ( I may have 'frame' and 'field' mixed up here, never could remember which was which). Anyway, you cannot use the entire frame, because some of the lines are eaten by the retrace. Yes, you can display more lines on a PAL monitor than you can on an NTSC monitor, but it doesn't matter, because.. > By looking at the line frequency at boot-time, the amiga should decide > whether to display 200 lines (60 Hz, no dma-time for 256 lines) or > 256 lines (50 Hz, no 200 lines please !). .. the line frequency and the vertical frequency of the monitor are completely separate things. The only reason you can't get much use out of a PAL television set in North America is because there are no TV stations broadcasting in that standard. You can, however use a PAL VCR here, feeding a PAL TV, and similarly, you can use a PAL Amiga with a PAL monitor here, where the line frequency is 60 Hz (and it's a bitch to get the power company to change it for you :-) ) There are two things to look at, therefore, the line frequency, which will determine the clock updates, and the vertical frequency, which will determine the number of lines you can show on screen. There are a couple of entries in the ExecBase struct that tell you what both of these are on the machine you are running, but I hesitate to point them out, for fear that Leo will tell me I'm wrong again, without saying why. > Still puzzled, Hope this clears it up for you. > Klaus -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------+ | // Larry Phillips | | \X/ lpami.wimsey.bc.ca!lphillips or van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
dale@boing.UUCP (Dale Luck) (12/14/88)
In article <1329@rmi.UUCP> kkaempf@rmi.UUCP (Klaus Kaempf) writes: > >By looking at the line frequency at boot-time, the amiga should decide >whether to display 200 lines (60 Hz, no dma-time for 256 lines) or >256 lines (50 Hz, no 200 lines please !). The amiga software does not decide whether to display 200 lines or 256 lines. The particular version of the agnus chip tells us that. It it NOT coupled to the line frequency. Also there is no line frequency pin on the A500. The real time clock get's it's timing from the same circuitry that generates video syncs. So genlocks have a tendency to really screw the timing of an a500 if vsync ever strays from 60/50 hz. > >Still puzzled, > >Klaus -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale