| CIA time of day register not set properly upon boot [message #210062] |
Wed, 10 July 2013 00:47  |
drevin
Messages: 53
Registered: November 2012
Karma: 0
|
Member |
|
|
On a C64 I have, the "hours" value of the CIA time of day register is not always set to 1 (like I believe it should be) upon boot/reset. This happens especially with soft reset. Switching OFF/ON usually brings it back to 1, but not always.
I check the values by typing "print peek(56331)" (CIA1) and "print peek(56587)" (CIA2) after startup. Both are sometimes set to values other than 1. So it's probably not caused by the chips themselves. Especially values 145 and 129 are common.
Testing the same with emulators always returns 1, but I have another working C64 which did produce a few 145s and 129s also. But they were very rare compared to the C64 in question, especially after the system had warmed up.
This hours problem by itself doesn't bother me. It's just an incorrect default value, and changing the hours afterwards seems to work ok. I'm just wondering what the root cause for this problem could be, and if it's possibly causing/going to cause additional problems. The system can run for hours without a hitch, so something pretty subtle has to be causing this "hours" anomaly. Maybe degraded capacitors, or some kind of timing problem? Or maybe this is all normal and I'm worrying for nothing?
|
|
|
|
| Re: CIA time of day register not set properly upon boot [message #210065 is a reply to message #210062] |
Wed, 10 July 2013 08:57  |
|
|
Originally posted by: SD!
On 2013-07-10 06:47:16 +0200, drevin@easy.com said:
> On a C64 I have, the "hours" value of the CIA time of day register is
> not always set to 1 (like I believe it should be) upon boot/reset. This
> happens especially with soft reset. Switching OFF/ON usually brings it
> back to 1, but not always.
>
> I check the values by typing "print peek(56331)" (CIA1) and "print
> peek(56587)" (CIA2) after startup. Both are sometimes set to values
> other than 1. So it's probably not caused by the chips themselves.
> Especially values 145 and 129 are common.
>
> Testing the same with emulators always returns 1, but I have another
> working C64 which did produce a few 145s and 129s also. But they were
> very rare compared to the C64 in question, especially after the system
> had warmed up.
>
> This hours problem by itself doesn't bother me. It's just an incorrect
> default value, and changing the hours afterwards seems to work ok. I'm
> just wondering what the root cause for this problem could be, and if
> it's possibly causing/going to cause additional problems. The system
> can run for hours without a hitch, so something pretty subtle has to be
> causing this "hours" anomaly. Maybe degraded capacitors, or some kind
> of timing problem? Or maybe this is all normal and I'm worrying for
> nothing?
I haven't verified it but I believe that TOD clocks are not initialised
upon reset/power-up (despite what the datasheet say about "all other
registers being reset to zero"). Their values are therefore to be
treated as "undefined" and all registers have to be "user-space"
initialised before use. What actually shows up in those registers upon
power-up, might depend on particular CIA revision idiosyncrasies. As I
wrote - I haven't verified this theory. Maybe someone else can give
more insight. In any case I have always properly initialised TOD clocks
myself before putting them into any use.
--
SD!
|
|
|
|
| Re: CIA time of day register not set properly upon boot [message #210066 is a reply to message #210065] |
Wed, 10 July 2013 13:39 |
Groepaz
Messages: 640
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
SD! wrote:
>> This hours problem by itself doesn't bother me. It's just an incorrect
>> default value, and changing the hours afterwards seems to work ok. I'm
>> just wondering what the root cause for this problem could be, and if
>> it's possibly causing/going to cause additional problems. The system
>> can run for hours without a hitch, so something pretty subtle has to be
>> causing this "hours" anomaly. Maybe degraded capacitors, or some kind
>> of timing problem? Or maybe this is all normal and I'm worrying for
>> nothing?
>
> I haven't verified it but I believe that TOD clocks are not initialised
> upon reset/power-up (despite what the datasheet say about "all other
> registers being reset to zero"). Their values are therefore to be
> treated as "undefined" and all registers have to be "user-space"
> initialised before use. What actually shows up in those registers upon
> power-up, might depend on particular CIA revision idiosyncrasies. As I
> wrote - I haven't verified this theory. Maybe someone else can give
> more insight. In any case I have always properly initialised TOD clocks
> myself before putting them into any use.
yes yes yes. at reset not everything in the CIAs is actually resetted and/or
cleared to 0. also the kernal does not initialize those registers at all. so
you indeed have to treat them as undefined after powerup and/or reset.
--
http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org
Es ist schon alles gesagt worden, nur noch nicht von jedem.
<Karl Valentin>
|
|
|
|
| Re: CIA time of day register not set properly upon boot [message #210069 is a reply to message #210066] |
Wed, 10 July 2013 20:24 |
drevin
Messages: 53
Registered: November 2012
Karma: 0
|
Member |
|
|
On Wednesday, July 10, 2013 8:39:46 PM UTC+3, Groepaz wrote:
> SD! wrote: >> This hours problem by itself doesn't bother me. It's just an incorrect >> default value, and changing the hours afterwards seems to work ok. I'm >> just wondering what the root cause for this problem could be, and if >> it's possibly causing/going to cause additional problems. The system >> can run for hours without a hitch, so something pretty subtle has to be >> causing this "hours" anomaly. Maybe degraded capacitors, or some kind >> of timing problem? Or maybe this is all normal and I'm worrying for >> nothing? > > I haven't verified it but I believe that TOD clocks are not initialised > upon reset/power-up (despite what the datasheet say about "all other > registers being reset to zero"). Their values are therefore to be > treated as "undefined" and all registers have to be "user-space" > initialised before use. What actually shows up in those registers upon > power-up, might depend on particular CIA revision idiosyncrasies. As I > wrote - I haven't verified this theory. Maybe someone else can give > more insight. In any case I have always properly initialised TOD clocks > myself before putting them into any use. yes yes yes. at reset not everything in the CIAs is actually resetted and/or cleared to 0. also the kernal does not initialize those registers at all. so you indeed have to treat them as undefined after powerup and/or reset. -- http://www.hitmen-console.org http://magicdisk..untergrund.net http://www.pokefinder.org http://ftp.pokefinder.org Es ist schon alles gesagt worden, nur noch nicht von jedem. <Karl Valentin>
Okay, this explains what I've been seeing then. Thanks for clearing it up!
|
|
|
|
| Re: CIA time of day register not set properly upon boot [message #210072 is a reply to message #210066] |
Thu, 11 July 2013 10:14 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, July 10, 2013 11:39:46 AM UTC-6, Groepaz wrote:
> SD! wrote:
On Wednesday, July 10, 2013 11:39:46 AM UTC-6, Groepaz wrote:
> SD! wrote:
>
>> I haven't verified it but I believe that TOD clocks are not initialised
>> upon reset/power-up (despite what the datasheet say about "all other
>> registers being reset to zero"). Their values are therefore to be
>> treated as "undefined" and all registers have to be "user-space"
>> initialised before use. What actually shows up in those registers upon
>> power-up, might depend on particular CIA revision idiosyncrasies. As I
>> wrote - I haven't verified this theory. Maybe someone else can give
>> more insight. In any case I have always properly initialised TOD clocks
>> myself before putting them into any use.
>
> yes yes yes. at reset not everything in the CIAs is actually resetted and/or
> cleared to 0. also the kernal does not initialize those registers at all. so
> you indeed have to treat them as undefined after powerup and/or reset.
It's bad programming practice to use values for your variables and memory locations that have been set by the system. I am unhappy that BASIC sets all variables to zero. When I programmed on the Control Data Corporation large mainframe in FORTRAN, there was a system command that preset the variables used by the program to indefinite and unusable in arithmetic. Further more when a symbolic cross reference map was requested, variables being used by the program without first being defined were flagged.
In my very first line printer graphics program, the line variable array was not set to space or anything else. Except for the "x" used to plot, the program had used values left over by a previous computer user. After plotting the line, the "x" was replaced by a " ". A most unexpected, interesting, and useless graph resulted.
|
|
|
|
| Re: CIA time of day register not set properly upon boot [message #210073 is a reply to message #210072] |
Thu, 11 July 2013 10:52 |
Anton Treuenfels
Messages: 105
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
"rusure" <r_u_sure9@yahoo.com> wrote in message
news:dd33d3b0-543b-47dc-9841-755d3aa114dd@googlegroups.com...
> I am unhappy that BASIC sets all variables to zero.
Actually the Commodore BASIC interpreters don't. When a variable name is
encountered that isn't already in the variable name table, what happens
depends on where it appears. If it is on the left side of an equals sign,
the variable is created and assigned the value of the expression on the
right side. If it is anywhere else, the interpreter doesn't create it but
treats it as having a value of zero (if numeric) or null (if string) . Which
works because the variable has clearly never been assigned any other value.
Other approaches are conceivable. An interpreter could be written to throw
an error if a variable name is not in the table. There would have to be
some way to create variables before use then. Actually IIRC DIM is not
limited to arrays but can also be used to create scalars, though it's hardly
ever used that way.
- Anton Treuenfels
|
|
|
|
| Re: CIA time of day register not set properly upon boot [message #210074 is a reply to message #210073] |
Thu, 11 July 2013 13:32 |
rusure
Messages: 1030
Registered: March 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, July 11, 2013 8:52:49 AM UTC-6, Anton Treuenfels wrote:
> "rusure" <r_u_sure9@yahoo.com> wrote in message
>
> news:dd33d3b0-543b-47dc-9841-755d3aa114dd@googlegroups.com...
>
>> I am unhappy that BASIC sets all variables to zero.
>
> Actually the Commodore BASIC interpreters don't. When a variable name is
> encountered that isn't already in the variable name table, what happens
> depends on where it appears. If it is on the left side of an equals sign,
> the variable is created and assigned the value of the expression on the
> right side. If it is anywhere else, the interpreter doesn't create it but
> treats it as having a value of zero (if numeric) or null (if string) . Which
> works because the variable has clearly never been assigned any other value.
>
> Other approaches are conceivable. An interpreter could be written to throw
The CDC computer's FORTRAN processor was a compiler. Maybe, my complaints are with interpreters. Nothing surprising there.
> an error if a variable name is not in the table. There would have to be
> some way to create variables before use then. Actually IIRC DIM is not
> limited to arrays but can also be used to create scalars, though it's hardly
> ever used that way.
>
>
>
> - Anton Treuenfels
|
|
|
|
Members
Search
Help
Register
Login
Home
