cfxm wrote:
Quote:
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?

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.

Quote:
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.

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. Smile
We'll have to talk then, maybe we can work together on standardizing the library and includes that come with the SDK's. The orginization simon used it just a mess but at the same time I would rather not have 3 different SDK's using 3 different include file setups.

I am the main maintainer of the GCC based PrizmSDK, which would work just fine on your PC-BSD I might add. Wink
TheStorm wrote:
We'll have to talk then, maybe we can work together on standardizing the library and includes that come with the SDK's. The orginization simon used it just a mess but at the same time I would rather not have 3 different SDK's using 3 different include file setups.

I am the main maintainer of the GCC based PrizmSDK, which would work just fine on your PC-BSD I might add. Wink

See also. (Didn't want to clutter up this thread with politicking)
Tari wrote:
TheStorm wrote:
We'll have to talk then, maybe we can work together on standardizing the library and includes that come with the SDK's. The orginization simon used it just a mess but at the same time I would rather not have 3 different SDK's using 3 different include file setups.

I am the main maintainer of the GCC based PrizmSDK, which would work just fine on your PC-BSD I might add. Wink

See also. (Didn't want to clutter up this thread with politicking)
Thanks for that. Cfxm, Jonimus, Tari, myself, let's continue this discussion in that thread; everyone else, RTC talk resumes here.
gbl08ma wrote:
Am I confusing everything, or according to Renesas's datasheet cfxm posted, the RTC should support year, month, date and even leap year adjustment?

Yes, it supports all of this. See my include file here: http://cemetech.net/forum/viewtopic.php?p=170835#170835
So the RTC doesn't reset (only the ticks value is reset at "midnight", which isn't really midnight because the RTC comes from factory with some random time, like on the old FXes) and it should ave all the features that the old FX calcs have. Great!
Great indeed! This means that the Prizm shells that need to get written soon can have a nifty clock, as well as (hopefully) a reasonable way of setting the time.
DoorsCS for Prizm anytime soon? Very Happy

I think that if indeed there is a limit on the number of add-ins the Prizm can show on the menu, a shell will be necessary. If the limit is on the shortcut letter Z, then I'll soon reach it, as I already have enough menu items to get to V. At this point, folders would come handy too.

But for now, I'm more interested in a clock utility like there is for the FX9860. If only I could understand what cfxm's code does, and how it helps gathering the date and time in a human-readable format...
The menu can handle quite a large number of add-ins, well past z from what I've seen.
So it just stops attributing keyboard shortcuts to the items after Z?
(sorry for offtopic...)
gbl08ma wrote:
DoorsCS for Prizm anytime soon? Very Happy
That's the plan. Smile I guess that might be my first or second Prizm project after I finish Tetrizm.

Quote:
I think that if indeed there is a limit on the number of add-ins the Prizm can show on the menu, a shell will be necessary.
Actually, one of my biggest concerns is a header that wastes less space than regular Prizm add-ins' headers.q
That's great news about DoorsCS and Prizm development Smile

Quote:
a header that wastes less space than regular Prizm add-ins' headers.


Perhaps the complete lack of an header would help? Of course that would strip icons, version and title info, but would make the size of apps much smaller.
The .bin file that results of compilation is really small, when compared to the g3a file produced by mkg3a. AFAIK the bin file contains all the necessary code for running the add-in. In that case, a shell that was able to launch and run .bin files directly, without the need to wrap them in a g3a, would be of great use. And of course, one can develop its own add-in wrapper format and provide a launcher for it (I guess this is what you're talking about).
Indeed, and that's something we've discussed in several topics here on Cemetech, especially what a proper header that several shells could share might look like. We discussed a variable-sized header with a few basic fields as well as the ability to contain arbitrary shell-specific fields like type tagging, icons, etc.
At the cost of making the icon(s) ugly when viewed from Prizm menus rather than some theoretical shell, it wouldn't be too difficult to embed code in the icon fields of the g3a header. Those aren't loaded into memory at runtime (IIRC) so a bit of a dynamic linker would be needed.

I think the some of the biggest gains would be had from a dynamic linking scheme, so we could have a shared libfxcg (and whatever else) object.
I'd very heartily support that, but it seems I've once again led us off-topic. Perhaps we already have a general shell topic of some kind around here that could support this sort of discussion while we return to talking about the RTC specifically. Smile
From me reading many SuperH docs and from my testing, I am sure to say that the RTC unit has many registers (constant between many CPU versions), the 64Hz counter, the second, minute, and hour counters, and others. The first 4 (64,s,m,h) are 8 bits long, with 8 bit padding. At R64CNT (0xAxxxFEC0) is the 64 Hz counter, read only. At RSECCNT (0xAxxxFEC2) is a read/write counter for seconds, but packed for 2 digit displaying.

Here is a code demo showing the program running the RTC clock and using the 2 Hz counter in the 64 Hz counter:
Code:
#include <display_syscalls.h>
#include <keyboard_syscalls.h>
#include <CONVERT_syscalls.h>
#include <color.h>
#include <display.h>
#include <keyboard.hpp>

void main(void) {
    int oldsec,sec;
    int count = 0;

    /** A counter running at 64Hz from the 128Hz counter
     *
     * This Port is made up of 6 bits
     * |x|1|2|4|8|16|32|64|
     *
     * This port is updated when the 128 Hz timer carries over.
     * Therefore, bit 1 is set every 64 Hz, but stays set.
     * you must wait for the bit to return to 0 if you want to opperate at 64 Hz.
     */
    volatile unsigned char *port64 = 0xA413FEC0;
    /** A status register for the RTC unit.
     *
     * bit 7 is set after a read/write to an RTC register if the 128 Hz timer carries.
     * If this happens, any reads or writes are invalid and must be repeated.
     * Bit 7 must be manually reset to 0.
     *
     * Usage:
     * - reset bit 7 of RCR1
     * - read R64CNT
     * - if bit 7 of RCR1 is set, reset bit 7 and reread R64CNT
     */
    volatile unsigned char *portRCR1 = 0xA413FEDC;
    /** (For all below) Packed digits of 2 digit numbers.
     *
     * Writing is allowed, but must follow a procedure.  See the SH7720 docs for more info.
     * RCR1 bit 7 applies to this for both reads and writes.
     *
     * This register contains a packed 2 digit number in 134 format. Example below
     * |7|6 - 4|3 - 0
     * ----------------
     * |x| 10s |  1s
     *
     * So, bits 0-4 are the first number from 0-9
     * bits 4-6 are the second number from 0-5
     */
    volatile unsigned char *ports = 0xA413FEC2;
    volatile unsigned char *portm = 0xA413FEC4;
    volatile unsigned char *porth = 0xA413FEC6;

    *ports = 0;
    *portm = 0;
    *porth = 0;

    char buffer[10];
    buffer[0] = ' ';
    buffer[1] = ' ';
    Bdisp_EnableColor(1);

    while (1) {
        if(PRGM_GetKey() == 48)
   {
     int r,c,k;
    
     GetKeyWait_OS(&c,&r,0,0,0,&k);
   }
        Bdisp_AllClr_VRAM();
        while (*port64 & 0b00100000);

        while (!(*port64 & 0b00100000));
        count++;

        itoa(count, buffer+2);
        PrintXY(1,1,buffer, TEXT_MODE_NORMAL, TEXT_COLOR_BLACK);

        itoa(((*porth >> 4) * 10) + (*porth & 0b1111), buffer+2);
        PrintXY(4,2,buffer, TEXT_MODE_NORMAL, TEXT_COLOR_BLACK);

        buffer[2] = ':';
        buffer[3] = 0;
        PrintXY(6,2,buffer, TEXT_MODE_NORMAL, TEXT_COLOR_BLACK);
        itoa(((*portm >> 4) * 10) + (*portm & 0b1111), buffer+2);
        PrintXY(7,2,buffer, TEXT_MODE_NORMAL, TEXT_COLOR_BLACK);

        buffer[2] = ':';
        buffer[3] = 0;
        PrintXY(9,2,buffer, TEXT_MODE_NORMAL, TEXT_COLOR_BLACK);
        itoa(((*ports >> 4) * 10) + (*ports & 0b1111), buffer+2);
        PrintXY(10,2,buffer, TEXT_MODE_NORMAL, TEXT_COLOR_BLACK);

        Bdisp_PutDisp_DD();

    }
    return;

}
Are any of those writeable? Why is the clock 64Hz but we get 128 ticks a second from RTC_GetTicks() - do you think it multiplies that value by two?
0b01111111 == bits 0-1 for the 7 counters == 127. Remember that they toggle, so at 0 seconds, it is 0. at 2/128 it is 1. at 3/128 it is 0. It is intended for bit checking. bit 0 turns from a 0 to a 1 at 64 Hz, so it toggles at 128 Hz.

The 64 Hz timer isn't writable, but the others listed there are.
Ohh, so the 64Hz clock has an edge-triggered counter on it that triggers on both up and down edges, Now it makes sense.
It technically isn't a clock. There is a 128 Hz clock in the RTC unit. When that clock carries, it adds one to the 64Hz counter.
AHelper wrote:
It technically isn't a clock. There is a 128 Hz clock in the RTC unit. When that clock carries, it adds one to the 64Hz counter.
Hmm, this all seems rather redundant. Why not just read the 64Hz "clock" from the 128Hz clock >>1, then? I'm not sure I quite see the point.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement