Casio Prizm Technical Documentation
» > >
» Goto page Previous  1, 2, 3 ... 7, 8, 9 ... 11, 12, 13  Next
» View previous topic :: View next topic  
The watchdog timer on the chip used in the prizm's should use the following two addresses

0xa4520000 - WTCNT
0xa4520004 - WTCSR

It works basically as described in the hardware manual for SH7730.

In order to use the watchdog timer it might also be necessary to clear bit 13 on the MSTPCR0(0xa4150030) register, otherwise the RCLK signal won't be passed to the WDT.

The custom chip used is in fact based of the SH7724 which is part of renesas's shmobile line of chips. The basis for this conclusion is the fact that the PVR register which specifies the processor core version is an exact match with the SH7724 in addition many of the IO modules also match up with the SH7724, including the FRQCR register which is located at 0xa4150000 and has the following structure.

31: Kick
Writing 1 here updates CPG settings
29-24: PLL
Multiplier = (PLL + 1) * 2
23-20: I_CLK
CPU Clock Divisor
15-12: SH_CLK
SuperHighway Clock Divisor
11-8: B_CLK
Bus Clock Divisor
3-0: P_CLK
Peripheral Clock Divisor

Divisor values:
0000 x1/2
0001 x1/3
0010 x1/4
0011 x1/6
0100 x1/8
0101 x1/12
0110 x1/16
1000 x1/24
1001 x1/32
1010 x1/36
1011 x1/48
1101 x1/72

The Kick bit has to have a 1 written to it before the CPU will update any changes done to the FRQCR register. All the information on the layout of the FRQCR came from the linux kernel since there is no datasheet available for the SH7724 without signing an NDA with renesas.

Also I should mention is not necessary to run from physical memory in order to access hardware registers on this chip. Since address translation only effects access to addresses in the P0 and P3 memory regions and all CPU/IO registers are in the P2 or P4 regions you can access them just fine while running from virtual memory.

Below is a set of assembly routines I wrote that can be assembled using a GCC toolchain and then called from C code that allows you to use the WDT as well as set adjust the clock.


Code:

.global _disable_wdt, _enable_wdt, _set_wtcnt, _disable_mstpcr, _enable_mstpcr
.global _set_pll_mult, _frqcr_kick, _set_iclk_div, _set_shclk_div, _set_bclk_div, _set_pclk_div

/*
 * SH7724 Watchdog timer and clock setting code
 *  By Brian Johnson
 */

/*
 * FRQCR
 * 31: Kick
 *   Writing 1 here updates CPG settings
 * 29-24: PLL
 *   Multiplier = (PLL + 1) * 2
 * 23-20: I_CLK
 *   CPU Clock Divisor
 * 15-12: SH_CLK
 *   SuperHighway Clock Divisor
 * 11-8: B_CLK
 *   Bus Clock Divisor
 * 3-0: P_CLK
 *   Peripheral Clock Divisor
 *
 * Divisor values:
 *   0000 x1/2
 *   0001 x1/3
 *   0010 x1/4
 *   0011 x1/6
 *   0100 x1/8
 *   0101 x1/12
 *   0110 x1/16
 *   1000 x1/24
 *   1001 x1/32
 *   1010 x1/36
 *   1011 x1/48
 *   1101 x1/72
 *
 * Updates to the FRQCR do not go into effect until 1 is written to the kick bit.
 *---------------------------------------------------------------------------------
 *
 * Before using the watchdog timer it migt be necessary to call enable_mtspcr(0, 13),
 * this will enable the RCLK signal to the WDT.
 */

/* void frqcr_kick() */
_frqcr_kick:
   mov.l   frqcr, r1
   mov   #0x80, r0
   shll16   r0
   shll8   r0
   mov.l   @r1, r2
   or   r0, r2
   mov.l   r2, @r1
   rts
   nop


/* void set_pclk_div(int divisor) */
_set_pclk_div:
   mov   r4, r0
   and   #0xF, r0
   mov.l   frqcr, r1
   mov.l   pclk_mask, r3
   mov.l   @r1, r2
   and   r3, r2
   or   r0, r2
   mov.l   r2, @r1
   rts
   nop


/* void set_bclk_div(int divisor) */
_set_bclk_div:
   mov   r4, r0
   and   #0xF, r0
   shll8   r0
   mov.l   frqcr, r1
   mov.l   bclk_mask, r3
   mov.l   @r1, r2
   and   r3, r2
   or   r0, r2
   mov.l   r2, @r1
   rts
   nop

/* void set_shclk_div(int divisor) */
_set_shclk_div:
   mov   r4, r0
   and   #0xF, r0
   shll8   r0
   shll2   r0
   shll2   r0
   mov.l   frqcr, r1
   mov.l   shclk_mask, r3
   mov.l   @r1, r2
   and   r3, r2
   or   r0, r2
   mov.l   r2, @r1
   rts
   nop

/* void set_iclk_div(int divisor) */
_set_iclk_div:
   mov   r4, r0
   and   #0xF, r0
   shll16   r0
   shll2   r0
   shll2   r0
   mov.l   frqcr, r1
   mov.l   iclk_mask, r3
   mov.l   @r1, r2
   and   r3, r2
   or   r0, r2
   mov.l   r2, @r1
   rts
   nop

/* void set_pll_mult(int multiplier) */
_set_pll_mult:
   mov   r4, r0
   and   #0x3F, r0
   shll16   r0
   shll8   r0
   mov.l   frqcr, r1
   mov.l   pll_mask, r3
   mov.l   @r1, r2
   and   r3, r2
   or   r0, r2
   mov.l   r2, @r1
   rts
   nop
.align 2
frqcr:
.long 0xa4150000
pll_mask:
.long 0xC0FFFFFF
iclk_mask:
.long 0xFF0FFFFF
shclk_mask:
.long 0xFFFF0FFF
bclk_mask:
.long 0xFFFFF0FF
pclk_mask:
.long 0xFFFFFFF0


/* void disable_mstpcr(int nr, int bit) */
_disable_mstpcr:
   extu.b   r5, r5
   mov   r4, r0
   and   #3, r0
   shll2   r0
   mov.l   mstpcr, r1
   mov.l   @(r0,r1), r2
   mov   #1, r3
   shld   r5, r3
   or   r3, r2
   mov.l   r2, @(r0,r1)
   rts
   nop

/* void enable_mstpcr(int nr, int bit) */
_enable_mstpcr:
   extu.b   r5, r5
   mov   r4, r0
   and   #3, r0
   shll2   r0
   mov.l   mstpcr, r1
   mov.l   @(r0,r1), r2
   mov   #1, r3
   shld   r5, r3
   not   r3, r3
   and   r3, r2
   mov.l   r2, @(r0,r1)
   rts
   nop
.align 2
mstpcr:
.long 0xa4150030


/* void set_wtcnt(char val) */
_set_wtcnt:
   extu.b   r4,r4
   mov.l   wtcnt, r1
   mov   #0x5a, r2
   shll8   r2
   or   r2, r4
   mov.w   r4, @r1
   rts
   nop
wtcnt:
.long 0xa4520000

/* void disable_wdt() */
_disable_wdt:
   mov.l   wtcsr, r1
   mov   #0xa5, r4
   shll8   r4
   mov.w   r4, @r1
   rts
   nop

/* void enable_wdt(int timer) */
_enable_wdt:
   mov.l   wtcsr, r1
   mov   r4, r0
   and   #7, r0
   or   #0x80, r0
   mov   #0xa5, r4
   shll8   r4
   or   r4,  r0
   mov.w   r0, @r1
   rts
   nop
wtcsr:
.long 0xa4520004
Thanks for the information! So, basically it's a 7730 CPG unit? In that case, the prizm cannot be further overclocked; it's already running at a PLL circuit mult. of 0b1111, or 32x. That's the highest value that can be used. However, we can underclock; I just enjoyed playing PONG at 1.8MHz (it's funny watching the screen refresh the shown pixels line by line in a very slow manner). So, while it's bad news, it could be worse.

EDIT: instructions for underclocking: copy that code above into something like overclock.S, and simply add it to the sources to be compiled (I believe with the new buildsystem you just add it to the src\ folder in your project, with the old one you add it to the CSOURCES variable and then add overclock.o to your OBJECTS variable). Then, prototype them as in the comments (here are the two important ones):


Code:
void frqcr_kick(void);
void set_pll_mult(int multiplier);


And then to go to 1.8MHz, do this:


Code:
set_pll_mult(0b000000);
frqcr_kick();


As for possible PLL values, some valid values are 0b0, 0b1, 0b11, 0b111, and 0b1111, with a few other ones I forget. The prizm is already running at the max (as far as we know), 0b1111, so switching to 0b111 will half the processing speed.

EDIT2: to the OP of the new FRQCR info, why did you write those routines in assembly? I think that writing them in C will lead to more optimized code, since you do some strange things like "mov #0x80, r0 \ shll16 r0 \ shll8 r0", where I think that simply loading a longword 0x80000000 into r0 with an offset data longword would be faster (and smaller). And, why not optimize that final "mov r2, @r1" to be after the RTS, and take out the NOP?
R O F L M A O
O
F
L
M
A
O
Quote:
Thanks for the information! So, basically it's a 7730 CPG unit? In that case, the prizm cannot be further overclocked; it's already running at a PLL circuit mult. of 0b1111, or 32x. That's the highest value that can be used.


No it is in fact an SH7724 CPG which means the PLL cab be clocked higher then x32. It can go up to x48. tough on my device i found that makes the graphics go all screwy and the highest i could get it to go reliably was x36. Also if its not already set you might try adjusting the ICLK divisor to x1/2 and get a bit more speed that way as well

Valid PLL multipliers:

000101:×12
000111:×16
001011:×24
001110:×30
001111:×32
010001:×36
010111:×48

Quote:

to the OP of the new FRQCR info, why did you write those routines in assembly? I think that writing them in C will lead to more optimized code, since you do some strange things like "mov #0x80, r0 \ shll16 r0 \ shll8 r0", where I think that simply loading a longword 0x80000000 into r0 with an offset data longword would be faster (and smaller). And, why not optimize that final "mov r2, @r1" to be after the RTS, and take out the NOP?

Yes I could optimize things things a bit more then I did when I was originally typing that out such as doing things like as you said doing the mov post rts. However if I let GCC compile this it usually produces a longer function since at the very least GCC will add a function prolog and epilog and usually move the parameters passed to the function onto the stack.
Brijohn, I'm trying to track down SIOF information for directly manipulating the RX and TX lines of the serial port, as well as flipping their directionality around and possible even using the stereo sound output that the 7724 overview datasheet promises, but the going is slow doing the translation to figure out which Port does which. I'll keep searching, but if you happen to know anything already, I'd appreciate it. Smile I'm going to focus on Port S, since that's used for SIOF on many of the other models.
brijohn wrote:
Quote:
Thanks for the information! So, basically it's a 7730 CPG unit? In that case, the prizm cannot be further overclocked; it's already running at a PLL circuit mult. of 0b1111, or 32x. That's the highest value that can be used.


No it is in fact an SH7724 CPG which means the PLL cab be clocked higher then x32. It can go up to x48. tough on my device i found that makes the graphics go all screwy and the highest i could get it to go reliably was x36. Also if its not already set you might try adjusting the ICLK divisor to x1/2 and get a bit more speed that way as well

Valid PLL multipliers:

000101:×12
000111:×16
001011:×24
001110:×30
001111:×32
010001:×36
010111:×48

Quote:

to the OP of the new FRQCR info, why did you write those routines in assembly? I think that writing them in C will lead to more optimized code, since you do some strange things like "mov #0x80, r0 \ shll16 r0 \ shll8 r0", where I think that simply loading a longword 0x80000000 into r0 with an offset data longword would be faster (and smaller). And, why not optimize that final "mov r2, @r1" to be after the RTS, and take out the NOP?

Yes I could optimize things things a bit more then I did when I was originally typing that out such as doing things like as you said doing the mov post rts. However if I let GCC compile this it usually produces a longer function since at the very least GCC will add a function prolog and epilog and usually move the parameters passed to the function onto the stack.


Ooh, very good stuff! This information is crucially important to me and the rest here -- I had checked every model but the 7724, actually, because for one there was no 7724 documentation from all the Renesas info I scoured for, so I assumed it either wasn't a real model or something along those lines Razz I will look into the screwy graphics you speak about, first at 36x and then 48x. I also have a feeling that Bdisp_PutDisp_DD is the next thing I should look into, since after realizing functions like Bdisp_AllCr_VRAM can be written to be more than twice as fast by hand, that the screen update time bottleneck can be much removed, and may fix this graphical glitching you speak of.

Would you mind if I put this information you shared on Cemetech's Prizm Wiki? Of course, with all credit given for your wonderful findings Wink

As for the function epilogue and prologue with GCC, under speed optimizations those are sometimes demolished, but your point is very good indeed and I had forgotten about that TBH.
R O F L M A O
O
F
L
M
A
O
Quote:
Brijohn, I'm trying to track down SIOF information for directly manipulating the RX and TX lines of the serial port, as well as flipping their directionality around and possible even using the stereo sound output that the 7724 overview datasheet promises, but the going is slow doing the translation to figure out which Port does which. I'll keep searching, but if you happen to know anything already, I'd appreciate it. I'm going to focus on Port S, since that's used for SIOF on many of the other models.


No sorry KermMartian, I haven't really looked into any serial interfaces outside the already listed information on the I2C. I am do currently believe that one of things kept from the base SH7724 is the two SPU2DSP units though.

Quote:

Would you mind if I put this information you shared on Cemetech's Prizm Wiki? Of course, with all credit given for your wonderful findings


No go ahead and post it on wiki if you want thats fine with me.
Interestingly enough, it is very possible to change the CPU clock divisor. It is already set on 1/3x normally, 1/2x doesn't seem to have much effect but putting it lower than 1/4x is crashing me out. Not that there's any use for changing it lower at all.

EDIT: it's not going into Pover, but here's the code to change the CPU division ratios:


Code:
#define ICLK_2 0b0000
#define ICLK_3 0b0001
#define ICLK_4 0b0010
#define ICLK_6 0b0011
#define ICLK_8 0b0100
#define ICLK_12 0b0101
#define ICLK_16 0b0110
#define ICLK_24 0b0111
#define ICLK_32 0b1000
#define ICLK_36 0b1001
#define ICLK_48 0b1010
#define ICLK_72 0b1011

void change_div(int div) {
   volatile unsigned int* frqcr = (unsigned int*) 0xA4150000;
    unsigned int cr = *frqcr;
    cr &= ~(0xF << 20);
    cr |= (div & 0xF) << 20;
    *frqcr = cr;
    *frqcr |= 0x80000000;
}
R O F L M A O
O
F
L
M
A
O
I hate to do this double post, being a goody two hooves on forums and all, but.. onto the next level of documentation! The Prizm's screen is thought to be a R61524, similar to the R61509 and R61517. The documentation for the R61509 is here: http://www.kyocera-display.com/SiteImages/PartList/CONTROLLER/Renesas%20R61509%20Ver%201.03%2020071126.pdf

Now to start by finding the memory mapped address of the controller. calc84maniac, myself, and others are discussing many things about this right now, so I'll edit in information as it's discovered, or they'll make a post and talk about it.
R O F L M A O
O
F
L
M
A
O
Great news someone is working on documenting the screen. I wonder if it's possible to use the extra pixels on the left, right and bottom borders of the screen (those that the OS only allows for changing their color).
Add-ins for the Casio fx-CG 10/20 (JPEG and PNG Viewer, Eigenmath port and more!) | tiny URL, email address and image shortener
gbl08ma wrote:
Great news someone is working on documenting the screen. I wonder if it's possible to use the extra pixels on the left, right and bottom borders of the screen (those that the OS only allows for changing their color).

I'm pretty sure it's possible, and it's also probably possible to use any rectangular screen area (which could be useful for emulators and other such things that would only use a subset of the screen)
In fact, the OS already exposes some rudimentary routines to use the screen in a selection sort of mode, but learning more about that would certainly be very helpful for, as you say, things like games and emulators that need to very rapidly refresh certain areas of the screen.
If the rest of you haven't looked at the source code to CGplayer in Cemetech's very own archives, I really really, really suggest you do. It directly uses the SIO registers, successfully, and even seems to write to flash. Crazy that it's been there all this time, and no one's cared enough to look at it. Razz
R O F L M A O
O
F
L
M
A
O
(Crossposting from the CGPlayer topic here at Cemetech)

I did extensive investigation tonight into the CGPlayer and its assumptions that the SCIF/SIOF matches the SH7730. I was particularly confused that though you equate the SCIF2 symbol to the address for SIOF on the 7730 (0xA4410000), you then access its registers as if it was indeed a scif0, and that success of your application knows that you are indeed accessing a SCIF rather than a SIOF. We could attach a serial CODEC and get great stereo sound out and in, as the SIOF information demonstrates, but sadly, I'm now 99% sure that a combination of the hardware (I see circuitry on the RX/TX lines that would force unidirectionality from examining the PCBs) and the CPU (the RxD and TxD lines on the 7730's SCIF are fixed undirectional, whereas the 7720ish ones have bidirectional lines) that we can only do mono, single-ear sound output.
KermMartian wrote:
...I was particularly confused that though you equate the SCIF2 symbol to the address for SIOF on the 7730 (0xA4410000), you then access its registers as if it was indeed a scif0, and that success of your application knows that you are indeed accessing a SCIF rather than a SIOF. ...

Yes, I did it because I tried to re-use the low level sio accessing code from fxPlayer (= code for 9860)

I would be happy if my code help you with your development, but please start with the docs of our Master Simon.
Especially I would recommend this table (see the image). I used it for audio cgplayer.
Ha, epic fail Sad
I tried to attach a file - one image, but in contrast to Omnimaga this forum doesn't support attachment.
So please read the manual attached to the Simon's mini SDK. There is everything.

Ashbad wrote:
...It directly uses the SIO registers, successfully, and even seems to write to flash....

Yes, I needed the direct register access to overclock sio, but I do not write to the flash. I tried to comment what I am doing with the flash in the source code. I try to bypass filesystem, because reading a part of the sound file is too slow. It is pretty simple I think.
Ah, I had an old version of Simon's help file that did not have that information, since I use the PrizmSDK for compiling my add-ins (and it took a bit of poking about to get CGPlayer to compile under the PrizmSDK Smile ). Based on your add-in and my own investigation I agree that the SCIF is at 0xA441000 and has the register structure of the 7730's SCIF, and I posit that it's impossible to switch this SCIF into bidirectional mode. Smile On a meta-level note, it's often hard to get Simon to share anything other than what he implicitly shares inside things like his SDK and Insight, and I want to make sure that all of the hardware information is as widely-disseminated as possible, so if you have information on syscalls or hardware that you can add to WikiPrizm, it would be greatly appreciated.
KermMartian wrote:
Ah, I had an old version of Simon's help file...
Latest version (as I know) is here:
http://ourl.ca/8207/238670
(fx_calculators_SuperH_based_10.chm)
LCD controller woot


Code:
#define SYNCO() __asm__ volatile("SYNCO\n\t":::"memory");
#define PRDR *(volatile unsigned char*)0xA405013C
#define LCDC *(volatile unsigned short*)0xB4000000

#define LCD_GRAM_X 0x200
#define LCD_GRAM_Y 0x201
#define LCD_GRAM 0x202
#define LCD_WINDOW_LEFT 0x210
#define LCD_WINDOW_RIGHT 0x211
#define LCD_WINDOW_TOP 0x212
#define LCD_WINDOW_BOTTOM 0x213

void SelectLCDReg(unsigned short reg)
{
   SYNCO();
   PRDR &= ~0x10;
   SYNCO();
   LCDC = reg;
   SYNCO();
   PRDR |= 0x10;
   SYNCO();
   return;
}

void WriteLCDReg(unsigned short reg, unsigned short value)
{
   SelectLCDReg(reg);
   LCDC = value;
   return;
}

unsigned short ReadLCDReg(unsigned short reg)
{
   SelectLCDReg(reg);
   return LCDC;
}

int main()
{
   //Fill the entire screen with black
   WriteLCDReg(LCD_WINDOW_LEFT, 0);
   WriteLCDReg(LCD_WINDOW_RIGHT, 395);
   WriteLCDReg(LCD_WINDOW_TOP, 0);
   WriteLCDReg(LCD_WINDOW_BOTTOM, 223);
   
   WriteLCDReg(LCD_GRAM_X, 0);
   WriteLCDReg(LCD_GRAM_Y, 0);
   
   SelectLCDReg(LCD_GRAM);
   unsigned i = 396*224;
   while(i--)
      LCDC = 0x0000;
}
What does this function?
Eiyeron wrote:
What does this function?
I second this. Some explanation would be awesome. Very Happy
DOes it make we acces to each border, "windows"?
  
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
Casio Prizm Technical Documentation
» Goto page Previous  1, 2, 3 ... 7, 8, 9 ... 11, 12, 13  Next
» View previous topic :: View next topic  
Page 8 of 13
» 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