non-system startup code time/clock problem

[alpine9000]

Originally Posted by meynaf

If by "serious" you understand "business" then no (hopefully ?).

Else, yes, maybe.
I mean, while demos and some games can be satisfied with os killing stuff, utilities and large projects (like a big game over 100MB in size) need to run under os.
Are there such projects now ? Well, there are a few game projects here and there. My personal current intent is to write a multi-format audio player. If i get some nice incentive i may eventually be porting another Atari ST game as well.

I completely agree

[ross]

Time has passed since the last post about the topic.
I've read everything but I still not convinced on what is the best solution and that works on most hardware and KSs.

Using 'calculates time difference passed through the TOD and update' seems the best but has a problem:
not always the TOD is tied to the same source, can be power supply frequency or video v-frequency, so machine type dependent.
To complicate things it may happen that it's granted to the user to change in real time the vertical screen frequency...

battclock.resource works only on KS2.0+.
HW bang the RTC seems unaffordable.
A full WHDl slave a bit excessive (anyway require 2.0).

What is left? A system call for "setclock load"?
Who has tried something like that, what did you opt for?
(it is absolutely acceptable and understandable to not care about it and not restore the date/time )

[meynaf]

Don't kill the OS and this problem will magically go away

[Don_Adan]

Originally Posted by ross

Time has passed since the last post about the topic.
I've read everything but I still not convinced on what is the best solution and that works on most hardware and KSs.

Using 'calculates time difference passed through the TOD and update' seems the best but has a problem:
not always the TOD is tied to the same source, can be power supply frequency or video v-frequency, so machine type dependent.
To complicate things it may happen that it's granted to the user to change in real time the vertical screen frequency...

battclock.resource works only on KS2.0+.
HW bang the RTC seems unaffordable.
A full WHDl slave a bit excessive (anyway require 2.0).

What is left? A system call for "setclock load"?
Who has tried something like that, what did you opt for?
(it is absolutely acceptable and understandable to not care about it and not restore the date/time )

You want to set correct time, after quiting? I never need this, but the easiest way for me is add counter to VBI interrupt addq.l #1,Counter, and update clock time at exit.

[ross]

Originally Posted by meynaf

Don't kill the OS and this problem will magically go away

If I could do it I would do it but sometimes it's impossible when you have to apply patch to old and badly written stuff ..

Originally Posted by Don_Adan

You want to set correct time, after quiting? I never need this, but the easiest way for me is add counter to VBI interrupt addq.l #1,Counter, and update clock time at exit.

Yes, I had thought about it, but often VBL IRQs are in more (scattered) routines or disabled or unused () or is simply inconvenient to insert a counter in a specific part.
I was looking for a more general solution to be applied quietly at the system reanimation

[meynaf]

Originally Posted by ross

If I could do it I would do it but sometimes it's impossible when you have to apply patch to old and badly written stuff ..

Depends how heavily you accept to patch...
What makes it so difficult in your case ?

[ross]

Originally Posted by meynaf

Depends how heavily you accept to patch...
What makes it so difficult in your case ?

Completely destroyed system areas. Idea is to delocate everything and recover at exit, RTC time included.

Yes I know, WHDl exists for this but I want to experiment

[alpine9000]

I ended up leaving the OS running. I had a pretty decent clock restore routine that worked most of the time, but I could never crack the nut of things like network stacks.

And when the OS is running, surprising as it sounds, it provides all these really useful features

[ross]

Originally Posted by alpine9000

I ended up leaving the OS running.

Well, code is your for your game, so you could do it

I had a pretty decent clock restore routine that worked most of the time

Based on? It's available?

but I could never crack the nut of things like network stacks.

Yes, this can be really a problem.

And when the OS is running, surprising as it sounds, it provides all these really useful features

Yes, I have a pending patch where I managed to leave the system active and everything was much simpler

[alpine9000]

Originally Posted by ross

Based on? It's available?

I am pretty sure someone posted the code on here is a thread very similar to this one, but at least an initial version made it into blocky skies:

https://github.com/alpine9000/blockyskies/blob/master/game/os.i

[ross]

Originally Posted by alpine9000

I am pretty sure someone posted the code on here is a thread very similar to this one, but at least an initial version made it into blocky skies:

https://github.com/alpine9000/blocky...ster/game/os.i

Ah, ok, is TOD based.

Thanks

[meynaf]

Originally Posted by ross

Completely destroyed system areas. Idea is to delocate everything and recover at exit, RTC time included.

The solution might be preventing the destruction of system areas.
Why does it happen ? Code and/or data at absolute addresses maybe ?

[ross]

Originally Posted by meynaf

The solution might be preventing the destruction of system areas.
Why does it happen ? Code and/or data at absolute addresses maybe ?

Yes, both, and is a pretty common situation if you want the original code to work in a low memory condition
(like with only 512kb ram) AND the same code in a 'modern' machine.
But anyway is only a curiosity of mine to find a valid solution for time/clock stuck if you stop system IRQ2 from happening.
And maybe TOD is the best choice available.

I know you are a big sustainer of a proper request of resources before hw banging (and you are right!)
but sometime is too hard or time consuming to avoid a dirty patch, or simply not as fun as get your hands dirty and find new solutions

[dissident]

Originally Posted by ross

Yes, both, and is a pretty common situation if you want the original code to work in a low memory condition
(like with only 512kb ram) AND the same code in a 'modern' machine.
But anyway is only a curiosity of mine to find a valid solution for time/clock stuck if you stop system IRQ2 from happening.
And maybe TOD is the best choice available.

I know you are a big sustainer of a proper request of resources before hw banging (and you are right!)
but sometime is too hard or time consuming to avoid a dirty patch, or simply not as fun as get your hands dirty and find new solutions

Hi ross,

maybe this solution I found out some time ago makes things easier restoring the system time independent from a kickstart version:

  MOVE.L  $4.W,A6        ;Execbase
  LEA     timer_request_struc(PC),A1 ;Timer-request-structure
  MOVEQ   #0,D0            ;Unit 0 (UNIT_MICROHZ) & Null for struc
  MOVE.B  D0,8(A1)        ;LN_Type: Entry type = Null
  MOVE.B  D0,9(A1)        ;LN_Pri: Priority of the struc. = NULL
  MOVEQ   #0,D1            ;No Flags for device
  MOVE.L  D0,$A(A1)        ;LN_Name: No name for the structure
  LEA     timer_device_name(PC),A0 ;Pointer to name of Timer-Device
  MOVE.L  D0,$E(A1)        ;MN_ReplyPort: No Reply-Port
  JSR     -444(A6)        ;OpenDevice()
  TST.L   D0
  BNE.S   open_timer_device_error
  LEA     timer_request_struc(PC),A1
  MOVE.W  #$A,$1C(A1)        ;IO_Command = TR_GETSYSTIME
  JSR     -456(A6)        ;DoIO()
  JSR     -120(A6)        ;Disable()

;Here we take over the machine...

  MOVE.L  #$BFE001,A4        ;CIA-A base address
  MOVEQ   #0,D0
  MOVE.B  $A00(A4),D0        ;TOD-clock bits 23-16
  SWAP    D0            ;Shift bits to the right position
  MOVE.B  $900(A4),D0        ;TOD-clock bits 15-8
  LSL.W   #8,D0            ;Shift bits to the right position
  MOVE.B  $800(A4),D0        ;TOD-clock bits 7-0
  MOVE.L  D0,TOD_time_save    ;Save time before demo/intro starts

  MOVEM.L D0-D7/A0-A6,-(A7)
  BSR     demo            ;start intro/demo
  MOVEM.L (A7)+,D0-D7/A0-A6

  MOVE.L  TOD_time_save(PC),D0    ;Time before starting demo/intro
  MOVEQ   #0,D1
  MOVE.B  $A00(A4),D1        ;TOD-clock Bits 23-16
  SWAP    D1
  MOVE.B  $900(A4),D1        ;TOD-clock Bits 15-8
  LSL.W   #8,D1
  MOVE.B  $800(A4),D1        ;TOD-clock Bits 7-0
  CMP.L   D0,D1            ;TOD overflow?
  BEQ.S   no_TOD_overflow    ;No -> skip
  MOVE.L  #$FFFFFF,D2        ;Max TOD value
  SUB.L   D0,D2            ;Difference until overflow
  ADD.L   D2,D1            ;+ value after overflow
  BRA.S   TOD_okay
  CNOP 0,4            ;Longword alignment for 68020+
no_TOD_overflow
  SUB.L   D0,D1            ;Get normal difference without overflow
TOD_okay
  MOVE.L  D1,TOD_time_save    ;Save period of demo/intro

;Restoring system...

  MOVE.L  $4.W,A6        ;Execbase
  JSR     -126(A6)        ;Enable()
  MOVE.L  TOD_time_save(PC),D0    ;Period of demo/intro
  MOVEQ   #0,D1
  MOVE.B  212(A6),D1        ;Get VBlankFrequency
  LEA     timer_request_struc(PC),A1
  DIVU.W  D1,D0            ;Calculate seconds
  MOVE.W  #$B,$1C(A1)        ;IO_command = TR_SETSYSTIME
  MOVE.L  D0,D1            ;Save seconds in d1
  EXT.L   D0            ;Word to longword
  ADD.L   D0,$20(A1)        ;TV_SECS: Set Unix-Time seconds
  SWAP    D1            ;Remainder of division
  MULU.W  #10000,D1        ;*10000 = µs
  ADD.L   D1,$24(A1)        ;TV_MICRO: Set Unix-Time microseconds
  JMP     -456(A6)        ;DoIO()
  CNOP 0,4
open_timer_device_error
  RTS

  CNOP 0,4
TOD_time_save        DC.L 0
timer_request_struc DS.B 40
timer_device_name   DC.B "timer.device",0
  EVEN

[ross]

Originally Posted by dissident

Hi ross,

maybe this solution I found out some time ago makes things easier restoring the system time independent from a kickstart version:

Thanks dissident, this is the same routine as pointed out by alpine9000 (in blockyskies source).
I've only a remarks about it: since the TOD tick source can vary, how obtain it (with system destroyed*)?
Maybe the easiest thing to do is count how many video lines there are in one tick and select a time count for 50 or 60Hz.
I already do it to know if I'm in PAL or NTSC, but TOD source can be also power line frequency, so I need to expand my existing routine.
Or is there an even simpler way?

EDIT:* well, you can get it before, but sometime KS1.x system is wrong about PAL/NTSC check

[phx]

Originally Posted by ross

Maybe the easiest thing to do is count how many video lines there are in one tick and select a time count for 50 or 60Hz.

To find out whether the video is PAL or NTSC you only have to look for the maximum raster line in VPOSR. But...

I already do it to know if I'm in PAL or NTSC, but TOD source can be also power line frequency

Yes. That complicates things. So you first have to determine PAL/NTSC video mode and then you have to compare the VERTBs with the TOD clock to see if they differ, right?

I should also improve my code in this aspect. Currently I'm only reading ExecBase.PowerSupplyFrequency and assume this is the CIA clock tick.

[dissident]

Originally Posted by alpine9000

I am pretty sure someone posted the code on here is a thread very similar to this one, but at least an initial version made it into blocky skies:

https://github.com/alpine9000/blocky...ster/game/os.i

Hi alpine9000, the system clock stuff is exactly my code I posted in this thread on 4 October 2015, 21:10 Funny, how things become independent.

[dissident]

Originally Posted by ross

Thanks dissident, this is the same routine as pointed out by alpine9000 (in blockyskies source).
I've only a remarks about it: since the TOD tick source can vary, how obtain it (with system destroyed*)?
Maybe the easiest thing to do is count how many video lines there are in one tick and select a time count for 50 or 60Hz.
I already do it to know if I'm in PAL or NTSC, but TOD source can be also power line frequency, so I need to expand my existing routine.
Or is there an even simpler way?

EDIT:* well, you can get it before, but sometime KS1.x system is wrong about PAL/NTSC check

Originally Posted by phx

Currently I'm only reading ExecBase.PowerSupplyFrequency and assume this is the CIA clock tick.

Hi ross & phx, on OCS/KS1.x machines this is the way I would detect it, too. And if you didn't destroy the execbase structure in memory you can read the ExecBase entries even if the system is turned off.

[phx]

Is ExecBase.PowerSupplyFrequency always correct?

Ross mentioned that Kick 1.x sometimes reports a wrong frequency, and I remember that too. But I do not remember if it was wrong video or power supply frequency, or both, and which ExecBase(?) entries were wrong.

[ross]

Originally Posted by dissident

Hi alpine9000, the system clock stuff is exactly my code I posted in this thread on 4 October 2015, 21:10 Funny, how things become independent.

You are right! So thanks to you

Originally Posted by phx

Is ExecBase.PowerSupplyFrequency always correct?

Ross mentioned that Kick 1.x sometimes reports a wrong frequency, and I remember that too. But I do not remember if it was wrong video or power supply frequency, or both, and which ExecBase(?) entries were wrong.

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).