I don't think we're completely sure about that. I'm not sure if it is an SH3 or FPU-less SH4A either...
PierrotLL wrote:
Thanks for the file.
About CPU, I don't know, SH7705 is used by fx-9860G. I read that Prizm CPU is in SH4-A family.
Indeed, but as JosJuice said, despite all of the very hard work people have put into trying to narrow down what processor model it is, exactly, we are thus far unsure what the precise configuration is, including whether it does or does not have an FPU. About CPU, I don't know, SH7705 is used by fx-9860G. I read that Prizm CPU is in SH4-A family.
Mmkay, then we wont be able to over clock it until we find the exact model version. I don't think whether or not it has an FPU will affect the overclocking/model problem I ran into, fortunately. The reason we need to know the exact version is because there's literally hundreds of iodefine.h headers for the Super-H family, all with very different addresses for the CPG and WDT struct instances.
PierrotLL wrote:
Thanks for the file.
About CPU, I don't know, SH7705 is used by fx-9860G. I read that Prizm CPU is in SH4-A family.
Yes that's true, the Prizm uses a custom SH4A and therefore the frequency clock code for an SH3 is incompatible. Also the problem with Ashbad's code earlier was that it was executed from virtual memory (the 0x30000000 space) but its's required that code that interfaces with the hardware must be executed from either the p1 or p2 address space which is anywhere from 0x80000000 to 0xbfffffff). What I've done is written a routine that takes a function, allocates space in the heap for it, copies it there, and returns a pointer to its new address. Using that in combination with a proper overclocking routine should yield the correct results. Also it's important that the watchdog timer is used whenever the frequency is updated because it takes a few milliseconds for the crystal timers to stabilize. If anyone wants my routine I'd be happy to release it but do note that I haven't tested it yet and it only works in gcc due to its use of some language extensions. About CPU, I don't know, SH7705 is used by fx-9860G. I read that Prizm CPU is in SH4-A family.
well, wouldn't all you need for a function like that be:
Code:
Code:
void overclock(void)
...
overclockend:
}
memcpy(malloc((int)overclock - (int))&&overclockend), (void*)overclock, (int)overclock - (int))&&overclockend);
Tried again this evening, still failed. Though, this time, something happens! A crash! 
Though I'm sure it has to do with executing code from the heap, and not because the stuff is incorrect (if it even is correct based on 7705.h's definition of the CPG and WDT...) and this time, I even make sure to reset the watchdog timer. Well, viola (sorry for the raw addresses, these are from addresses for the CPG and WDT structs in the 7705.h header -- I'm going to rewrite it at a later time with the actual names, and then test ALL _o/ the 100+ different header files...)
Code:
EDIT: oh, and for fun...
Though I'm sure it has to do with executing code from the heap, and not because the stuff is incorrect (if it even is correct based on 7705.h's definition of the CPG and WDT...) and this time, I even make sure to reset the watchdog timer. Well, viola (sorry for the raw addresses, these are from addresses for the CPG and WDT structs in the 7705.h header -- I'm going to rewrite it at a later time with the actual names, and then test ALL _o/ the 100+ different header files...)
Code:
void overclock(void) {
*((unsigned short*)(0xFFFFFF84)) = 0x5a00;
*((unsigned short*)(0xFFFFFF86)) = 0x5a02;
*((unsigned short*)(0xFFFFFF80)) = 0x8210;
*((unsigned short*)(0xFFFFFF84)) = 0x5a00;
*((unsigned short*)(0xFFFFFF86)) = 0xa502;
return;
}
overclockend: ;
void*asdf = malloc((int)overclock - (int)&&overclockend);
memcpy(asdf, (void*)overclock, (int)overclock - (int)&&overclockend);
void (*overclock_me_bro)(void) = (void (*)(void))asdf;
overclock_me_bro();EDIT: oh, and for fun...
Good luck, sir, and I am very happy that you're attempting this, especially given the Nspire's recent GUI-ful overclocking. If you get something working, I'd love to through a quick little spiffy GUI on top.
This is what Simon sent me some time ago regarding the Prizm's frequency control register:
Please use Google Translate or the like.
Quote:
Beim Clock Pulse Generator handelt es sich offensichtlich fast um den des Mutter-Prozessors 7730.
Im Bootcode wird Folgendes gemacht:
ROM:800006B6 mov.l @(h'C4,pc), r6 ; [8000077C] = FRQCR
ROM:800006B8 mov.l @(h'C4,pc), r7 ; [80000780] = h'F00F0
ROM:800006BA mov.l @(h'C8,pc), r1 ; [80000784] = h'8F102203
ROM:800006BC mov.l @r6, r2
ROM:800006BE and r7, r2
ROM:800006C0 or r1, r2
ROM:800006C2 mov.l r2, @r6
Die verwenden einige undokumentierte bzw. verbotene Bit-Kombinationen.
HIGH 10 prohibited
PLL 01111 x16
CPU 0001 prohibited
SH 0010 x1/2
Bus 0010 x1/2
Peripheral 0011 prohibited
Da kann man nur ausprobieren.
Ich selbst glaube daran, dass Übertakten, wenn es auch keine sofortigen Konsequenzen hat,
die Schaltkreise strapaziert, d. h. die Lebensdauer verringert.
Der Prozessor muss definitiv bei einer höheren Temperatur arbeiten.
Batterie-Lebensdauer wird auch kürzer sein.
Im Bootcode wird Folgendes gemacht:
ROM:800006B6 mov.l @(h'C4,pc), r6 ; [8000077C] = FRQCR
ROM:800006B8 mov.l @(h'C4,pc), r7 ; [80000780] = h'F00F0
ROM:800006BA mov.l @(h'C8,pc), r1 ; [80000784] = h'8F102203
ROM:800006BC mov.l @r6, r2
ROM:800006BE and r7, r2
ROM:800006C0 or r1, r2
ROM:800006C2 mov.l r2, @r6
Die verwenden einige undokumentierte bzw. verbotene Bit-Kombinationen.
HIGH 10 prohibited
PLL 01111 x16
CPU 0001 prohibited
SH 0010 x1/2
Bus 0010 x1/2
Peripheral 0011 prohibited
Da kann man nur ausprobieren.
Ich selbst glaube daran, dass Übertakten, wenn es auch keine sofortigen Konsequenzen hat,
die Schaltkreise strapaziert, d. h. die Lebensdauer verringert.
Der Prozessor muss definitiv bei einer höheren Temperatur arbeiten.
Batterie-Lebensdauer wird auch kürzer sein.
Please use Google Translate or the like.
Thanks for that, Cfxm! I've documented that piece of information on the Overclocking page of the up-and-coming Prizm wiki; hopefully you or Ashbad will be able to further expand it.
hmm, so his input is some code from the bootloader that he believes sets the frequency rate -- and asserts that it lowers battery life at higher speeds (makes sense, which is probably why the processor is set primarily at an underclocked rate). Anyone super good with superH 3 assembly (pun intended), could you please explain what his assembly chunk does? It seems far different than what mine did. For those who want some good documentation, here's the PDF manual for the SH3 7730's hardware; for stuff related to this, C-f "CPG", "WDT", "WatchDog Timer", etc.
http://documentation.renesas.com/doc/products/mpumcu/rej09b0359_sh7730hm.pdf
And finally, I can try the documented C code for overclocking to 2** MHz with the 7730.h header today, hopefully with success.
EDIT: And Kerm, RE: the new Overclocking page, I merged it with the CPU Clocks page I made yesterday, for less clutter, FYI -- could you delete the old Overclocking page?
http://documentation.renesas.com/doc/products/mpumcu/rej09b0359_sh7730hm.pdf
And finally, I can try the documented C code for overclocking to 2** MHz with the 7730.h header today, hopefully with success.
EDIT: And Kerm, RE: the new Overclocking page, I merged it with the CPU Clocks page I made yesterday, for less clutter, FYI -- could you delete the old Overclocking page?
Overclocking definitely lowers battery life; that's a well-established principle of overclocking. 
I'd recommend that perhaps someone like Fishbot might be able to shed some light on that code.
a, you wrote a thorough overclocking/CPU clocking page! Very very impressive, sir.
I'd recommend that perhaps someone like Fishbot might be able to shed some light on that code.
a, you wrote a thorough overclocking/CPU clocking page! Very very impressive, sir.
I somewhat remember that little piece of code in the OS, but I'm not entirely sure it does what we currently think it does. I can't confirm that, as of yet.
KermMartian wrote:
a, you wrote a thorough overclocking/CPU clocking page! Very very impressive, sir.
I wish I could take all the credit. Alas, I did <50% of the work, a decent amount is edited from the other Prizm Wiki.
Ashbad wrote:
KermMartian wrote:
a, you wrote a thorough overclocking/CPU clocking page! Very very impressive, sir.
I wish I could take all the credit. Alas, I did <50% of the work, a decent amount is edited from the other Prizm Wiki.
KermMartian wrote:
Ashbad wrote:
KermMartian wrote:
a, you wrote a thorough overclocking/CPU clocking page! Very very impressive, sir.
I wish I could take all the credit. Alas, I did <50% of the work, a decent amount is edited from the other Prizm Wiki.
Indeed. I'm unsure how to even make references work, though, once I know, cited it shall be!
So, I'm pretty sure Casio uses a custom CPU for cost reasons, so they can remove the FPU and put the die directly on the board and drop some epoxy.
BTW, here are some pics of the PCB (not from) me: 1 2
I'd really like to have higher quality pictures as those ones are quite meh
Also, on the first pic you can see "LY755", which can be seen in the developper/debugging menu and seems to reference some kind of debugging/serial tool. There is also a file called SerLY755A.dll in the emulator's directory
EDIT: The CPU may support JTAG, there are probably pins somewhere...
EDIT 2: The link port MAY be serial/UART. Here is a pinout
EDIT 3: Look@ Test Mode
BTW, here are some pics of the PCB (not from) me: 1 2
I'd really like to have higher quality pictures as those ones are quite meh
Also, on the first pic you can see "LY755", which can be seen in the developper/debugging menu and seems to reference some kind of debugging/serial tool. There is also a file called SerLY755A.dll in the emulator's directory
EDIT: The CPU may support JTAG, there are probably pins somewhere...
EDIT 2: The link port MAY be serial/UART. Here is a pinout
EDIT 3: Look@ Test Mode
The link port is definitely serial. Read this topic:
http://www.cemetech.net/news.php?id=476
http://www.cemetech.net/news.php?id=476
Well, working a lot on this tonight, hopefully with much luck. Since the general concensus here is that the Prizm is run by a SH4-A, likely the 7730 specifically, I'm reading into the hardware specs for the 7730 and will test some C code soon. The C code for overclocking the SH4(-A) is a lot different than the SH3(-E), so the current C code on the old prizm wiki won't work, likely (the structure and general addresses of the CPG and WDT and related "registers" like the FRQCR, etc. are very different...)
One thing that stays the same mostly between models in the SH4 family is detecting the current clock speed ratio. Since the base freq is apparently 27MHz and the one it's set at is apparently decided here to be 58MHz, the 5 bit STC struct in the FRQCR from bits 28:24 should be 00001. If this is true the Prizm is highly likely to be of a SH4-A variety.
EDIT: ^ this is actually wrong. The above has to do with the PLL, not the frequency. The frequency is in a division ration, not multiplication. Bits [23:8] are holding the division values for the bus, SH, and CPU clock speeds. I'll post the speeds here once I have confirmed them.
And for those without the large set of iodefine.h files for each superH[3|4] model, here is the one for the 7730 (warning it's very large, >3000 lines so pastebin's line count looks a bit weird as a result):
http://pastebin.com/xiyV8CZs
And, here's the main part of the accompanying 7730.c file it came with. This chunk of code apparently sets up the hardware for operation, so somewhere in the bootloader/start of the OS the assembled version of this will likely be found. Meaning that some code loading a lot of '1' values to addresses at or slightly past 0xFFE00000 (the location of the SCFI0 stuct) is where it's taking place. The importance? The clock frequency setting code is likely very soon after this chunk of code, probably within 1000 or less instructions from it. If someone with a Prizm diassembly can look for a pattern like this (*cough* Graphmaster *cough*) it would be very beneficial.
http://pastebin.com/UavARYWJ
***EDIT:***
Memory executed from the heap at all will cause an instant crash. We need to find another way to make this be executed from non-virtual memory. Ideas?
EDIT: Read the logs below to see Fishbot's idea on how to do this. He also says that the reason it doesn't work in the Heap is likely because the heap might be in P4 memory (no access to physical mem)
****EDIT:****
Well, adding this to the new wiki, I read through the hardware doc thoroughly, and made my own commented struct for the FRQCR register on the SH4 7730. The general layout should stay the same throughout all SH4-A models, but the address is variable. I provided bit fields for the register, along with read/write status and values allowed and their consequences.
Code:
(just throwing this out there for future reference, since this may be a SH4-A 7730, and this struct makes it easy to find out and change all the clock values_
EDIT:
Edited the new wiki's page on this by A LOT. Now includes SH4-A information, along with some structure/example code, and some documentation of the SuperHyway bus clock for which control ratios are found in the FRQCR; also included info on why the "copy to heap" method won't work for executing code out of virtual mem space. (Now I can take credit, Kerm, I threw out 80% of the old info and rewrote most of it \o/)
EDIT: for those not just in #prizm, here's some interesting info on Fishbot's new idea on executing priv'd code, allowing for overclocking:
One thing that stays the same mostly between models in the SH4 family is detecting the current clock speed ratio. Since the base freq is apparently 27MHz and the one it's set at is apparently decided here to be 58MHz, the 5 bit STC struct in the FRQCR from bits 28:24 should be 00001. If this is true the Prizm is highly likely to be of a SH4-A variety.
EDIT: ^ this is actually wrong. The above has to do with the PLL, not the frequency. The frequency is in a division ration, not multiplication. Bits [23:8] are holding the division values for the bus, SH, and CPU clock speeds. I'll post the speeds here once I have confirmed them.
And for those without the large set of iodefine.h files for each superH[3|4] model, here is the one for the 7730 (warning it's very large, >3000 lines so pastebin's line count looks a bit weird as a result):
http://pastebin.com/xiyV8CZs
And, here's the main part of the accompanying 7730.c file it came with. This chunk of code apparently sets up the hardware for operation, so somewhere in the bootloader/start of the OS the assembled version of this will likely be found. Meaning that some code loading a lot of '1' values to addresses at or slightly past 0xFFE00000 (the location of the SCFI0 stuct) is where it's taking place. The importance? The clock frequency setting code is likely very soon after this chunk of code, probably within 1000 or less instructions from it. If someone with a Prizm diassembly can look for a pattern like this (*cough* Graphmaster *cough*) it would be very beneficial.
http://pastebin.com/UavARYWJ
***EDIT:***
Memory executed from the heap at all will cause an instant crash. We need to find another way to make this be executed from non-virtual memory. Ideas?
EDIT: Read the logs below to see Fishbot's idea on how to do this. He also says that the reason it doesn't work in the Heap is likely because the heap might be in P4 memory (no access to physical mem)
****EDIT:****
Well, adding this to the new wiki, I read through the hardware doc thoroughly, and made my own commented struct for the FRQCR register on the SH4 7730. The general layout should stay the same throughout all SH4-A models, but the address is variable. I provided bit fields for the register, along with read/write status and values allowed and their consequences.
Code:
struct st_FRQCR {
unsigned int PLL_VCO_selection : 2; /* [31:30] R/W */
/*
0b11 = low speed mode
0b00 = high speed mode (over or at 150MHz)
ALL OTHER VALUES RESTRICTED
*/
unsigned int : 1; /* [29] R */
/*
reserved, always write with 0b0
*/
unsigned int PLL_circuit_multiplication_ration : 5; /* [28:24] R/W */
/*
0b00001: ×2
0b00010: ×3
0b00011: ×4
0b00101: ×6
0b00111: ×8
0b01111: ×16
ALL OTHER VALUES RESTRICTED
*/
unsigned int CPU_clock_division_ratio : 4; /* [23:20] R/W */
/*
0b0000: ×1/1
0b0010: ×1/2
0b0101: ×1/4
0b0111: ×1/6
0b1000: ×1/8
0b1001: ×1/10
0b1010: ×1/12
0b1011: ×1/16
0b1100: ×1/20
ALL OTHER VALUES RESTRICTED
*/
unsigned int : 4 /* [19:16] R */
/*
reserved, always write with 0b0000
*/
unsigned int SH_clock_division_ratio : 4; /* [15:12] R/W */
/*
0b0000: ×1/1
0b0010: ×1/2
0b0101: ×1/4
0b0111: ×1/6
0b1000: ×1/8
0b1001: ×1/10
0b1010: ×1/12
0b1011: ×1/16
0b1100: ×1/20
ALL OTHER VALUES RESTRICTED
*/
unsigned int bus_clock_division_ratio : 4; /* [11:8] R/W */
/*
0b0000: ×1/1
0b0010: ×1/2
0b0101: ×1/4
0b0111: ×1/6
0b1000: ×1/8
0b1001: ×1/10
0b1010: ×1/12
0b1011: ×1/16
0b1100: ×1/20
ALL OTHER VALUES RESTRICTED
*/
unsigned int : 4 /* [7:4] R */
/*
reserved, always write with 0b0000
*/
unsigned int peripheral_clock_division_ratio : 4; /* [3:0] R/W */
/*
0b0000: ×1/1
0b0010: ×1/2
0b0101: ×1/4
0b0111: ×1/6
0b1000: ×1/8
0b1001: ×1/10
0b1010: ×1/12
0b1011: ×1/16
0b1100: ×1/20
ALL OTHER VALUES RESTRICTED
*/
}
st_FRQCR*FRQCR = (st_FRQCR*)0xA4150000;(just throwing this out there for future reference, since this may be a SH4-A 7730, and this struct makes it easy to find out and change all the clock values_
EDIT:
Edited the new wiki's page on this by A LOT. Now includes SH4-A information, along with some structure/example code, and some documentation of the SuperHyway bus clock for which control ratios are found in the FRQCR; also included info on why the "copy to heap" method won't work for executing code out of virtual mem space. (Now I can take credit, Kerm, I threw out 80% of the old info and rewrote most of it \o/)
EDIT: for those not just in #prizm, here's some interesting info on Fishbot's new idea on executing priv'd code, allowing for overclocking:
Quote:
22:07 *** Ashgood joined #prizm
Discussing the Casio Prizm | Notable Community Projects: Khavi by Fishbot, Obliterate by KermMartian, Walnut by z80man
Topic set by Fishbot!Mibbit@97-117-133-242.phnx.qwest.net on Thu Jun 16 2011 21:39:38 GMT-0400 (Eastern Daylight Time)
22:07 nikky herf derf
22:08 KermM HERF DERF
22:09 KermM nikky, I think your presence in this channel means you need to start posting Prizm articles on ticalc.org
22:09 nikky Okay
22:09 nikky I'll start posting anti-prizm articles at once.
22:09 Ashgood coolstory
22:09 grphmstur hey, question
22:10 nikky Decrying you all as traitors.
22:10 Ashgood yep?
22:10 grphmstur if the OS starts at 0x8000 0000, why does it make calls to 0xA000 addressees?
22:10 Ashgood that's some hardware specific stuff
22:10 Ashgood IIRC
22:10 Ashgood plus I think some vector table is there
22:10 grphmstur It jumps to it.
22:10 grphmstur the vector table is reasonable
22:11 grphmstur also. 1.03 is out
22:11 Ashgood I think the sycall vector is there
22:11 grphmstur what about A000 069E?
22:11 grphmstur or 63C?
22:11 Ashgood no idea
22:11 Ashgood where does it call to it?
22:12 Ashgood It's likely just part of the vector table as well
22:12 grphmstur beginning of the OS it seems
22:12 Ashgood hmm
22:13 Ashgood maybe some lower level routines in the vector table?
22:13 grphmstur well, it's strange
22:13 Ashgood honestly I can't remember
22:13 grphmstur why do we assume that the OS runs at 0x8000 again?
22:14 Ashgood one thing, I mistaked
22:14 Ashgood the vector table is at "0x80020070"
22:14 Fishbot Is this prizm talk?
22:14 grphmstur okay, do we have a list of those
22:14 grphmstur yes, Fishbot
22:14 Fishbot Hi
22:14 Fishbot Okay, the A000**** addresses are ROM and OS code if I recall
22:15 Ashgood here's some of the syscalls on the vector table: http://prizmwiki.omnimaga.org/wiki/Syscalls
22:15 Fishbot The vector table is *NOT* at 80020070
22:15 Ashgood where is it?
22:15 *** TC01 quit (Quit: ChatZilla 0.9.86.1-rdmsoft [XULRunner 1.9.0.17/2009122204])
22:15 Ashgood ah, I see
22:15 Fishbot The syscalls are at approximately ~80050070
22:15 KermM Warning #1: Fishbot: Illegal use of colors
22:15 grphmstur lol
22:15 Ashgood
22:15 KermM
22:15 Ashgood shut up fake KermM
22:15 Fishbot The vector table is at around 80020100
22:16 Ashgood ah
22:16 Fishbot I don't know why my IRC client is doing that
22:16 Ashgood He's at it again!
22:16 Fishbot Test
22:16 Fishbot Okay
22:17 Fishbot The only thing that's at 80020070 is the hash function that's used to look up the syscall in the vector table
22:17 Ashgood So fishbot, I found out that copying code to the heap and executing it there doesn't work
22:17 Fishbot Hm?
22:17 Fishbot What address?
22:17 Ashgood allocated
22:18 Ashgood dynamically
22:18 Ashgood (malloc)
22:18 Fishbot Okay
22:18 Ashgood z80man's idea, actually
22:18 Ashgood instant crash-a-saurus-rex!
22:18 Fishbot That means it's from one of the other Vmem areas
22:18 Ashgood ah
22:18 Fishbot Code normally executes from P2, which has execution privileges.
22:18 grphmstur r15 has something to do with the stack, right Fishbot?
22:18 Fishbot It might be in P4
22:18 Fishbot Yes
22:18 *** Goplat quit (Read error: Operation timed out)
22:19 Fishbot r15 is SP
22:19 Ashgood apparently changing the FRQCR can only be changed by code in non-virtual mem
22:19 Fishbot We knew that
22:19 Ashgood indeed
22:19 Fishbot Well, only in code that can access non-virtual mem
22:19 grphmstur then how are you going to manage that?
22:20 Fishbot I have to figure out how to write to flash first
22:20 Fishbot Or at least where the OS writes files in flash
22:20 Ashgood then maybe strap it to an existing syscall?
22:20 Ashgood that is never used?
22:20 Ashgood (probably a bad idea, but just throwing out ideas to start)
22:20 Fishbot Well, to open flash, you need non-vmem code
22:21 *** Goplat joined #prizm
22:21 Fishbot All the syscalls are in flash...
22:21 Fishbot So it would have to write a file, find that file in physical memory, have the OS map it in, then pass it the physical address it's at
22:22 Ashgood another thing, are you sure add-ins are run in the priviledged ring?
22:22 Fishbot Or alternatively, abuse the hardware security
22:22 Fishbot Yes
22:22 Ashgood okay
22:22 Fishbot Bye
22:22 Ashgood oh, okay, bye
22:22 Ashgood thanks for the info!
22:22 grphmstur Fishbot is leaving???
22:22 Ashgood aye
Discussing the Casio Prizm | Notable Community Projects: Khavi by Fishbot, Obliterate by KermMartian, Walnut by z80man
Topic set by Fishbot!Mibbit@97-117-133-242.phnx.qwest.net on Thu Jun 16 2011 21:39:38 GMT-0400 (Eastern Daylight Time)
22:07 nikky herf derf
22:08 KermM HERF DERF
22:09 KermM nikky, I think your presence in this channel means you need to start posting Prizm articles on ticalc.org
22:09 nikky Okay
22:09 nikky I'll start posting anti-prizm articles at once.
22:09 Ashgood coolstory
22:09 grphmstur hey, question
22:10 nikky Decrying you all as traitors.
22:10 Ashgood yep?
22:10 grphmstur if the OS starts at 0x8000 0000, why does it make calls to 0xA000 addressees?
22:10 Ashgood that's some hardware specific stuff
22:10 Ashgood IIRC
22:10 Ashgood plus I think some vector table is there
22:10 grphmstur It jumps to it.
22:10 grphmstur the vector table is reasonable
22:11 grphmstur also. 1.03 is out
22:11 Ashgood I think the sycall vector is there
22:11 grphmstur what about A000 069E?
22:11 grphmstur or 63C?
22:11 Ashgood no idea
22:11 Ashgood where does it call to it?
22:12 Ashgood It's likely just part of the vector table as well
22:12 grphmstur beginning of the OS it seems
22:12 Ashgood hmm
22:13 Ashgood maybe some lower level routines in the vector table?
22:13 grphmstur well, it's strange
22:13 Ashgood honestly I can't remember
22:13 grphmstur why do we assume that the OS runs at 0x8000 again?
22:14 Ashgood one thing, I mistaked
22:14 Ashgood the vector table is at "0x80020070"
22:14 Fishbot Is this prizm talk?
22:14 grphmstur okay, do we have a list of those
22:14 grphmstur yes, Fishbot
22:14 Fishbot Hi
22:14 Fishbot Okay, the A000**** addresses are ROM and OS code if I recall
22:15 Ashgood here's some of the syscalls on the vector table: http://prizmwiki.omnimaga.org/wiki/Syscalls
22:15 Fishbot The vector table is *NOT* at 80020070
22:15 Ashgood where is it?
22:15 *** TC01 quit (Quit: ChatZilla 0.9.86.1-rdmsoft [XULRunner 1.9.0.17/2009122204])
22:15 Ashgood ah, I see
22:15 Fishbot The syscalls are at approximately ~80050070
22:15 KermM Warning #1: Fishbot: Illegal use of colors
22:15 grphmstur lol
22:15 Ashgood
22:15 KermM
22:15 Ashgood shut up fake KermM
22:15 Fishbot The vector table is at around 80020100
22:16 Ashgood ah
22:16 Fishbot I don't know why my IRC client is doing that
22:16 Ashgood He's at it again!
22:16 Fishbot Test
22:16 Fishbot Okay
22:17 Fishbot The only thing that's at 80020070 is the hash function that's used to look up the syscall in the vector table
22:17 Ashgood So fishbot, I found out that copying code to the heap and executing it there doesn't work
22:17 Fishbot Hm?
22:17 Fishbot What address?
22:17 Ashgood allocated
22:18 Ashgood dynamically
22:18 Ashgood (malloc)
22:18 Fishbot Okay
22:18 Ashgood z80man's idea, actually
22:18 Ashgood instant crash-a-saurus-rex!
22:18 Fishbot That means it's from one of the other Vmem areas
22:18 Ashgood ah
22:18 Fishbot Code normally executes from P2, which has execution privileges.
22:18 grphmstur r15 has something to do with the stack, right Fishbot?
22:18 Fishbot It might be in P4
22:18 Fishbot Yes
22:18 *** Goplat quit (Read error: Operation timed out)
22:19 Fishbot r15 is SP
22:19 Ashgood apparently changing the FRQCR can only be changed by code in non-virtual mem
22:19 Fishbot We knew that
22:19 Ashgood indeed
22:19 Fishbot Well, only in code that can access non-virtual mem
22:19 grphmstur then how are you going to manage that?
22:20 Fishbot I have to figure out how to write to flash first
22:20 Fishbot Or at least where the OS writes files in flash
22:20 Ashgood then maybe strap it to an existing syscall?
22:20 Ashgood that is never used?
22:20 Ashgood (probably a bad idea, but just throwing out ideas to start)
22:20 Fishbot Well, to open flash, you need non-vmem code
22:21 *** Goplat joined #prizm
22:21 Fishbot All the syscalls are in flash...
22:21 Fishbot So it would have to write a file, find that file in physical memory, have the OS map it in, then pass it the physical address it's at
22:22 Ashgood another thing, are you sure add-ins are run in the priviledged ring?
22:22 Fishbot Or alternatively, abuse the hardware security
22:22 Fishbot Yes
22:22 Ashgood okay
22:22 Fishbot Bye
22:22 Ashgood oh, okay, bye
22:22 Ashgood thanks for the info!
22:22 grphmstur Fishbot is leaving???
22:22 Ashgood aye
Well, I was slaving all today trying to get some overclocking code working. I'll just say it up front; while the RTC addresses match up to the ones in the SH7720, the WDT and CPG addresses can't; they simply have no effect. I have no 7721.h file, I have basically all other ones; without that, I can't be sure what this is exactly. 7720 is out of the question; 7727 is as well. I doubt simon's argument that it is a 7730; the RTC unit on the 7730 is completely different from what AHelper found. I really can only guess it's a modded 7721 at this point; if someone could scour the internetz and find the addresses for the st_cpg and st_wdt (the WDT and CPG structs) for the 7721, then I can test my theory.
What would be even more helpful would be a disassembly of the Prizm OS. I've heard much talk about the process of it so far, but no one has given us results. An OS disassembly would be super helpful right now, anyone got at least a partial one I could look through?
EDIT: as for some useful information, I really suggest you all read this: http://documentation.renesas.com/doc/products/mpumcu/doc/superh/r01uh0083ej_sh7720_hm.pdf starting at page 463 or so. It talks about the FRQCR register, the two watchdog timer registers, their quirks (you need to access the WDT ones as shorts, prefixing the value with 0x5a), and the procedure for overclocking. Here are the structs from 7720.h:
Code:
Here's the code to overclock using them.
Code:
I'm not sharing any addresses, since they're incorrect anyways. I can't even get the watchdog to reset, which means they couldn't match up. To restart the WDT, all you have to do is reset the TME bit, the WTCNT value to 0 which essentially fakes a system reset (but doesn't reset the FRQCR), and change the frequency of the WDT intervals as needed (I just put a large value there to be sure). Then, you can change the multiplication bits on the FRQCR. For changing the division factors on the FRQCR, you can just directly set them. Again, remember to access registers correctly.
What would be even more helpful would be a disassembly of the Prizm OS. I've heard much talk about the process of it so far, but no one has given us results. An OS disassembly would be super helpful right now, anyone got at least a partial one I could look through?
EDIT: as for some useful information, I really suggest you all read this: http://documentation.renesas.com/doc/products/mpumcu/doc/superh/r01uh0083ej_sh7720_hm.pdf starting at page 463 or so. It talks about the FRQCR register, the two watchdog timer registers, their quirks (you need to access the WDT ones as shorts, prefixing the value with 0x5a), and the procedure for overclocking. Here are the structs from 7720.h:
Code:
struct st_cpg { /* struct CPG */
union { /* FRQCR */
unsigned short WORD; /* Word Access */
struct { /* Bit Access */
unsigned short STC2:1; /* STC2 */
unsigned short IFC2:1; /* IFC2 */
unsigned short PFC2:1; /* PFC2 */
unsigned short STC :2; /* STC */
unsigned short IFC :2; /* IFC */
unsigned short _PFC:2; /* PFC */
} BIT; /* */
} FRQCR; /* */
char wk[2]; /* */
union { /* WTCNT */
unsigned char READ; /* Read Access*/
unsigned short WRITE; /* Write Access*/
} WTCNT; /* */
union { /* WTCSR */
union { /* Read Access*/
unsigned char BYTE; /* Byte Access*/
struct { /* Bit Access*/
unsigned char TME :1; /* TME */
unsigned char WTIT:1; /* WT/IT */
unsigned char RSTS:1; /* RSTS */
unsigned char WOVF:1; /* WOVF */
unsigned char IOVF:1; /* IOVF */
unsigned char CKS :3; /* CKS */
} BIT; /* */
} READ; /* */
unsigned short WRITE; /* Write Access*/
} WTCSR; /* */
}; /* */
struct st_wdt { /* struct WDT */
union { /* WTCNT */
unsigned char READ; /* Read Access*/
unsigned short WRITE; /* Write Access*/
} WTCNT; /* */
union { /* WTCSR */
union { /* Read Access*/
unsigned char BYTE; /* Byte Access*/
struct { /* Bit Access*/
unsigned char TME :1; /* TME */
unsigned char WTIT:1; /* WT/IT */
unsigned char RSTS:1; /* RSTS */
unsigned char WOVF:1; /* WOVF */
unsigned char IOVF:1; /* IOVF */
unsigned char CKS :3; /* CKS */
} BIT; /* */
} READ; /* */
unsigned short WRITE; /* Write Access*/
} WTCSR; /* */
}; Here's the code to overclock using them.
Code:
CPG->WTCSR.WRITE = 0x5a03;
CPG->WTCNT.WRITE = 0x5a00;
CPG->FRQCR.WORD = 0x1303; // I've tried out a lot of different values, none of them have any effect. Reading those pages in the manual should inform you of the different codes you can use for different PLL multiplications.I'm not sharing any addresses, since they're incorrect anyways. I can't even get the watchdog to reset, which means they couldn't match up. To restart the WDT, all you have to do is reset the TME bit, the WTCNT value to 0 which essentially fakes a system reset (but doesn't reset the FRQCR), and change the frequency of the WDT intervals as needed (I just put a large value there to be sure). Then, you can change the multiplication bits on the FRQCR. For changing the division factors on the FRQCR, you can just directly set them. Again, remember to access registers correctly.
As an update, I've got some test code for the SH 7730/31's CPG and WDT units almost ready for deployment, which I'm hoping will work. The processor base seems to be 7720/21 based on the findings by AHelper, but we have no idea what units are changed, and with what. In addition, Kerm has some information to share about the serial port -- apparently the SIOF unit has been switched out as well, and if it is of a 7730, we're screwed with calcnet/etc. Hopefully this post will push him to explain his findings more 
Register to Join the Conversation
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
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