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.
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;
}
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.
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).
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
(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"?
very, very excellent work, calc84 (and Tari!) Shall I go put the documentation on the wiki?
Time for me to make SourceCoder allow images up to 396x224 now, I guess. Very Happy And we also now have way more than the TI-Nspire's 320x240 pixels to work with. Wink
Interesting funny routine: draw VRAM to the LCD upside down (exact same speed as Bdisp_PutDisp_DD):


Code:
void flip_upside_down(void) {
   WriteLCDReg(LCD_GRAM_X, 0);
   WriteLCDReg(LCD_GRAM_Y, 0);
   
   SelectLCDReg(LCD_GRAM);
   unsigned i = 384*216;
   while(i--)
      LCDC = *((color_t*)0xA8000000 + i);
}


Anyways, seems we actually didn't get a speed increase from this. Oh well, we got more pixels and LCD control. Smile
Have we tried doing it int-wise instead of short-wise (color_t-wise) and seeing if that makes any framerate difference?
  
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
» Goto page Previous  1, 2, 3 ... 8, 9, 10, 11, 12, 13  Next
» View previous topic :: View next topic  
Page 9 of 13
» All times are GMT - 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