non-system startup code time/clock problem - Page 5

dissident · 11 December 2018, 22:38

Quote:

Originally Posted by ross

Yes, I absolutely don't remember what was wrong.. too much time ago, but i'm sure that my PAL KS1.2(3?) machine seldom reported (line frequency, video frequency?

) wrong value(s).

Okay, what I can remember from the past is, that you couldn't drag the zize of the CLI window down to the bottom of a PAL display, because the system thought it was a NTSC machine. The only way was to do a reset and hope that the system was initialized as a PAL system after that. I also remember this problem was mentioned in several old issues of the German Amiga Magazin and they tried to solve it with some little tools published as listings. I will check this tomorrow, if there were any "new" solutions.

phx · 12 December 2018, 13:22

Quote:

Originally Posted by dissident

Okay, what I can remember from the past is, that you couldn't drag the zize of the CLI window down to the bottom of a PAL display, because the system thought it was a NTSC machine.

Yes. I rarely noticed, because I just worked with NTSC-sized CLIs. But you are right!

Quote:

I will check this tomorrow, if there were any "new" solutions.

Thanks. But as you confirmed that this problem really existed it is probably best to do all checks yourself, and to not depend on the OS at all.

dissident · 12 December 2018, 19:10

Quote:

Originally Posted by phx

Yes. I rarely noticed, because I just worked with NTSC-sized CLIs. But you are right!

Thanks. But as you confirmed that this problem really existed it is probably best to do all checks yourself, and to not depend on the OS at all.

Hi phx & ross. I was successful digging in my old "Amiga Magazin"'s and found an article about the gfx-library 1.x bug in magazine issue 11/1990, page 63:

General infos:
NTSC: 525 lines, 0 <= VBeamPos() <= 262
PAL: 625 lines, 0 <= VBeamPos() <= 312

What does the gfx-library do to determine if it is a PAL or NTSC system?
It checks, if raster line 100 is followed by a line > 270 (PAL) or a line < 50 (NTSC).

The original Gfx-library 1.x VBeamPos() function:

Code:

VBeamPos
  move.l  $dff004,d0 ;VPOSR
  asr.l   #8,d0
  and.l   #$1ff,d0
  rts

Bug:
Imagine V0-V8 is updated between the two 16-bit accesses to the custom registers during the "move.l $dff004,d0" command:
- V0-V8=255
- Processor gets high bit V8(=0)
- Agnus increases counter to 256
- Processor gets low bits V0-V7 (=0)
- The result is 0 (instead of 256)
As a result, the NTSC/PAL-Function will drop directly into NTSC, because the beam has not reached line 270 after the label "wait" (see below)

The solution to determine NTSC/PAL is the routine "VideoTest"

Code:

;VideoTest with no parameters
;d0 ... Result PAL or NTSC

NTSC EQU 1
PAL  EQU 4

  CNOP 0,4
VideoTest
  move.l  d2,-(a7)
  bsr.s   newVBeamPos
  cmp.l   #270,d0
  ble.s   nextCheck

;Line >270? must be PAL!
is_PAL
  moveq   #PAL,d0
  bra.s   exit

;wait for beam to reach line >= 100 ...
  CNOP 0,4
nextCheck
  bsr.s   newVBeamPos
  move.l  d0,d2
  moveq   #100,d0
  cmp.l   d2,d0
  bgt.s   nextCheck       ;<=100? wait ...

;Now wait for beam to reach line > 270 (PAL) or <=50 (NTSC)
wait
  bsr.s   newVBeamPos
  move.l  d0,d1
  cmp.l   #270,d1
  bgt.s   is_pal          ;> 270? PAL.
  moveq   #50,d0
  cmp.l   d1,d0
  blt.s   wait            ;> 50 ? loop ...
  moveq   #NTSC,d0
exit
  move.l  (a7)+,d2
  rts

;a5 ... ExecBase
;a6 ... GfxBase
  CNOP 0,4
newVBeamPos  
  move.l  d2,-(a7)
  exg     a5,a6
  jsr     -120(a5)        ;Disable()
  exg     a5,a6
  jsr     -384(a6)        ;VBeamPos()
  move.l  d0,d2
newVBeamPosLoop
  jsr     -384(a6)        ;VBeamPos()
  exg     d0,d2
  cmp.l   d0,d2
  bne.s   newVBeamPosLoop
  exg     a5,a6
  jsr     -126(a6)        ;Enable()
  exg     a5,a6
  move.l  (a7)+,d2
  rts

My conclusion:
Maybe patching the VBeamPos() function via SetFunction() of the exec-library at an early system state:
1) out of a bootblock program or
2) as a resident program in CHIP memory, executed during every reset could prevent that the gfx-library uses the wrong raster line position values
But I'm not sure, if it is already too late at these time points, because the gfx-library might be initialized or has already determined NTSC/PAL

ross · 12 December 2018, 19:33

Quote:

Originally Posted by dissident

Bug:
Imagine V0-V8 is updated between the two 16-bit accesses to the custom registers during the "move.l $dff004,d0" command:
- V0-V8=255
- Processor gets high bit V8(=0)
- Agnus increases counter to 256
- Processor gets low bits V0-V7 (=0)
- The result is 0 (instead of 256)
As a result, the NTSC/PAL-Function will drop directly into NTSC, because the beam has not reached line 270 after the label "wait" (see below)

Thanks dissident, this is the reason why i'm using a routine like this (a5=$dff000):

Code:

readl:	        move.w	6(a5),d1
		swap	d1
		move.w	4(a5),d1
		rol.l	#8,d1
		and.w	#$1ff,d1
		rts

check:	        bsr.b	readl
		beq.b	check
.lc		move.w	d1,d0
		bsr.b	readl
		bne.b	.lc
		cmp.b	#$38,d0
		beq.b	pal	
		...

Never ever fails

phx · 12 December 2018, 23:51

Indeed, it helps a lot when reading V8 from VPOSR later.

Also thanks to dissident for digging out the old article. I couldn't remember it, although I bought most issues of Amiga Magazin.

So we have a definitive way to determine PAL/NTSC mode now, which also helps to find the real CIA TOD frequency.

ross · 13 December 2018, 10:37

Quote:

Originally Posted by phx

So we have a definitive way to determine PAL/NTSC mode now, which also helps to find the real CIA TOD frequency.

Well, PAL/NTSC mode discovery was not the primary problem here, but TODA source

Even making some TIMER/TOD related counting is not effective because we can have an early forced NTSC/PAL with ECS Amiga.
So what? GfxBase->DisplayFlags(TODA_SAFE)? Yes, affordable but only on KS20+ (on KS1.x probably not supported at all).
Make use of BPLCON0(ERSY) bit like graphics.library does? How invasive is this? A little desync on video or VH syncs are working like usual on contrary to stopped V(H)POS?
As soon as I have some time I will play with ERSY bit on WinUAE, but every alternative idea is absolutely welcome

Thanks for the excellent posts!

Don_Adan · 13 December 2018, 11:50

Quote:

Originally Posted by ross

Well, PAL/NTSC mode discovery was not the primary problem here, but TODA source

Even making some TIMER/TOD related counting is not effective because we can have an early forced NTSC/PAL with ECS Amiga.
So what? GfxBase->DisplayFlags(TODA_SAFE)? Yes, affordable but only on KS20+ (on KS1.x probably not supported at all).
Make use of BPLCON0(ERSY) bit like graphics.library does? How invasive is this? A little desync on video or VH syncs are working like usual on contrary to stopped V(H)POS?
As soon as I have some time I will play with ERSY bit on WinUAE, but every alternative idea is absolutely welcome

Thanks for the excellent posts!

Yes, exist easy (?) method for systems with activated net stack

Use bsdsocket.library connect to atomic timer server, read atomic date value, check/set difference between used date on Amiga, at exit connect second time to atomic server, set final date value.

ross · 13 December 2018, 12:00

Quote:

Originally Posted by Don_Adan

Yes, exist easy (?) method for systems with activated net stack

Use bsdsocket.library connect to atomic timer server, read atomic date value, check/set difference between used date on Amiga, at exit connect second time to atomic server, set final date value.

Hi Don, I think that's a bit overkill

Toni Wilen · 14 December 2018, 15:23

Quote:

Originally Posted by ross

Make use of BPLCON0(ERSY) bit like graphics.library does? How invasive is this? A little desync on video or VH syncs are working like usual on contrary to stopped V(H)POS?
As soon as I have some time I will play with ERSY bit on WinUAE, but every alternative idea is absolutely welcome

It probably causes (some) displays to lose sync temporarily (picture rolls if CRT or may blank if LCD).

WinUAE does not do anything interesting, it only stops hpos/vpos counters, because display behavior when syncs are invalid is undefined.

ross · 14 December 2018, 15:37

Quote:

Originally Posted by Toni Wilen

It probably causes (some) displays to lose sync temporarily (picture rolls if CRT or may blank if LCD).

WinUAE does not do anything interesting, it only stops hpos/vpos counters, because display behavior when syncs are invalid is undefined.

Thanks Toni, I suspected it.
This 'picture rolling' can be a little annoying..
Are there any alternatives to discover TODA source?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
startup/system takeover	sidewinder	Coders. General	15	28 February 2016 16:33
time clock prob a2000	source	Hardware mods	11	07 August 2011 13:16
A1200 Real Time Clock	Eclipse	support.Hardware	4	22 March 2011 02:18
App to update Amiga System time from web time??	DDNI	request.Apps	2	31 December 2007 07:21
Reading the Real Time Clock	girv	Coders. General	5	04 September 2007 18:30

12 December 2018, 23:51	#85
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,496	Indeed, it helps a lot when reading V8 from VPOSR later. Also thanks to dissident for digging out the old article. I couldn't remember it, although I bought most issues of Amiga Magazin. So we have a definitive way to determine PAL/NTSC mode now, which also helps to find the real CIA TOD frequency.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)