| C64 TOD AM/PM switching [message #225311] |
Wed, 15 January 2014 15:05  |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi,
does a real C64 switch the AM/PM flag of the TODs (bit 7 of dc0b &
dd0b) at 01:00:00.0 and 13:00:00.0? Vice, at least the Mac port, does!
I would expect the switches to take place at 12:00:00.0 twice a day,
i.e. noon and midnight. Is Vice broken or does a real C64 exhibit the
same strange behavior? If so, why at 1 o'clock? Historical reasons? The
net has nothing about switching at 1 o'clock. Whereever I look, I
always find information about switching at 12 o'clock. Looked at
Wikipedia (Article "12 hour clock"), etc., which is very interesting by
the way.
Can anybody confirm this strange behavior of the CIA clocks on the real thing?
Thanks in advance.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #226242 is a reply to message #225311] |
Thu, 16 January 2014 08:23  |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, January 15, 2014 1:05:48 PM UTC-7, Paul Förster wrote:
> Hi,
>
> does a real C64 switch the AM/PM flag of the TODs (bit 7 of dc0b & dd0b) at 01:00:00.0 and 13:00:00.0? Vice, at least the Mac port, does! I would expect the switches to take place at 12:00:00.0 twice a day, i.e. noon and midnight. Is Vice broken or does a real C64 exhibit the same strange behavior? If so, why at 1 o'clock? Historical reasons? The net has nothing about switching at 1 o'clock. Whereever I look, I always find information about switching at 12 o'clock. Looked at Wikipedia (Article "12 hour clock"), etc., which is very interesting by
> the way.
>
> Can anybody confirm this strange behavior of the CIA clocks on the real thing?
>
> Thanks in advance.
> --
> cul8er
>
> Paul
> paul.foerster@gmx.net
When the CIA TOD clocks are initiated to the
range of 01:00:00:0 to 12:59:59:0, the clocks
remain in the proper range. The AM or PM
settings are denoted by whether the high
order hour bit is set or clear. When the
hour is set to $12, the C128D system sets
the hour high order bit. When the hour
is set to $92, the high order bit is
cleared. The following program runs on my
C128D. The first two instructions should
be discarded on a C64 and the C128
routine at B8c2 prints the hexidecimal
character equivalents of the accumulator
contents. The clock rolls over from
11:59:59;9 to 92:00:00:0 and from
91:59:59:9 to 12:00:00:0. It is highly
likely that the program will function
much the same way on a "real" C64.
1300 A2 00 LDX #$00
1302 8E 00 FF STX $FF00
1305 A0 11 LDY #$11
1307 8C 0B DC STY $DC0B
130A A0 59 LDY #$59
130C 8C 0A DC STY $DC0A
130F A0 53 LDY #$53
1311 8C 09 DC STY $DC09
1314 A0 00 LDY #$00
1316 8C 08 DC STY $DC08
1319 A9 0D LDA #$0D
131B A0 03 LDY #$03
131D 20 D2 FF JSR $FFD2
1320 B9 08 DC LDA $DC08,Y
1323 20 C2 B8 JSR $B8C2
1326 A9 3A LDA #$3A
1328 88 DEY
1329 10 F2 BPL $131D
132B A5 91 LDA $91
132D 30 EA BMI $1319
132F 60 RTS
|
|
|
|
| Re: C64 TOD AM/PM switching [message #226645 is a reply to message #226242] |
Thu, 16 January 2014 15:00 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, January 16, 2014 6:23:28 AM UTC-7, rusure wrote:
> On Wednesday, January 15, 2014 1:05:48 PM UTC-7, Paul Förster wrote:
>
>> Hi,
>> does a real C64 switch the AM/PM flag of the TODs (bit 7 of dc0b & dd0b) at 01:00:00.0 and 13:00:00.0? Vice, at least the Mac port, does! I would expect the switches to take place at 12:00:00.0 twice a day, i.e. noon and midnight. Is Vice broken or does a real C64 exhibit the same strange behavior? If so, why at 1 o'clock? Historical reasons? The net has nothing about switching at 1 o'clock. Whereever I look, I always find information about switching at 12 o'clock. Looked at Wikipedia (Article "12 hour clock"), etc., which is very interesting by the way
>> Can anybody confirm this strange behavior of the CIA clocks on the real thing?
>>
>> Thanks in advance.
>> --
>> cul8er
>>
>> Paul
>> handle paul.foerster ISP gmx.net
>
>
> When the CIA TOD clocks are initiated to the
> range of 01:00:00:0 to 12:59:59:0, the clocks
> remain in the proper range. The AM or PM
> settings are denoted by whether the high
> order hour bit is set or clear. When the
> hour is set to $12, the C128D system sets
> the hour high order bit. When the hour
> is set to $92, the high order bit is
> cleared. The following program runs on my
> C128D. The first two instructions should
> be discarded on a C64 and the C128
> routine at B8c2 prints the hexidecimal
> character equivalents of the accumulator
> contents. The clock rolls over from
> 11:59:59;9 to 92:00:00:0 and from
> 91:59:59:9 to 12:00:00:0. It is highly
> likely that the program will function
> much the same way on a "real" C64.
> 1300 A2 00 LDX #$00
> 1302 8E 00 FF STX $FF00
> 1305 A0 11 LDY #$11
> 1307 8C 0B DC STY $DC0B
> 130A A0 59 LDY #$59
> 130C 8C 0A DC STY $DC0A
> 130F A0 53 LDY #$53
> 1311 8C 09 DC STY $DC09
> 1314 A0 00 LDY #$00
> 1316 8C 08 DC STY $DC08
> 1319 A9 0D LDA #$0D
> 131B A0 03 LDY #$03
> 131D 20 D2 FF JSR $FFD2
> 1320 B9 08 DC LDA $DC08,Y
> 1323 20 C2 B8 JSR $B8C2
> 1326 A9 3A LDA #$3A
> 1328 88 DEY
> 1329 10 F2 BPL $131D
> 132B A5 91 LDA $91
> 132D 30 EA BMI $1319
> 132F 60 RTS
I have uploaded to the URL listed below a movie of the TOD clock running from 11:59::50:0 to 92:00:??:? and from 91:59:50:0 to 12:59:??:? The movie shows the TOD running on my C128D in C64 mode. I have replaced the jsr to the C128 hex routine with something that prints a BCD byte in the accumulator. I have skipped the storage of #0 in $ff00 at the beginning of the program.
https://drive.google.com/file/d/0B80L9cEZ8YnvZVI0ZHFuU3pOTHc /edit?usp=sharing
|
|
|
|
| Re: C64 TOD AM/PM switching [message #226774 is a reply to message #226242] |
Thu, 16 January 2014 16:01 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi rusure,
On 2014-01-16 13:23:28 +0000, rusure said:
> The clock rolls over from
> 11:59:59;9 to 92:00:00:0 and from
> 91:59:59:9 to 12:00:00:0.
so you confirm this to run on a *real* 128(D)?
> It is highly
> likely that the program will function
> much the same way on a "real" C64.
leaving aside the hexout routine at B8C2, yes, I feel it *should* work
the same. But I asked for physical proof, as Vice (Mac) flips the AM/PM
bit at 01:00:00 and 13:00:00 instead of 00:00:00 and 12:00:00 (all 24
hour notation), which is sort of strange.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #226775 is a reply to message #226645] |
Thu, 16 January 2014 16:07 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi rusure,
On 2014-01-16 20:00:45 +0000, rusure said:
> I have uploaded to the URL listed below a movie of the TOD clock
> running from 11:59::50:0 to 92:00:??:? and from 91:59:50:0 to
> 12:59:??:? The movie shows the TOD running on my C128D in C64 mode. I
> have replaced the jsr to the C128 hex routine with something that
> prints a BCD byte in the accumulator. I have skipped the storage of #0
> in $ff00 at the beginning of the program.
>
> https://drive.google.com/file/d/0B80L9cEZ8YnvZVI0ZHFuU3pOTHc /edit?usp=sharing
very interesting. So the bit gets flipped at 00:00:00 and 12:00:00 and
not 01:00:00 and 13:00:00. So I take it that Vice (Mac) has a bug here.
It flips the bit at the latter two points of time. :-(
Thanks very much.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #226902 is a reply to message #226775] |
Thu, 16 January 2014 18:24 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, January 16, 2014 2:07:46 PM UTC-7, Paul Förster wrote:
> Hi rusure,
>
>
>
> On 2014-01-16 20:00:45 +0000, rusure said:
>
>> I have uploaded to the URL listed below
>> a movie of the TOD clock running from 11:59::50:0 to 92:00:??:? and from 91:59:50:0
>> to 12:59:??:? The movie shows the TOD
>> running on my C128D in C64 mode. I have
>> replaced the jsr to the C128 hex routine
>> with something that prints a BCD byte in
>> the accumulator. I have skipped the
>> storage of #0 in $ff00 at the beginning
>> of the program.
>>
>> https://drive.google.com/file/d/0B80L9cEZ8YnvZVI0ZHFuU3pOTHc /edit?usp=sharing
>
> very interesting. So the bit gets flipped at
> 00:00:00 and 12:00:00 and not 01:00:00 and
> 13:00:00. So I take it that Vice (Mac) has
> a bug here.
The high order hour bit can be clear. or set.
The Commodore TOD hour byte can only "properly" (i'm making up this jargon as I write this)
assume values of $01 to $12 when the high order
bit is clear and $81 to $92 when the high order
bit is set. The hour byte "flips" (your
jargon) to $92 when the hour byte is set to
$12 and to $12 when the hour byte is set to
$92. From $11:$59:$59:$09 the TOD rolls over
to $92:$00:$00:$00 and from $91:$59:$59:$09 to $12:$00:$00:$00. You may be able to set the
TOD to improper values but I can't predict
the TOD's behavior when you do something
wrong. It may be useful to download the video
and view it in slow motion at the times when
the hour high order bit flips. The Mac TOD
behavior may be the result of a different
TOD philosophy rather than a bug.
> It flips the bit at the latter two points of time. :-(
>
> Thanks very much.
> --
> cul8er
>
> Paul
> paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #226903 is a reply to message #226775] |
Thu, 16 January 2014 19:50 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, January 16, 2014 2:07:46 PM UTC-7, Paul Förster wrote:
> very interesting. So the bit gets flipped at 00:00:00 and 12:00:00 and
> not 01:00:00 and 13:00:00. So I take it that Vice (Mac) has a bug here.
> It flips the bit at the latter two points of time. :-(
> Thanks very much.
> --
> cul8er
>
> Paul
> handle paul.foerster ISPgmx.net
Below is a URL for an image containg captured frames from
the TOD movie I made earlier today. The frames contain
the instant when the AM/PM hour high irder bit flips.
https://drive.google.com/file/d/0B80L9cEZ8Ynvb0xsbGRiblUwc0U /edit?usp=sharing
|
|
|
|
| Re: C64 TOD AM/PM switching [message #227678 is a reply to message #225311] |
Fri, 17 January 2014 11:03 |
|
|
Originally posted by: Frank Buss
Paul Förster wrote:
> Hi,
>
> does a real C64 switch the AM/PM flag of the TODs (bit 7 of dc0b & dd0b)
> at 01:00:00.0 and 13:00:00.0? Vice, at least the Mac port, does!
I wrote a test program, see below, binary here:
http://www.frank-buss.de/c64/tod.prg
Output on Vice 2.4 on Windows:
WRITE/READ/ROLLOVER: 11 / 11 / 12
WRITE/READ/ROLLOVER: 12 / 92 / 01
WRITE/READ/ROLLOVER: 91 / 91 / 92
WRITE/READ/ROLLOVER: 92 / 12 / 81
And on a real C64:
WRITE/READ/ROLLOVER: 11 / 11 / 92
WRITE/READ/ROLLOVER: 12 / 92 / 81
WRITE/READ/ROLLOVER: 91 / 91 / 12
WRITE/READ/ROLLOVER: 92 / 12 / 01
It is a bug in Vice, someone should file a bug report for the
Sourceforge project.
But another interesting effect: why does it invert the AM/PM flag, when
I write 12/92?
The program:
10 deffnb(x)=int(x/10)*16+x-int(x/10)*10
20 h=11:gosub1000
30 h=12:gosub1000
40 h=91:gosub1000
50 h=92:gosub1000
60 end
1000 print"write/read/rollover:";h;"/ ";
1010 poke56331,fnb(h)
1020 poke56330,fnb(59)
1030 poke56329,fnb(58)
1040 poke56328,fnb(00)
1060 x=peek(56328)
1070 x=peek(56331):gosub2000:print" / ";
1080 y=peek(56328)
1090 if x=peek(56331) then goto1080
1100 x=peek(56331):gosub2000
1110 print
1120 return
2000 y=int(x/16):gosub3000
2010 y=x-y*16
3000 print chr$(y+48);
3010 return
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
|
|
|
|
| Re: C64 TOD AM/PM switching [message #227809 is a reply to message #227678] |
Fri, 17 January 2014 14:27 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi Frank,
On 2014-01-17 16:03:34 +0000, Frank Buss said:
> Paul Förster wrote:
>> Hi,
>>
>> does a real C64 switch the AM/PM flag of the TODs (bit 7 of dc0b & dd0b)
>> at 01:00:00.0 and 13:00:00.0? Vice, at least the Mac port, does!
>
> I wrote a test program, see below, binary here:
>
> http://www.frank-buss.de/c64/tod.prg
>
> Output on Vice 2.4 on Windows:
>
> WRITE/READ/ROLLOVER: 11 / 11 / 12
> WRITE/READ/ROLLOVER: 12 / 92 / 01
> WRITE/READ/ROLLOVER: 91 / 91 / 92
> WRITE/READ/ROLLOVER: 92 / 12 / 81
>
> And on a real C64:
>
> WRITE/READ/ROLLOVER: 11 / 11 / 92
> WRITE/READ/ROLLOVER: 12 / 92 / 81
> WRITE/READ/ROLLOVER: 91 / 91 / 12
> WRITE/READ/ROLLOVER: 92 / 12 / 01
>
> It is a bug in Vice, someone should file a bug report for the
> Sourceforge project.
>
> But another interesting effect: why does it invert the AM/PM flag, when
> I write 12/92?
>
> The program:
>
> 10 deffnb(x)=int(x/10)*16+x-int(x/10)*10
> 20 h=11:gosub1000
> 30 h=12:gosub1000
> 40 h=91:gosub1000
> 50 h=92:gosub1000
> 60 end
> 1000 print"write/read/rollover:";h;"/ ";
> 1010 poke56331,fnb(h)
> 1020 poke56330,fnb(59)
> 1030 poke56329,fnb(58)
> 1040 poke56328,fnb(00)
> 1060 x=peek(56328)
> 1070 x=peek(56331):gosub2000:print" / ";
> 1080 y=peek(56328)
> 1090 if x=peek(56331) then goto1080
> 1100 x=peek(56331):gosub2000
> 1110 print
> 1120 return
> 2000 y=int(x/16):gosub3000
> 2010 y=x-y*16
> 3000 print chr$(y+48);
> 3010 return
now that is an interesting read! Thanks. :) Here's what I got on Vice
2.4 on the Mac which corresponds to what you found on Vice 2.4 on
Windows:
write/read/rollover: 11 / 11 / 12
write/read/rollover: 12 / 92 / 01
write/read/rollover: 91 / 91 / 92
write/read/rollover: 92 / 12 / 81
So, I conclude: Flipping the AM/PM bit back and fourth *should* happen
when going from 11:59:59.0 to 12:00:00.0 twice a day and not on 1
o'clock.
The only reason I see for inverting the AM/PM bit when writing 12 & 92
is that maybe they thought that most people think of 12 o'clock as noon
and not midnight. The computer loses its time anyway when switched off
so most people will set the clock to 12 PM rather than to 12 AM, still
entering 12 and not setting the AM/PM flag properly. Far fewer people
are awake during night than during day after all. Just a wild guess.
There's no other technical or logical reason.
Thanks for this short, but very insightful program. Actually, I was
about to write something similar this weekend but you did it before I
could. So, thanks very much. :-)
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #227924 is a reply to message #226242] |
Fri, 17 January 2014 15:25 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi rusure,
> When the CIA TOD clocks are initiated to the
> range of 01:00:00:0 to 12:59:59:0, the clocks
> remain in the proper range. The AM or PM
> settings are denoted by whether the high
> order hour bit is set or clear. When the
> hour is set to $12, the C128D system sets
> the hour high order bit. When the hour
> is set to $92, the high order bit is
> cleared.
hmmm, sorry, maybe I'm dumb or something but I still don't get the idea
behind this special handling of clearing or setting the bit IF the hour
is set to $12 or $92. As your demos and Frank Busse's program
demonstrates, the clock ranges from between $12:$00 and $11:$59 for AM
and between $92:$00 and $91:$59 for PM and rolls over accordingly. So
far so good.
But then, what's the point in inverting the AM/PM bit if the hour is
set to $12 (effectively making it $92) or $92 (effectively making it
$12). If I set it to $12, then I mean 12 AM. And if I set it to $92,
then I explicitly mean 12 PM. So manipulating the bit in any way does
not make sense at all. So what's the idea behind that scheme?
Sorry, I don't live in 12-hour-clock country, so I have a hard time
understanding that specific oddity. I live in 24-hour-clock country
(Switzerland) and for me, the 12-hour-clock day ranges from 12 AM
(midnight!) to 11:59 AM (1 min. before noon!) and 12 PM (noon!) to
11:59 PM (1 min. before midnight!). If this is really the case (as I
learned during childhood), then flipping the bit explicitly (sic!) if I
set the TOD to one of the two 12 hours doesn't make sense at all as it
would teleport me to the other side of the world immediately. Not that
I would have any objection had Commodore indeed invented teleportation.
But it's definitely not working by setting a TOD to the wrong 12 hour
cycle.
So, I get the "how" but not the "why". :-( Why is that? It requires
unnecessary special treatment when setting the clock to one of the two
"twelves"...
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #227925 is a reply to message #227678] |
Fri, 17 January 2014 16:16 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi Frank,
On 2014-01-17 16:03:34 +0000, Frank Buss said:
> But another interesting effect: why does it invert the AM/PM flag, when
> I write 12/92?
I think I have the solution to that oddity. As far as I know, you're
German, as I was (I'm Swiss now). So we, originating from 24-hour-land,
cannot understand that strange behavior per se. For us, it's illogical.
However, I talked to my wife about that. She is born Swiss but spent
her first 8 years of life in London because her dad was the Swiss
ambassador in London at that time.
So I asked her to not think about it long but intuitively tell me what
she would set the clock to if she was to set it to 12 (noon!). Her
answer was kind of surprising as she immediately said she'd set the
clock to 12 AM. She knows that this is logically not correct but still
would do it. Hence the English people seem to refer to 12 AM for noon
and hence 12 PM for midnight. I don't know how Americans handle it but
the British seem to handle it that way. As a consequence, I see the
automatic bit flipping as an automatic corrective action that Commodore
did to account for this everyday language oddity. It would also explain
why I have such difficulty to understand that effect that rusure
appears to see as the most natural thing in the world.
Frank, does that help you?
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
|
|
| Re: C64 TOD AM/PM switching [message #228045 is a reply to message #227926] |
Fri, 17 January 2014 18:49 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi Frank,
On 2014-01-17 21:33:57 +0000, Frank Buss said:
> Not really, because in my test program I set the time to 12:59:58, not
> 12:00:00. Maybe ask your wife how she would set a digital clock to 12:30
> PM :-)
that's the point. We cannot nail it by mathematical logic and
correctness, but rather by how rusure and my wife see the world, i.e.
everyday language use in English speaking territories. rusure said,
setting the hour to between 01 and 12 sets the PM flag only if 12 is
used, which also equals your output from the real machine, otherwise it
leaves the flag untouched. Then, if you set the hour to between 01 and
12 (meaning 13 to 00), you'd have to set the flag explicitly, also
clearing the flag internally as a result if set to 12, thus making it
AM again at midnight. This also matches your output.
This is kind of intuitive if you look at the world the way described by
rusure and my wife, i.e. people having grown up with this view of the
world.
So I wrote this small routine just a few minutes ago to be fed with
hours 00..23 (BCD) to spit out the hour for the TOD to be set with:
d2000 2014
..> 2000 a9 00 lda #$00
..> 2002 d0 04 bne $2008
..> 2004 a9 92 lda #$92
..> 2006 d0 0a bne $2012
..> 2008 f8 sed
..> 2009 c9 13 cmp #$13
..> 200b 90 05 bcc $2012
..> 200d 38 sec
..> 200e e9 12 sbc #$12
..> 2010 09 80 ora #$80
..> 2012 d8 cld
..> 2013 60 rts
load A (in $2001) with anything between 00 and 23 and let it run. After
completion, A should be:
01..11 => 01..11
12 => 12, which then internally should flip to 92
13..23 => 81..91
00 => 92, which then internally should flip to 12
Feed the result to the TOD's hour register and *theoretically*, the
AM/PM flag should be correct at all times. You could combine this with
your BASIC program to check for all 24 hours of the day. Just poke the
hour in BCD to 8193 and then sys 8192. Then read the result, which is
BCD again of course.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #228467 is a reply to message #227924] |
Sat, 18 January 2014 03:23 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Friday, January 17, 2014 1:25:34 PM UTC-7, Paul Förster wrote:
> Hi rusure,
> I still don't get the idea behind this special
> handling of clearing or setting the bit IF the
> hour is set to $12 or $92. As your demos and
> Frank Busse's program demonstrates, the clock
> ranges from between $12:$00 and $11:$59 for AM
> and between $92:$00 and $91:$59 for PM and
> rolls over accordingly. So far so good.
I think this behavor is a result of some sloppy TOD coding. The TOD program most likely flips the high order bit, the first instant after
the hour byte contents is changed to either $12 or $92. Whether the clock rolled over while changing the hour byte to $12/$92 or if hour was set to $12/$92 is probably not a concern of the TOD programming.
I have discovered another TOD oddity. The program was modified to load the hour, minute, and second TOD registers every half minute. The 10ths register was loaded every minute. The TOD clock advances once a minute every minute after the 10ths register is read. The TOD clock does not advance on the half minute when the 10ths isn't loaded, Somewhere in the TOD Bermuda triangle, the clock continues ticking even if the ticking for the registers is suspended.
Let's postpone a discussion of the advisability of toggling between standard and saving time in the autumn and fall. In addition I'll postpone why for some Christmas falls on January 7th rather than on December 25th.
|
|
|
|
| Re: C64 TOD AM/PM switching [message #228571 is a reply to message #228467] |
Sat, 18 January 2014 05:26 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi rusure,
On 2014-01-18 08:23:03 +0000, rusure said:
> I think this behavor is a result of some sloppy TOD coding. The TOD
> program most likely flips the high order bit, the first instant
> afterthe hour byte contents is changed to either $12 or $92. Whether
> the clock rolled over while changing the hour byte to $12/$92 or if
> hour was set to $12/$92 is probably not a concern of the TOD
> programming.
it doesn't appear to me as an oddity anymore if I look at it through
your eyes. This also explains what you said initially about the bit
flipping behavior which I didn't understand at first. 1-12 is AM and
the other 1-12 is PM. It's just that simple. You set the clock
accordingly and it does an internal correction on both twelves to make
it "mathematically" correct where the last hour of the 1-12 cycle
belongs to the next cycle already as far as the flag is concerned.
> I have discovered another TOD oddity. The program was modified to load
> the hour, minute, and second TOD registers every half minute. The
> 10ths register was loaded every minute. The TOD clock advances once a
> minute every minute after the 10ths register is read. The TOD clock
> does not advance on the half minute when the 10ths isn't loaded,
> Somewhere in the TOD Bermuda triangle, the clock continues ticking even
> if the ticking for the registers is suspended.
this is documented behavior. IIRC, I found that in "Mapping the
Commodore 64". Bottom line it says there, once you access the hour
register, the min, sec and 10th registers are not updated from the
internal (still ticking!) CIA registers anymore until you access the
10th register. So, reading the hour should make it stop updating min,
sec and 10th but the internal CIA clock should continue to tick away.
Reading the 10th then at an arbitrary time later should make the
registers being updated with the new time from the internal registers
again. That's also why you always have to read or write the 10th
register if you touch the hour register.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #228789 is a reply to message #227924] |
Sat, 18 January 2014 08:50 |
dott.Piergiorgio
Messages: 166
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Il 17/01/2014 21:25, Paul Förster ha scritto:
> Sorry, I don't live in 12-hour-clock country, so I have a hard time
> understanding that specific oddity. I live in 24-hour-clock country
> (Switzerland) and for me, the 12-hour-clock day ranges from 12 AM
> (midnight!) to 11:59 AM (1 min. before noon!) and 12 PM (noon!) to 11:59
> PM (1 min. before midnight!).
perhaps there's another oddity. a Swiss coder, perhaps ? :D
Anyway, because the TOD clock in PAL 64s wasn't correctly timed for
50hz, was imprecise even by _Italian_ standards ;)
Best regards from Italy,
dott. Piergiorgio.
|
|
|
|
| Re: C64 TOD AM/PM switching [message #228791 is a reply to message #228789] |
Sat, 18 January 2014 10:28 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi dott. Piergiogio,
On 2014-01-18 13:50:06 +0000, dott.Piergiorgio said:
> Anyway, because the TOD clock in PAL 64s wasn't correctly timed for
> 50hz, was imprecise even by _Italian_ standards ;)
no prob here. Just set bit 7 in $dc0e/$dd0e to get PAL frequency. To
keep things simple, determine from $02a6 whether you're on a PAL (=1)
or NTSC (=0) machine. Then it should run pretty accurate.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #228792 is a reply to message #225311] |
Sat, 18 January 2014 10:45 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi Frank, hi rusure,
I finally set up my real C64 again so I could do some testing myself. I
heavily modified your program for testing with Vice initially, then the
real machine and a Turbo Chameleon 64. Yet, thanks very much for your
initial version. The program outputs a table with four columns:
1. column ("24hr"): hour to be tested (decimal)
2. column ("Wr"): hour written to TOD register (BCD)
3. column ("Rd"): hour read from TOD register (BCD) immediately after
writing the value in column 2 to see the conversion between AM/PM, if
any.
4. column ("Nx"): next hour (BCD) after the hour switch
Note: You may select the CIA (1 or 2) to be checked in line 10. You may
also play with the hour range (0..23) to be printed in line 140 or "rem
out" or delete the line completely to see the full 24 hour range.
Values in the table having bit 7 set (i.e. starting with digits 8 or 9)
have the PM bit set, all other values are AM!
Output on a real C64:
CIA# 1
24hr: Wr => Rd => Nx
--------------------
0 : 92 => 12 => 01 <= Switch from 00 to 01 (24-hour notation)
1 : 01 => 01 => 02
2 : 02 => 02 => 03
11 : 11 => 11 => 92
12 : 12 => 92 => 81 <= Switch from 12 to 13 (24-hour notation)
13 : 81 => 81 => 82
14 : 82 => 82 => 83
23 : 91 => 91 => 12
ready.
I added a small routine which calculates the correct 12 hour BCD number
including AM/PM flag from a 00-23 hour BCD number:
2000 a9 00 lda #$00 ; input hour (range 00..23)
2002 d0 04 bne $2008
2004 a9 92 lda #$92
2006 d0 0a bne $2012
2008 f8 sed
2009 c9 13 cmp #$13
200b 90 05 bcc $2012
200d 38 sec
200e e9 12 sbc #$12
2010 09 80 ora #$80
2012 d8 cld ; A=hour (range 01..12 with AM/PM bit)
Here's an example of the BASIC program run in Vice 2.4 on a Mac running
Mavericks:
CIA# 1
24hr: Wr => Rd => Nx
--------------------
0 : 92 => 12 => 81 <= wrong next hour
1 : 01 => 01 => 02
2 : 02 => 02 => 03
11 : 11 => 11 => 12
12 : 12 => 92 => 01 <= wrong next hour
13 : 81 => 81 => 82
14 : 82 => 82 => 83
23 : 91 => 91 => 92
ready.
Ok, now for the Chameleon part:
The program won't run there at all! Why? It gets stuck in line 350.
Since the hour does not advance at all in the current core (8i),
peeking the new hour reveals the same value as the previous hour which
is already stored in variable x. So, no chance to advance. The
consequence is that the program will show the title, and the values for
the first three columns but never make it to the last column. So you
may either press R/S here or delete line 350 completely to see the
table (without values column 4!) on a Chameleon.
That should conclude my initial testing. Integration into my RTC
read/write code can now begin. :-)
Thanks very much to you guys. :-)
--
cul8er
Paul
paul.foerster@gmx.net
Source of the TOD test program:
10 cs=1
20 c(1)=56320
30 c(2)=56576
40 for i=0 to 21
50 read p
60 poke 8192+i,p
70 next
80 def fn b(x)=int(x/10)*16+x-int(x/10)*10
90 print chr$(14);
100 print "CIA#";cs
110 print "24hr: Wr => Rd => Nx"
120 print "--------------------"
130 for i=0 to 23
140 if i>2 and i<11 or i>14 and i<23 then next
150 poke 8193,fn b(i)
160 sys 8192
170 h=peek(2)
180 gosub 210
190 next
200 end
210 if i<10 then print " ";
220 print i;": ";
230 x=h
240 gosub 400
250 print " => ";
260 poke c(cs)+11,h
270 poke c(cs)+10,fn b(59)
280 poke c(cs)+9,fn b(59)
290 poke c(cs)+8,fn b(08)
300 x=peek(c(cs)+8)
310 x=peek(c(cs)+11)
320 gosub 400
330 print " => ";
340 y=peek(c(cs)+8)
350 if x=peek(c(cs)+11) then 340
360 x=peek(c(cs)+11)
370 gosub 400
380 print
390 return
400 y=int(x/16)
410 gosub 430
420 y=x-y*16
430 print chr$(y+48);
440 return
450 data 169, 35, 208, 4, 169, 146
460 data 208, 10, 248, 201, 19, 144
470 data 5, 56, 233, 18, 9, 128, 216
480 data 133, 2, 96
|
|
|
|
| Re: C64 TOD AM/PM switching [message #229014 is a reply to message #228791] |
Sat, 18 January 2014 13:14 |
dott.Piergiorgio
Messages: 166
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Il 18/01/2014 16:28, Paul Förster ha scritto:
> Hi dott. Piergiogio,
>
> On 2014-01-18 13:50:06 +0000, dott.Piergiorgio said:
>> Anyway, because the TOD clock in PAL 64s wasn't correctly timed for
>> 50hz, was imprecise even by _Italian_ standards ;)
>
> no prob here. Just set bit 7 in $dc0e/$dd0e to get PAL frequency. To
> keep things simple, determine from $02a6 whether you're on a PAL (=1) or
> NTSC (=0) machine. Then it should run pretty accurate.
well, if a Swiss says is a pretty accurate timing.... :D ;)
(for non-european ppl: the standard stereotypical joke on swiss ppl is
that they're fixated on precise timing, timetables &c.)
Best regards from Italy,
dott. Piergiorgio.
|
|
|
|
| Re: C64 TOD AM/PM switching [message #229015 is a reply to message #229014] |
Sat, 18 January 2014 13:43 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
On 2014-01-18 18:14:18 +0000, dott.Piergiorgio said:
> well, if a Swiss says is a pretty accurate timing.... :D ;)
but I'm not born that way. I have Swiss citizenship for about 14
months. I was born German and have been for about 45 years. So there's
no obsession by heritage in my blood line. :-P
So, just do it and grab your favorite stop-watch. :-P
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #229121 is a reply to message #229015] |
Sat, 18 January 2014 16:26 |
dott.Piergiorgio
Messages: 166
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Il 18/01/2014 19:43, Paul Förster ha scritto:
> On 2014-01-18 18:14:18 +0000, dott.Piergiorgio said:
>> well, if a Swiss says is a pretty accurate timing.... :D ;)
>
> but I'm not born that way. I have Swiss citizenship for about 14 months.
> I was born German and have been for about 45 years. So there's no
> obsession by heritage in my blood line. :-P
>
> So, just do it and grab your favorite stop-watch. :-P
naahh.. I grab my favorite mandolino :P :D
Best regards from Italy,
dott. Piergiorgio.
|
|
|
|
| Re: C64 TOD AM/PM switching [message #229428 is a reply to message #228792] |
Sat, 18 January 2014 22:08 |
|
|
Originally posted by: Greg King
On Saturday, January 18, 2014 10:45:30 AM UTC-5, Paul Förster wrote:
>
> Source of the TOD test program:
>
> 10 cs=1
> 20 c(1)=56320
> 30 c(2)=56576
> 40 for i=0 to 21
> 50 read p
> 60 poke 8192+i,p
> 70 next
> 80 def fn b(x)=int(x/10)*16+x-int(x/10)*10
Here are two efficient BASIC functions that convert between binary and BCD:
10 rem binary to binary-coded decimal
20 def fnd(b)=int(b/10)*6+b
30 rem decimal to binary
40 def fnb(d)=d-int(d/16)*6
|
|
|
|
|
|
| Re: C64 TOD AM/PM switching [message #229858 is a reply to message #229428] |
Sun, 19 January 2014 07:42 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi Greg,
On 2014-01-19 03:08:57 +0000, Greg King said:
> Here are two efficient BASIC functions that convert between binary and BCD:
> 10 rem binary to binary-coded decimal
> 20 def fnd(b)=int(b/10)*6+b
> 30 rem decimal to binary
> 40 def fnb(d)=d-int(d/16)*6
cool! Thanks. :)
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #233163 is a reply to message #225311] |
Tue, 21 January 2014 23:10 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
|
Just for the record, I have never allowed a TOD to run for more than 10 minutes. I only use TODs to delay program progress. This typically needs a clock to run for minutes at the most. Most frequently, all I need for a clock to run is for periods of seconds or less. TOD hour bytes and AM/PM flags just are not considered by my programs. The JIFFY clock ticks off time in JIFFIES. I have never had a watch that conforms to JIFFY clock standards. I don't have intuition for time periods measured in JIFFIES, I just don't use the JIFFY clock.
|
|
|
|
| Re: C64 TOD AM/PM switching [message #233951 is a reply to message #233163] |
Wed, 22 January 2014 13:52 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi rusure,
On 2014-01-22 04:10:15 +0000, rusure said:
> Just for the record, I have never allowed a TOD to run for more than 10
> minutes. I only use TODs to delay program progress. This typically
> needs a clock to run for minutes at the most. Most frequently, all I
> need for a clock to run is for periods of seconds or less. TOD hour
> bytes and AM/PM flags just are not considered by my programs. The
> JIFFY clock ticks off time in JIFFIES. I have never had a watch that
> conforms to JIFFY clock standards. I don't have intuition for time
> periods measured in JIFFIES, I just don't use the JIFFY clock.
the TOD is both, a 12 AM/PM clock *and* a timer and has alarm. So the
TOD can run normal day time while one can still use the timer and/or
alarm. You can control which one you use by setting or clearing bit 7
in the TOD control register. So there's no reason to not use the TOD
clock as a normal clock which is way more accurate than TI$, or TI
respectively, the latter being the Jiffy junk. :-)
And yes, just like you, I don't know of any clock in the world that
ticks in Jiffies. I wonder why Commodore ever did that.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #239364 is a reply to message #233951] |
Sun, 26 January 2014 14:50 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, January 22, 2014 11:52:40 AM UTC-7, Paul Förster wrote:
yes, just like you, I don't know of any clock in the world that ticks in Jiffies. I wonder why Commodore ever did that.
> --
> cul8er
> Paul
>
As you discovered in another thread, converting between hours, minutes, seconds, & JIFFYs and a 3 byte JIFFY clock is nontrivial in machine language. I may have a TRANSACTOR article, at the bottom of my Commodore Bermuda triangle, for the multiplication and division in ML needed for the chores. It's the kind of thing that could be in C(OMMODORE?)= HACKING on the FRIDGE.. I don't recall seeing a resolution of your attempts to locate the routines used by BASIC for the conversions.
For the TOD, you need to deal with a flaky AM/PM flag and converting between digital and BCD. All in all, the TOD is far easier to deal with than the JIFFY clock. I think its kind of strange that the TOD minute and second bytes range from $00 to $59, & the tenths byte ranges from $00 to $09, while, aside the AM/PM flag, the TOD hour byte doesn't range from $00 to $11 but rather from $01 to $12.
|
|
|
|
| Re: C64 TOD AM/PM switching [message #240480 is a reply to message #239364] |
Mon, 27 January 2014 13:31 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi rusure,
On 2014-01-26 19:50:42 +0000, rusure said:
> aside the AM/PM flag, the TOD hour byte doesn't range from $00 to $11
> but rather from $01 to $12.
no, that's understandable aner perfectly logical. It reflects the use
of time in everyday language of English speaking countries. Have a look
at Wikipedia and search for 12-hour-clock.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241729 is a reply to message #228791] |
Sat, 01 February 2014 04:00 |
<address_is
Messages: 19
Registered: January 2013
Karma: 0
|
Junior Member |
|
|
Paul Förster <paul.foerster@gmx.net> wrote:
> Hi dott. Piergiogio,
>
> On 2014-01-18 13:50:06 +0000, dott.Piergiorgio said:
>> Anyway, because the TOD clock in PAL 64s wasn't correctly timed for >
>> 50hz, was imprecise even by _Italian_ standards ;)
>
> no prob here. Just set bit 7 in $dc0e/$dd0e to get PAL frequency. To keep
> things simple, determine from $02a6 whether you're on a PAL (=1) or NTSC
> (=0) machine. Then it should run pretty accurate.
Unless it is a PAL SX-64 for example. Or a PAL 64 run in the US, or
something used $2A6 for its own purpose, etc. Unfortunately many programs
do just what you wrote and then fail badly under some less common
conditions. This buggy thinking is even present in VICE (sic!) No, TOD
frequency is *NOT* one-to-one bound to PAL/NTSC variants of the system.
Reliable determining the right setup for the TODs is much more complex than
checking $02a6 flag! I had to deal with it some time ago, fixing badly
written soft piece (by myself ;-)
--
SD!
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241779 is a reply to message #241729] |
Sat, 01 February 2014 13:09 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi SD!,
btw., what does SD stand for?
On 2014-02-01 09:00:01 +0000, <address_is@invalid.invalid> said:
> Reliable determining the right setup for the TODs is much more complex than
> checking $02a6 flag! I had to deal with it some time ago, fixing badly
> written soft piece (by myself ;-)
some anonymous guy provided me with this code. It runs fine on a Turbo
Chameleon 64 in turbo and normal mode:
tv_system := $02a6
sei
turbo_reliable_norm_detection:
: lda $d011
bmi :- ;wait for a line number <256 (RST8 = 0)
: lda $d011
bpl :- ;wait for line 256 (RST8 = 1)
lda #8
: cmp $d012 ;wait for either line 264 or line 8
bne :-
lda $d011 ;and check RST8 to find out which one it was.
bpl ntsc_detected
pal_detected:
lda #1
bne no_ntsc_patch
ntsc_detected:
lda #0
no_ntsc_patch:
sta tv_system
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241800 is a reply to message #241779] |
Sat, 01 February 2014 20:23 |
|
|
Originally posted by: SD!
Paul Förster <paul.foerster@gmx.net> wrote:
> Hi SD!,
>
> btw., what does SD stand for?
Shortest variant of my old handle.
> On 2014-02-01 09:00:01 +0000, <address_is@invalid.invalid> said:
>> Reliable determining the right setup for the TODs is much more complex than
>> checking $02a6 flag! I had to deal with it some time ago, fixing badly
>> written soft piece (by myself ;-)
>
> some anonymous guy provided me with this code. It runs fine on a Turbo
> Chameleon 64 in turbo and normal mode:
>
> tv_system := $02a6
> sei
> turbo_reliable_norm_detection:
Good, but as I tried to express - determining video system (even in a more
reliable manner than checking $02a6) doesn't help initialising TODs
properly and we talk about those here. I once wrote a piece that does when
I had to fix my own TOD depending program to work reliably on every (real)
64 compatible machine.
--
SD!
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241801 is a reply to message #241800] |
Sun, 02 February 2014 03:16 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi SD,
On 2014-02-02 01:23:51 +0000, SD! said:
> Good, but as I tried to express - determining video system (even in a more
> reliable manner than checking $02a6) doesn't help initialising TODs
> properly and we talk about those here. I once wrote a piece that does when
> I had to fix my own TOD depending program to work reliably on every (real)
> 64 compatible machine.
would you publish or send me that code? I'd be too curious to see how
it works. If you prefer to keep it secret, then you can still send it
to me and I promise to not give it away.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241802 is a reply to message #241800] |
Sun, 02 February 2014 05:08 |
|
|
Originally posted by: Frank Buss
SD! wrote:
> Paul Förster <paul.foerster@gmx.net> wrote:
>> Hi SD!,
>>
>> btw., what does SD stand for?
>
> Shortest variant of my old handle.
>
>> On 2014-02-01 09:00:01 +0000, <address_is@invalid.invalid> said:
>>> Reliable determining the right setup for the TODs is much more complex than
>>> checking $02a6 flag! I had to deal with it some time ago, fixing badly
>>> written soft piece (by myself ;-)
>>
>> some anonymous guy provided me with this code. It runs fine on a Turbo
>> Chameleon 64 in turbo and normal mode:
>>
>> tv_system := $02a6
>> sei
>> turbo_reliable_norm_detection:
>
> Good, but as I tried to express - determining video system (even in a more
> reliable manner than checking $02a6) doesn't help initialising TODs
> properly and we talk about those here. I once wrote a piece that does when
> I had to fix my own TOD depending program to work reliably on every (real)
> 64 compatible machine.
But shouldn't be too difficult. First measure the number of phi2 cycles
for one tenth TOD second. As Paul wrote, it is easy to check if it is a
PAL or NTSC machine, so you know the phi2 clock frequency. With this you
can calculate the real time for one tenth TOD second and then check if
the 50 Hz or 60 Hz setting is right (you have to do this, because it is
possible that a NTSC machine is used with a a 50 Hz power supply and
vice versa).
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241803 is a reply to message #241801] |
Sun, 02 February 2014 04:56 |
|
|
Originally posted by: SD!
Paul Förster <paul.foerster@gmx.net> wrote:
> Hi SD,
>
> On 2014-02-02 01:23:51 +0000, SD! said:
>> Good, but as I tried to express - determining video system (even in a more
>> reliable manner than checking $02a6) doesn't help initialising TODs
>> properly and we talk about those here. I once wrote a piece that does when
>> I had to fix my own TOD depending program to work reliably on every (real)
>> 64 compatible machine.
>
> would you publish or send me that code? I'd be too curious to see how it
> works. If you prefer to keep it secret, then you can still send it to me
> and I promise to not give it away.
There isn't much secret stuff about the eight bit machines these days ;-) I
shall find the code once back at the repo enabled place (I come back
tomorrow evening) but the idea is quite simple once you understand that PAL
vs NTSC is *NOT* bound to TOD clock frequency[*]. Then you only need to
determine somehow what it actually is. How? I went the route of setting the
frequency flag to either of the two values and comparing the resulting TOD
accuracy against another timing resource over a predefined period of time.
If it runs accurately the flag is set correctly. If it runs faster (or
slower - depending on the initial flag setting), you missed the ball and
have to toggle the flag. The drawback is that because the TOD's granularity
is relatively low at only tenths of a second and the difference between
possible frequencies isn't huge in this context either, it means that you
have to "waste" sizeable amount of time upon initialisation. AFAIR I got
reliable results at about one second. The good news is that you have to do
it only once ;-)
--
SD!
[*] - as I wrote earlier, this is such a widely spread misconception that
the majority of TOD using programs has been written with this in mind.
Splinters of this bug is even present in VICE! The truth is that in a plain
C-64 TOD clock is derived from mains frequency, which happens to be 50Hz
when the machine is run in a "PAL country" and 60Hz when the machine is run
in an "NTSC country". Now, /usually/ a machine run in a "PAL country" will
be of PAL video norm (VIC, clocks, etc.). Vice-versa: /usually/ a machine
run in an "NTSC country" will be of NTSC video norm. Usually... But nothing
prevents running PAL machine in the US (60Hz on a PAL computer) or NTSC
machine in the EU (50Hz on an NTSC computer), does anything? Also nothing
should prevent your program from running correctly on an SX-64, should
anything? But the funny part is that the SX does NOT derive TOD clock from
the power lines... uh-oh... and if we depend on the PAL/NTSC buggy approach
then we are fried because no matter what the country you run the machine in
and no matter what its video norm is - TOD frequency is /always/ the same
(60Hz) there.
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241804 is a reply to message #241802] |
Sun, 02 February 2014 10:48 |
Aaron Daughtry
Messages: 227
Registered: July 2013
Karma: 0
|
Senior Member |
|
|
On 2014-02-02 10:08:06 +0000, Frank Buss said:
>>> some anonymous guy provided me with this code. It runs fine on a Turbo
>>> Chameleon 64 in turbo and normal mode:
>>>
>>> tv_system := $02a6
>>> sei
>>> turbo_reliable_norm_detection:
>>
>> Good, but as I tried to express - determining video system (even in a more
>> reliable manner than checking $02a6) doesn't help initialising TODs
>> properly and we talk about those here. I once wrote a piece that does when
>> I had to fix my own TOD depending program to work reliably on every (real)
>> 64 compatible machine.
>
> But shouldn't be too difficult.
Sure it isn't ;-)
> First measure the number of phi2 cycles
> for one tenth TOD second. As Paul wrote, it is easy to check if it is a
> PAL or NTSC machine, so you know the phi2 clock frequency.
Why phi2? Unless you meant the TIMA/TIMB timers, that is..
> With this you can calculate the real time for one tenth TOD second
> and then check if the 50 Hz or 60 Hz setting is right
If you want to do this with CPU cycle counting you have to take into
account that those are not fully reliable with VIC stealing them under
some circumstances. Meaning you still have to account for VIC's RASTER
stuff or you have to disable the VIC's output. The first seemed too
much of a burden to me (given all possible situations) the second is
not what I ever wanted as I wanted the checking routine to be part of a
library and be as little "invasive" as possible. Flicking the screen
didn't fit into my set of objectives. You may also try counting cycles
with TIMA/TIMB timers of the CIA but you'd probably have to chain them
and possibly try to save their setup if you want to be "non-invasive".
All that adds on bytes in the routine. Hence I went the route of
counting full rasters and it works well but uses IMHO too much time
(about a second) to get reliable result. Then there is the idea of
doing it the other way around, which I was too lazy to implement and
test yet ;-) I mean instead of counting full rasters and checking how
long it takes to complete a predefined set of them - count TODTENs and
see how many rasterlines you use for one. This should be much faster as
I imagine being able to get reliable output in up to two TODTENs, which
would be one fifth of the time needed now - quite acceptable.
> (you have to do this, because it is
> possible that a NTSC machine is used with a a 50 Hz power supply and
> vice versa).
Actually it is about the mains frequency rather than PSU ;-) but I am
sure you know it.
Also - as I wrote in the previous post - because you want the program
to run correctly on every SX too, don't you? ;-)
--
SD!
|
|
|
|
| Re: C64 TOD AM/PM switching [message #241805 is a reply to message #241801] |
Sun, 02 February 2014 10:52 |
Aaron Daughtry
Messages: 227
Registered: July 2013
Karma: 0
|
Senior Member |
|
|
On 2014-02-02 08:16:30 +0000, Paul Förster said:
> Hi SD,
>
> On 2014-02-02 01:23:51 +0000, SD! said:
>> Good, but as I tried to express - determining video system (even in a more
>> reliable manner than checking $02a6) doesn't help initialising TODs
>> properly and we talk about those here. I once wrote a piece that does when
>> I had to fix my own TOD depending program to work reliably on every (real)
>> 64 compatible machine.
>
> would you publish or send me that code? I'd be too curious to see how
> it works. If you prefer to keep it secret, then you can still send it
> to me and I promise to not give it away.
Actually I found an older version checked out on my laptop... it is the
one that counts full rasters. I still haven't implemented the "other
way around" variant.
;******************************************************
..export tod_init
..import pal_ntsc_check
..include "c64.i"
; Reliable initialisation of TOD clock by Silver Dream ! / W.F.M.H.
; takes account of possible differences in TOD ticks frequencies
; supplied to the CIA chips
; INPUTS: none
; RETURNS: detected frequency in A
; REGISTERS AFFECTED: A, X, Y
;//
tod_init:
php ; store the status register so that we don't change too many things
sei ; it may be better to take care of NMIs too (we don't do it for now)
jsr pal_ntsc_check
cmp #$01
beq pal_wait_50_rasters
ntsc_wait_60_rasters:
ldx #60
bne reset_tod
pal_wait_50_rasters:
ldx #50
reset_tod:
; set TOD tick frequency to 50Hz
lda CIACRA
ora #$80
sta CIACRA
; we want to set the clock rather than alarm time
lda CIACRB
and #$7f ; we clear bit 7 of CIACRB
sta CIACRB ; so that writing to TOD sets clock rather than alarm time
; reset all registers to zero
lda #$00
sta TODHRS ; here it latches to stop counting
sta TODMIN
sta TODSEC
sta TODTEN ; latch released here
count_rasters:
bit SCROLY
bpl count_rasters
: bit SCROLY
bmi :-
dex
bne count_rasters
lda TODTEN
bne ticks_60hz
ticks_50hz:
lda CI2CRA
ora #$80
sta CI2CRA
lda #50
bne finish
ticks_60hz:
lda CIACRA
and #$7f
sta CIACRA
lda CI2CRA
and #$7f
sta CI2CRA
lda #60
finish:
plp
rts
;/
;*******************************************************
--
SD!
|
|
|
|
| Re: C64 TOD AM/PM switching [message #242081 is a reply to message #241805] |
Mon, 03 February 2014 16:16 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi SD!,
On 2014-02-02 15:52:34 +0000, SD! said:
> Actually I found an older version checked out on my laptop... it is the
> one that counts full rasters. I still haven't implemented the "other
> way around" variant.
what do you mean by "older" version? Is there a "new" version? ;-)
> sei ; it may be better to take care of NMIs too (we don't do it for now)
[..]
thanks very much for the code. Wow! It took me 2 minutes to understand,
what your code does (at least I hope so), but it took me a whole day to
understand the concept, thanks also to your explanation in your other
post. I'm getting old. :(
Well, at least I *think* I understood it. Let me summarize to see if I
really understood it correctly:
- determine the model type NTSC/PAL by checking raster lines
- set CIA1 to the thus determined frequency and reset it to 00:00:00.0
- count raster lines
- check if 1/10 of a second has passed after counting a fixed cycle number
- if yes, the TOD has been initialized to the wrong value,
if no, the TOD has been set correctly
What I don't understand is that this still sets the CIA frequency in
relation to the number of raster lines counted, which is an absolute
value inside the computer but bears no relation to the mains frequency.
So, why doesn't (or shouldn't) it set the CIA frequency to always 50 Hz
on a PAL machine and 60 Hz on an NTSC machine. I just don't get it... :(
Also, shouldn't I set the NMI vector to a dummy "rti" during the
checks? Ok, admittedly, it's hard to hit the RESTORE key in exactly
those few microseconds. :)
Did I really get it? I'm not so sure after all...
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #242097 is a reply to message #242081] |
Mon, 03 February 2014 17:54 |
Aaron Daughtry
Messages: 227
Registered: July 2013
Karma: 0
|
Senior Member |
|
|
On 2014-02-03 21:16:30 +0000, Paul Förster said:
>> Actually I found an older version checked out on my laptop... it is the
>> one that counts full rasters. I still haven't implemented the "other
>> way around" variant.
>
> what do you mean by "older" version? Is there a "new" version? ;-)
Yes, even two ;-)
>> sei ; it may be better to take care of NMIs too (we don't do it for now)
> [..]
>
> thanks very much for the code. Wow! It took me 2 minutes to understand,
> what your code does (at least I hope so), but it took me a whole day to
> understand the concept, thanks also to your explanation in your other
> post. I'm getting old. :(
Or my explanations were not up to snuff...
> Well, at least I *think* I understood it. Let me summarize to see if I
> really understood it correctly:
>
> - determine the model type NTSC/PAL by checking raster lines
Right - this becomes our independent timing resource but we have to
know what is its period, meaning whether we are run on a PAL or NTSC
machine.
> - set CIA1 to the thus determined frequency and reset it to 00:00:00.0
Actually I set it always to 50Hz. Just to save on bytes - I have always
the same setting, no matter what the video norm is and don't have to
account for it later on.
> - count raster lines
Yes, actually count full rasters to be precise.
> - check if 1/10 of a second has passed after counting a fixed cycle number
Not really. We expect that 50 full rasters (on PAL) or 60 full rasters
(on NTSC) take (with adequate accuracy) exactly one second. This means
that during that time TODTEN should wrap to 00 and this is the value
that we should get IF the 50Hz value set previously was actually
correct. So - in other words - what we check is whether TOD shows the
correct value of one second after one "wall clock" second. The "wall
clock" second we time with either 50 or 60 full rasters, depending on
the video norm.
> - if yes, the TOD has been initialized to the wrong value,
If we got one second (+/- 0.05s) from TOD (TODTEN at $00) then we were
initially right and the tick frequency is indeed 50Hz.
> if no, the TOD has been set correctly
IF we got something else than one second (TODTEN != $00) after one
second (and some nanoseconds) "wall clock" - it means that TOD is not
accurate, which has to be caused by the fact that the supplied
frequency is NOT 50Hz as we initially assumed. If it is not 50, then it
has to be 60Hz then.
> What I don't understand is that this still sets the CIA frequency in
> relation to the number of raster lines counted,
No, it doesn't. Initially it sets it to 50Hz, regardless of the video
norm. Later on it doesn't relate the set frequency to the video norm
either.
> which is an absolute value inside the computer but bears no relation
> to the mains frequency.
As I tried to explain before - to verify the accuracy of the TOD we
need another, trusted timing resource. One we know the accuracy and can
trust it. There aren't many of them available in the 64. We can count
CPU cycles, either with code or with TIMA/TIMB timers or (what I did
here) we can time one second with full rasters. We know that 50 full
rasters on PAL will take one second and the same second will pass
during 60 full rasters on an NTSC system. The PAL vs. NTSC is checked
/only/ to give us proper number of full rasters to count in order to
time one second.
> So, why doesn't (or shouldn't) it set the CIA frequency to always 50 Hz
> on a PAL machine and 60 Hz on an NTSC machine. I just don't get it... :(
Because PAL C-64/128 machine can be run in the US and while still being
PAL, will have 60Hz TOD ticks frequency supplied. If you set your TOD
to 50Hz - you are out of luck.
Because every SX-64, even PAL one will always have 60Hz supplied to the
TOD. No matter where you run it.
That's what I wrote before. Combine it with the fact that the given
routine does *NOT* set the frequency in relation to the video norm and
you should be on the right page.
> Also, shouldn't I set the NMI vector to a dummy "rti" during the
> checks? Ok, admittedly, it's hard to hit the RESTORE key in exactly
> those few microseconds. :)
RESTORE is not the only source of NMIs. Yes, you should. To be on the
safe side. Especially that the number of microseconds you have a chance
to get NMI is slightly above 1000 ;-) But in any case you don't want to
enter /any/ race condition. AFAIR that's one of the enhancements I did
in the "newer" version.
> Did I really get it? I'm not so sure after all...
You did well :-) Hope I cleared the remaining parts. Did I? Please let me know.
P. S. Maybe this thread will eventually motivate me to finish the other
version of the routine... ;-)
--
SD!
|
|
|
|
| Re: C64 TOD AM/PM switching [message #242330 is a reply to message #241802] |
Wed, 05 February 2014 15:07 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi Frank,
On 2014-02-02 10:08:06 +0000, Frank Buss said:
> But shouldn't be too difficult. First measure the number of phi2 cycles
> for one tenth TOD second. As Paul wrote, it is easy to check if it is a
> PAL or NTSC machine, so you know the phi2 clock frequency. With this you
> can calculate the real time for one tenth TOD second and then check if
> the 50 Hz or 60 Hz setting is right (you have to do this, because it is
> possible that a NTSC machine is used with a a 50 Hz power supply and
> vice versa).
finally a concept, my old brain can immediately grasp. :)
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
| Re: C64 TOD AM/PM switching [message #245226 is a reply to message #242097] |
Sun, 23 February 2014 16:00 |
Paul Förster
Messages: 415
Registered: April 2012
Karma: 0
|
Senior Member |
|
|
Hi SD!,
ok, some delay in the thread on my part. :(
On 2014-02-03 22:54:43 +0000, SD! said:
>> what do you mean by "older" version? Is there a "new" version? ;-)
> Yes, even two ;-)
is there a way to make you post an update here? ;-)
> Or my explanations were not up to snuff...
no, your explanations are pretty good. I'm just getting old -- definitly. :(
> Actually I set it always to 50Hz. Just to save on bytes - I have always
> the same setting, no matter what the video norm is and don't have to
> account for it later on.
ok, I see. You only correct it later in the routine if needed. After
all, it need some initial setting, even if it was the wrong one.
> Yes, actually count full rasters to be precise.
what do you mean by full rasters? Is there a way to see if a raster
line is drawn only to a specific position so I could, in theory,
manipulate one single arbitrary position on screen in a different
graphics mode for example even if the graphics mode before and after
that position is different? Just curious...
>> - check if 1/10 of a second has passed after counting a fixed cycle number
> Not really. We expect that 50 full rasters (on PAL) or 60 full rasters
> (on NTSC) take (with adequate accuracy) exactly one second. This means
> that during that time TODTEN should wrap to 00 and this is the value
> that we should get IF the 50Hz value set previously was actually
> correct. So - in other words - what we check is whether TOD shows the
> correct value of one second after one "wall clock" second. The "wall
> clock" second we time with either 50 or 60 full rasters, depending on
> the video norm.
ah, so you actually check the complete opposite of what I said. You
don't check whether a defined number of rasters have passed in a
certain time frame, but rather whether a defined time frame has passed
has passed after a certain number of rasters.
>> What I don't understand is that this still sets the CIA frequency in
>> relation to the number of raster lines counted,
> No, it doesn't. Initially it sets it to 50Hz, regardless of the video
> norm. Later on it doesn't relate the set frequency to the video norm
> either.
this is the point I just don't get. You count rasters which are video
norm dependent but yet you don't relate to the video norm.
> As I tried to explain before - to verify the accuracy of the TOD we
> need another, trusted timing resource. One we know the accuracy and can
> trust it. There aren't many of them available in the 64. We can count
> CPU cycles, either with code or with TIMA/TIMB timers or (what I did
> here) we can time one second with full rasters. We know that 50 full
> rasters on PAL will take one second and the same second will pass
> during 60 full rasters on an NTSC system. The PAL vs. NTSC is checked
> /only/ to give us proper number of full rasters to count in order to
> time one second.
I'd love to see CPU cycle counting code which would take the VIC
stealing cycles into account without disabling the screen. :)
> Because PAL C-64/128 machine can be run in the US and while still being
> PAL, will have 60Hz TOD ticks frequency supplied. If you set your TOD
> to 50Hz - you are out of luck.
ok, got that bit. :)
> Because every SX-64, even PAL one will always have 60Hz supplied to the
> TOD. No matter where you run it.
and how did Commodore make sure that the TOD did not run too fast in
PAL country on an SX-64 then?
> RESTORE is not the only source of NMIs. Yes, you should. To be on the
> safe side. Especially that the number of microseconds you have a chance
> to get NMI is slightly above 1000 ;-) But in any case you don't want to
> enter /any/ race condition. AFAIR that's one of the enhancements I did
> in the "newer" version.
please post. :) Setting the NMI vector to point to an rti is trivial.
Did you do anything else?
> You did well :-) Hope I cleared the remaining parts. Did I? Please let me know.
I'm not 100% sure yet. At least I hope I finally got the concept that
you measure the time taken to pass a predefined number of rasters
rather than the other way around as I initially thought would be the
case.
> P. S. Maybe this thread will eventually motivate me to finish the other
> version of the routine... ;-)
yes, I hope so too. :) After all, this is quite interesting. You
probably noticed on the TC64 mailing list that I did the RTC read/write
code there. That's also why I asked for a way to set TI/TI$ in another
thread here. The idea and code you provided are included in that code
to also set the TOD properly on any system, not only the TC64, to keep
the code more flexible.
--
cul8er
Paul
paul.foerster@gmx.net
|
|
|
|
Members
Search
Help
Register
Login
Home
