There may have been time settings in the system manager in a development version of the OS, just like the battery screen we see now is no longer the one that used to accept manganese batteries and "chargeable batteries". I believe Casio decided to simplify the Prizm-specific features of the OS at some point in development...

Oh well... At least their inclusion of the RTC unit didn't go to waste

<edit>

I removed the Calendar and Clock buttons with a View menu. Here it is below:



Now, the calendar has a new view being added, the year view. Here's a WIP of the rendering of the small calendars.



I already fixed the letters 1 pixel too low. I will fix the box height being too short, add in a grid, and fix highlight issues. Now, some polling:

• I want to let you know if an event is active for a day. Should I widen it a bit and display an icon in the cell, or shade the cell a color?
  
• I left out the overlap days (from previous and next month). Should I add them? I don't know if grey will look good.
  
• Should I shade the background for weekends? (Light grey, or name your color)

Shade the cell with the "light" color for the category of the event for that day. For days with multiple events, either display the color for the first event/most used category for that day, or switch the color each second for each different category (may look ugly/flashy).


Try to use a very light grey and see if it looks nice. You could create a setting for hiding other months days', for people who don't like them anyway (you said you'll be using the Main Memory, so adding some keys to it for settings shouldn't be hard).


Do not shade (because that would get in conflict with days that have events), instead make the text color for weekends red or blue.

One more thing: do you plan on adding an "agenda" view, where we can see all events in a list for e.g. the next 30 days?
Now that I'm clearing abusing of your motivation for developing this add-in, let me add a few more crazy ideas:
- Multiple clocks/timezones
- Multiple stopwatches and countdowns
- Google Calendar and CalDAV sync (OK, I'm clearly dreaming now )

Year View: The calendar renderer is done. I left out the overlap days as it doesn't make sense to have them. Your cursor will move to the other calendars.

Events: File layout:
Code:


Multiple times, :-\ I am not considering this now. Same for the multiple stopwatches and timers. Timer will not be done for the next update.

Here is the year view now. If you see a single pixel out of place, let me know as this is the time for changes

Every pixel seems in place now I like the way weekends are colored. By the way, do you plan on adding a setting for the day the week starts at (Monday or Sunday), or would this be too difficult with the current calendar implementation?

Suggestions for the file event layout:
I see you're identificating fields by their absolute position in the file (0x0010, 0x0016, etc.). What about using a control character like 0x1D (ascii 29) to separate fields within one event, and another control character like 0x1E (ascii 30) for delimiting one event (for files with multiple events)?
1st field would be the category, 2nd field the date range...

In my opinion, this approach would have the additional benefits:
- Virtually unlimited fields in terms of length. One field could have one byte or 3000 bytes, but you'd know that when character appears, that's the start of a new field.
- Backwards compatibility. You could have e.g. 10 fields in the first version of the add-in, and make it ingore any fields past the 10th one. Then on a second version of the add-in, imagine you need to add a 11th field. I think this would break compatibility with previous calendars if your file format was used!
This new version would have no problem parsing the old format with ten fields (it'll just find out there's no eleventh one and set it empty), and the old version will have no problem parsing the new format (it'll just ignore the 11th field).

And the following cons:
- Too much of an hassle for a simple event storage? I have no idea if it's very difficult to parse a file and look for special characters (I'd do it with some loops, but I never tried that TBH).
- Uses more space (one more byte per field, the same bytes per event as the pointer to the next event would not be needed).

Also, for multiple timezones with a clock for each, I don't think it's such an hard thing: just add an offset of X (or -X) hours to the "real" clock (RTC), which could be set to UTC (and then people would select their main timezone). Don't worry about this now though, as I think this is something I can hack into the add-in when it is finished

Looks really good. Can't wait for this version to come out!

Maybe this is a ea-200 function, i shearched in OS and i found this modes is ea-200
[normal mode]
[clock mode]
[sound mode]
[realtime mode], and other...

i think, calculator can output sound to ea-200, i found also references to microphone related with ea-200

some ea-200 text strings are registed only in OS in english.

You are correct. If you look at the app on your calculator and try to set up the equipment, it lists all of the modes it supports.

It outputs sound in the form of a Y= waveform iirc

If I may nitpick, the blue/green background/foreground combination makes me sad, but other than that it looks great. Keep up the good work!

If you find a better color combo (16 bit fore- and background), you can post them here for others to pick I am fine with changing it

I'd prefer a color plus a non-color: ie, a colored background with grayscale text, or a light gray background with blue text.

Hmm... How about one of these two combos?

The "Time settings" string is translated in all languages, but that doesn't matter as I already found out where it appears: in the Spreadsheet mode (can't remember well exactly but I found that out yesterday).
It's unlikely Casio ever thought about adding a human-readable clock for daily use to the UI of the Prizm OS, but having settings for setting the RTC and then using it for something useful would only bring advantages (e.g. the files would get the correct creation and modification date, as opposed to some fixed date sometime in 2010).

About the color scheme: well, you have three options - either use the flashy 8-bit style used by Casio in most OS screens other than the Menu (which not many people like but goes in style with everything else in the OS), get a more subtle color sheme, or else go through the hassle of supporting custom colors with a settings screen (not something easy and not very useful).

About a more subtle color scheme: most calendar softwares I see today are very white-ish (perhaps because that's the color of the paper?) and then have the lines, text, etc. in color (usually light greys, black, dark blues, dark reds, dark greens...). Perhaps you could try to match that style?

The Prizm does have syscalls for reading and making numeric dates from text strings, as well as getting and setting the RTC clock.

It isn't 8 bit, it is 3 bit (I like it and don't see problems with it). This add-in (as well as my other utility add-ins) is trying to fit in nicely with the OS. I do not want to break from that. Otherwise I would have made this add-in differently.

Initially my goal was, and still it, to use mostly 3 bit colors. The only non-3-bit color I use is COLOR_LIGHTGRAY/COLOR_LIGHTSLATEGRAY, the rest are 3-bit. I don't want to use non-colorful colors since, well, it is a Prizm and the OS tries to use colors to present data better.

The paper theme that you are describing sounds like how Windows made their calendars. I don't know what they are now.

Yes, perfect! Those are exactly the sort of color combinations that I love.

I'm OK with the 3-bit colors, as the purpose is to fit in with the OS. If I am OK with the OS color scheme, I'm not - an example: the red looks a bit like pink on my Prizm, and I'd like to have some more saturated red instead.



I don't know either since I don't use Windows for ages... Google Calendar, Thunderbird-Sunbird and Evolution are white, though (the last two ones with customizable color schemes, most likely)

When you have time, could you please post the source code for the work you've done so far? I'd like to have the calendar ready before mid-September, but I understand people have more things to do than code for me, so I'd like to have a try at finishing the calendar events part.

Also, I suppose you are using your fork of libfxcg with more syscalls than the original one, and that it may be somewhere on GitHub. If not, could you please post it too?

I don't have code in for events, so there's nothing to post for that.

Here's the github url: https://github.com/AHelper/libfxcg/tree/new-syscalls

If only you could make it put the clock at the top at all times(See the Red on top):



I used one of your images for reference.

Don't you have code for the mini-calendars on the under-development year view?

I may start working on an event parser that copies things from and to the main memory. I'll try to use my format proposal with control characters separating the fields, though

Spenceboy98: we'd need to hack into the syscalls that draw the header for that, and that's still too risky/impossible with the current knowledge of the OS.

(BTW: did you know fx-CG Manager Plus has a config function to automatically set the emulated calc's RTC to the system RTC? Perhaps Casio really planned to do something important with it!)