I have just been playing around with PrizmSDK and made a test add-in for the Prizm. I noticed there's a function to get the RTC ticks and wrote code to output it to the calculator's screen when the add-in is run.

This allowed me to test a few things I was curious about: if the RTC resets every time you turn off the calculator, or if resets every time you take out the batteries.

From my brief tests, the RTC ticks value "walks" faster than a computer RTC, because what I call a "calculator second", measured by looking to the 3rd digit from the right on the ticks number, is way faster than a real second (IMO it lasts one third or one quarter of a real second).

Plus, and while I didn't do extensive or exact tests on this either, the clock seems to keep counting at the same speed, while the calculator is turned off (by pressing Shift+On).
It also didn't reset to zeros when I removed one of the batteries, but that might have been because I didn't allow enough time for the blue capacitors to empty.

Anyways, I think we should explore the RTC a bit more, and if those who already have information about it are kind enough to post it, it would be great.

All this, because I wonder if it is possible to make the calculator show us the current time and date - from what I know, it shouldn't be a problem, assuming:
- The RTC always goes at the same speed, not affected by processor usage or clock (I highly doubt about the latter)
- The RTC isn't stopped, reset or slowed down when the calculator is powered off
- We can convert between the calculator's "milliseconds" and real milliseconds.

Does anyone have more information about the RTC, which can help this noob answer his questions? Thanks

This is an excellent thing to ponder. I know that the first point (The RTC always goes at the same speed, not affected by processor usage) is something I plan to exploit to solve some speed problems in my Tetrizm game, but I didn't consider what I could use the RTC for in terms of it continuing counting when the calculator is off (or reset). As far as I can tell, there's no way to modify the value for the RTC, which makes me think we would need to write a program that lets you enter a base value for the current time/date, record the corresponding current RTC value, and then do an offset calculation to figure out the current time/date.

The one thing I have heard about the RTC is that it apparently ticks at around 15 times per second, I'm not quite sure if it's true.

Yeah, my idea to display human-readable time was to have some file saying "tick 3456789 corresponds to 12:56 12th October 2011", then (assuming the RTC is accurate/stable in terms of speed, and all the RTCs in all the Prizms work at the same speed) we could calculate, given how many RTC ticks are advanced per second, what the current time is (by comparison with the saved time&date=ticks).

This way, an user would only need to adjust the time every time the RTC resets, which, judging from my fast experiments, only happens when the calculator is left much time without batteries.

Of course, the RTC is useful for much more things than telling you the time

(offtopic: I own an old Casio digital diary. For PC comm, it uses a serial cable with one 3-pin end, that is the same as the recent Casio graphic calcs use. Turns out that not only the cable fits in the female connector the Casio calcs have, but it also works with the Prizm, and I'm able to use a VT100 terminal emulator I found on the internet ).

Out of curiosity, what are the settings? As far as I can figure out, it's 9600 baud, 2/3 stop bits, no parity bits, but that's a very odd setting, so I think I must be wrong.

I used 9000 8N1 without hardware or software flow control.

I got it working with minicom and screen (what I wrote on the calc displayed on the PC, what I wrote on the PC displayed on the calc), on Linux (of course, you'll find me using Windows only to develop add-ins ).

Now I'm working on making Linux open a terminal on the serial line so I can control my PC using the Prizm (you may kid, but you never know when a VT100 terminal in your backpack might come handy...).

Oh, and I found the terminal here: http://ourl.ca/117495
Too bad, I can't find its source code and I fear the original author has given up on the project...

I wanted to make a clock utility like Menno did for the fx-9860G/GII:
http://www.casiocalc.org/to/fsdisplay.php?cat2disp=FS.FX.9860G.casm#casio-digital-w

But have stopped all development.
So, if you are interested:

Code:

RTC_GetTicks return the time from midnight at 1/128 seconds.

Oh, so if you turn on your calculator at the same time two days in a row, it will have the same value for RTC_GetTicks, and you can't check the passing of days?

If it returns the time from midnight...
then it is aware of when the midnight is!
How?

Other thing. If it returns the time from midnight (by magically knowing when is midnight), then some simple code will say what time is it (but not date).

OK, assuming that by "midnight" you mean some random time in the day. This means the RTC resets every 24 hours. Still, saving a file saying "tick 5622 is 11:32AM" will get the time right every day (assuming the RTC advance is constant over time etc.).

EDIT: After some simple math, according to what PierrotLL said, my Prizm's midnight was about 12:37 hours ago (12,58 hours ago), while it's already 21:47 here

A pre-registered date is certainly defined zero, or maybe when the rtc-battery (if it exsists) were inserted.

Anyway this RTC is very useful into timing. I use it for example in my Epic Coaster Remake for the sky switching on FXes.

We have already functions on fx, right, so why don't use them with some modifications?

An excellent question. Is the RTC on the Prizm as described identical to its functionality on the FXes? Also, you should totally port over your Epic Coaster to the Prizm with some nifty color! Did you Introduce Yourself yet?

Had not found this topic, sorry! :p

I did a test myself and I can confirm the RTC resets (I just don't know if it is every 24 hours or what). At 8:59 the ticks value on my Prizm was 10978866, at 9:07 they were 11034018, at 9:08 they were 11049076 but at 9:12 they were only 20571.

I have a more complete list of time-ticks relation from 8:36 to 9:55, but this has no scientific precision: I didn't look at the seconds when I saw the time, and I haven't checked the ticks/time periodically (it was more at random).

I don't think the Prizm RTC works the same way as the FXes, because today I just copied a clock addin from one mate's FX calc to another mate's FX calc (nobody else seems to know how to use the Link function ) and I had the opportunity to play with the addin for a while. Looks like the RTC of the old FX has a way to store the year, month and day, as well as hours, minutes and seconds, and I think each tick represents a millisecond (not 1/128 of a second or whatever it is).

My conclusion: either what we call a RTC on the Prizm is just the CPU ticks (and the Prizm has no RTC, or the RTC hasn't been found yet), or the RTC is indeed strange and not usable for human-readable time/date.

Thanks for your additional thoughts and exploration. I'm using the RTC in Tetrizm now, and it's a big improvement over when I was trying to essentially do cycle-counting to fudge lacking an asychronously-ticking clock. Also, I see from your numbers that 6894 ticks passed per minute between 8:59 and 9:07, or about 114.9 per second, which jives with the 1/128th second per tick (128 ticks per second) that we had been discussing. I'm still hopeful that we'll find an actual RTC somewhere inside that knows when the ticks clock resets and keeps track of longer increments of time.

The RTC is (almost) identical to legacy models. Its registers start at address 0xA413FEC0.
The Renesas SH-7720 manual describes the Prizm RTC in detail.

This is completely off-topic, but I notice you have a micro-SDK link in your signature; have you tried the PrizmSDK v0.3 yet for comparison? I think you might find it a bit cleaner, although of course it couldn't exist without the previous research that Simon et alia had done.

Didn't try it yet. For some reason, I have returned to the Windows platform after using Linux a few years. Didn't fit my needs for a clean and stable OS. That's why I'm switching to the new PC-BSD release (based on FreeBSD 9.0) soon, but won't use it for calculator development stuff - at least for now.


Are you kidding? The reason I created this SDK was Simon's SDK being too complicated for the average user. And I'm also planning some updates for the next months.

I totally agree that Simon's SDK was too complicated; I had mistaken "micro-SDK" for "mini-SDK". I haven't tried the microSDK yet, so I have no frame of reference for how it compares to the PrizmSDK.

Am I confusing everything, or according to Renesas's datasheet cfxm posted, the RTC should support year, month, date and even leap year adjustment?