Indeed, I ran through the 7721 manual, which indicates that SIOF is handled by Port S. Port S has two registers, PSCR (control register) and PSDR (data register). The RxD and TxD lines are pins 1 and 2 of Port S; the following code sets both lines of the port to "output" and repeatedly toggles them high and low:


Code:

Unfortunately, while this doesn't crash, a multimeter attached to the Prizm's serial port shows nothing in particular happening. The ring stays at 0.000V relative to the base, while the tip stays at a solid 2.647V relative to the base.

I therefore took a look at the 7730 manual. Unlike the 7721, where both pins 1 and 2 of Port S are bidirectional and can be set output, input with pullup, or input without pullup, the 7730 has pin 2 bidirectional but pin 1 as unidirectional input. For my future reference to modify my testing program to see if the SIOF module is a 7730 module:


Code:


Edit: Interesting, didn't get any activity on the serial port from that, either.

Interesting results of my findings confirm the CPG unit in the Prizm is *not* of a SH7730 or a SH7731. The values of the supposed FRQCR are almost entirely invalid when checked, and have no effect when changed. A translation of simon's advice from a page back (seems to) say that the address of the FRQCR is at [8000077C], which points to the value "AAAA0000". Trying that address out too, had no effect. As for the value of the data at 0xAAAA0000, it's 0x00000000.

I really need an OS disassembly right now. Does anyone... anyone at all.. have one?

Wait, working from the RTC, what could the base model be? Do the addresses match anything there?

Well, we know for sure the RTC unit is of a SH7720. Thing is, nothing else seems to be. Perhaps we're going around in circles for nothing, and the processor in the Prizm is just like that in the 9860, a SH7705? It seems rather unlikely, but everything else we're getting into here is making that point more and more possible by the day. If it is, then that's slightly frustrating and yet bodaciously excellent at the same time. Perhaps try looking at the serial hardware on the SH7705?

Sounds good, grabbing the PDF now and investigating. I'll edit this post once I read up on what the 7705 supports in the way of bidirectional serial. Edit: Actually, it looks like the 7705 only does FIFO-based serial (SCIF) on port SC. It's even worse than the 7730: both RxD and TxD are stuck unidirectional.

Well, for another short update, I don't seem to be getting anything right for the SH7705 design either. This is starting to really annoy me. There are a few models between the 7705 and the 7720 subfamily, being the 7706, 7707, 7709, 7709A, 7709S, and 7710. There's always the possibility that the CPG/WDT unit could be from one of those.

And, as a note to anyone who sees this who has an OS disassembly by now, We really need it at this point, if no one can provide one relatively soon I'll be forced to find some way to disassemble it and reorganize it myself (I'd prefer not to go through that if the work has already been done). If you have a copy, even of just a few beginning parts of ROM, it'd be crucially helpful if you could give it to us. That is all. (Sorry for the bold-spam, but it needs to catch eye attention of those who have the disassemblies.)

From an entirely non-technical point of view (i.e. without looking at any code/OS disassembling/hardware info), I'd say using the processor from the fx9860 is a valid and likely choice from Casio: porting the OS would be easier, old code would be more likely to work without many modifications (mainly just the addition of colors and adaptation to a huge screen resolution) and the people involved in the process of developing the calc and its software were already familiarized with that processor.

That's a very true perspective, and I've actually searched and found a 9860 add-in that overclocked to different speeds at the press of a button. It used something called the EPSILON Hardware Library, made by someone called "kucalc", which I scoured the internet for hours looking for a download for, to no avail. If someone has a copy of it though... I'd be estatic if you could permit me a look.

EDIT: found the author's email -- sent him one requesting the source of EPSILON:

Have you looked at Revolution-FX? It seems to be another library developed by kucalc, and it has its source public (Creative Commons) up to the version 0.3: http://sourceforge.net/projects/revolution-fx/
There seems to be a 1.0 version but it is distributed as a Windows setup file, and I couldn't find its source.

I had a look at the source code for 0.3 and couldn't find anything about setting the CPU clock, and I don't know if this version of the library is pre-EPSILON or post-EPSILON, or even if it has anything to do with EPSILON. CPUSPEED seems to have been released in March 2007 and the v0.3 of Revolution-FX in August 2007.

Let's hope kucalc replies to your email and shares with us the source, or at least points us in the right direction by sharing some info.

Thanks a ton for that link -- it actually did have CPU overclocking code in it. Thing is, it didn't work on the Prizm at all, for reasons AngelFish/Fishbot/Qwerty/whatever he likes to go by these days () told me:

Add-ins are definitely ran in privileged mode, which is one step closer to being able to do things like overclocking. The problem is that add-ins are also ran in VMEM, or Virtual Memory. This means (for those of you who don't know) that all memory addresses may not correspond to true memory addresses, and that there are certain addresses we cannot access without being in PMEM (privileged memory, or physical memory). The CPU masks off these addresses in VMEM, so we'll have to break into PMEM to change them (the CPG, WDT, possibly the SIOF and others are all masked off, but apparently we were able to work with the RTC because unlike the others it is *not* masked off). Fishbot's theoretical solution to this is:

1. Unlock Flash. Without this, nothing can happen.
2. Create a new syscall entry, which we place whatever code we want to execute into.
3. call the syscall, which will be turned into PMEM and privileged mode.

There are a few possibilities as to how this can happen. Fishbot thinks there's a chance that flash is locked down with a lock/unlock key, which is stored in the OS. Of course there's a good chance it's wide open and we just need to learn the procedure to do this. Another possibility is actually modifying an OS version with this new syscall, and loading it instead of the official one.

You know what that means? Not only is an OS disassembly very helpful to our future discoveries and hacking, it's 100% critical. If someone sees graphmastur here sometime today or tomorrow, please point him to this thread; I believe he has some headway with disassembly.

And, as a note for those curious, the overclocking code on the 9860 is exactly the same as the vanilla SH7705 code I tried earlier, to no avail. I say there's a half chance it's a 7705 module, but many things have actually changed between models; I noticed the RTC unit in a 9860 is actually of a 7705 as well, whereas in the Prizm it is definitely one of a 7720.

The RTC is probably not masked off because it has space for use in lots of areas in the OS (e.g. ECon2?), but also on official add-ins Casio might develop one day (I can't stop saying a stopwatch is something that makes all sense to have on a calc you can take to chemistry/lab classes).

Isn't it possible that a syscall for changing to PMEM mode exists already? How does the OS update function work? It is something accessible through the OS (i.e. not through a bootloader), and I think that what it does is updating the ROM with the data it receives through USB from the update software which is running on the PC.

That's another good point, and a good outset point for looking through the OS. I'm not going to throw out the idea there's a syscall for getting into PMEM, but it seems very unlikely. It's probably something hidden into the linking/memory psuedo-addins.

I'd be willing to bet that there's already a syscall to jump to real addressing mode from virtual addressing mode, if you're already in Ring 0/1 (or whatever Renesas calls their privileged mode). I agree that there's a chance the address is masked off, and I also agree that an OS disassembly would be invaluable in helping us further examine this issue.

Well, I assume that everyone knows that Casio's 1.02 OS updater stored the OS inside a DLL. The OS could then be extracted... ( http://prizmwiki.omnimaga.org/wiki/Tools , look under "prizmosdecomp") I just don't know if anyone disassembled the extracted binary.

Another great thing to do is to perform USB sniffing while updating the OS, and again, I don't know if anyone did this already (too lazy to search right now)

Yes, graphmastur sniffed the OS transfer, and BrandonW decoded the screenshot transfer protocol. We're still waiting on Graph to publish his OS-sniffing results, though.

Yes, yes, I knows... Well, I need to get windows set back up so I can decode 1.04 update. If anyone has "usb simple logger" link, and can use it while updating their prizm, I'd be much obliged. Just make sure the logger recognizes your prizm is plugged in, after you switch it to the OS receive mode. If no data is being sent, abort and try again.

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:

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:


And then to go to 1.8MHz, do this:


Code:


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?

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


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. I'm going to focus on Port S, since that's used for SIOF on many of the other models.