What about shorting out the CPU clock input? That would surely stop the CPU, would that do terrible things to the flash?
That in theory would help isolate the peripherals. You would still have to play with the ram and hope that that does not interfere with your interface, as they both share the same address lines. If we can find the Chip Enable (CS) line for the ram chip that would help immensely as we can then in theory talk right to the flash with out interference.

Since we currently do not have that tho the previous idea to just highjack the CS line and drop a new flash module on there is still "The Easiest" approach available.
I'm trying to aim for the least-destructive path, so if I can find a CS pin for the ram and disable it and talk directly to the flash with minimal soldering/changes to components, I'll take it.
Sadly isolating the hardware on this device is not going to be anything but destructive. In my opinion the best way to handle it is to tap the rst line for the flash and cut it and put the calc into "Reset". Then all you have to do is hold the flash's reset line inactive and you should be isolated. Sadly you have to cut a trace but your going to have to cut it anyway because of how the reset circuit works. Now if you don't intend on using the reset line and some how manage to Stop the cpu from ticking. You might have a better method of attack there. But above is the IMO current most obvious way to handle it.
Are we even sure the CPU keeps ticking? Has anyone looked at the address and data lines in the current state, to see what addresses are being read and with what values?
I plan to, I haven't had a change to put a scope on my prizm. I should be able to next week
I Do not own a scope so I have no idea. Based on some conjecture of how the Reset system seems to be behaving tho I would want to assume that it is toggling the reset line for the CPU as well as the other peripherals.
I'll be getting a scope for rental over a 3 day weekend in about 2 hours, so get ready for some experimentation to occur.
I have a scope hooked up to my prizm now. Will be dumping the output of pins when the calc was powered by USB and let to stand for a bit.

Testing scope, RTC measured at 32.765kHz
Flash chip - 3.3V
13|WE# H
16|WP#/ACC L
17|RY/BY# H
32|CE# Normally high, active low | L
34|OE# Pattern (Will need to look at again)

A0 ~ 3MHz (0101010111111[loop])
A1 ~ 3MHz (0011001111111[loop])
A2 ~ 3MHz (0000111111111[loop])





00 00 D4 1F 44 0E D1 1F E1 00 D4 1F E7 10 D6 1F

     .data:0x00000000   0000   .word 0x0000   
     .data:0x00000002   f82b   .word 0xf82b   
     .data:0x00000004   7022   add   #34,r0   
     .data:0x00000006   f88b   .word 0xf88b   
     .data:0x00000008   0087   mul.l   r8,r0   
     .data:0x0000000a   f82b   .word 0xf82b   
     .data:0x0000000c   08e7   mul.l   r14,r8   
     .data:0x0000000e   f86b   .word 0xf86b

LCD BUS DUMP (This is ever other data line. Address lines cannot be mapped)


I have not found where these data lines enter the CPU.  There are no testpads for these lines.

Flash seems to have been overwritten. How large is the cache line for the CPU?

The back has a nice breakout of the RTC and some other clock. RTC is 12.765kHz and unknown clock is ~37.5MHz.

The following voltage areas were located: 3.3V 3V 1.8V 1.2V 2V 5V

LCD is 3.3V and 5V. CPU is 1.2V (core), 3.3V, 1.8V. IO is 2V.

I have a link of my scope captures and board images here.
Dear AHelper,

Have you opened a working calculator? Could you kindly test some of the pins from this post http://www.cemetech.net/forum/viewtopic.php?t=11358 - just to verify it is correct what I assumed from the other write ups please?

Many thanks in advance
So if I understood correctly the IRC log, the flash contents changed as you probed it?

That byte sequence doesn't appear anywhere in the bootcode or OS 01.04 or 02.00. It could of course have come from one of the data sections. It doesn't appear to be code, judging by the disassembly, it doesn't make much sense. It could be just random data... I wonder if the flash chip is faulty?

EDIT: this post no longer makes sense after AHelper edited his (byte sequence corrected).
Amazonka, I only have a broken prizm. I can, however, map the keyboard ribbon cable as well as the test points on the keyboard PCB.

gbl08ma, the first reads were wrong, I probed the vias, however none of the vias conduct. Going back, I probed the exposed resistor arrays and got the correct reading.

I'll grab my rom and compare the first 16 bytes to see if it was truely overwritten (It is the first 16 bytes as per the address lines). I'll then start asserting higher address pins when it boots to dump further into the flash chip and see the extent of the damages.

Also, there is a delay from when the calc gets power to when the internal oscillators activate, about 0.3-0.4 seconds. Just estimating that, will grab an accurate reading soon. Also, touching the RTC and destabilizing it will drop the unknown clock signal to about 26.25MHz. The system gets very unstable. The flash accesses get 1000x slower or completely stopped. Just a side-effect of probing the clock freq. when I physically touch the probe's metal.
If these are indeed the first 16 bytes, then they don't match with any of the few known bootloaders.

If disabling the oscillators is enough to stop the CPU, that may be enough to leave the flash under our exclusive control. Unless the flash also needs the same oscillator, or a clock based on it, for something?

The 0.3-0.4 seconds delay is in line with the time it takes for the screen to turn on after the reboot button is pressed or batteries are inserted.

EDIT: this post no longer makes sense after AHelper edited his.
The flash chip does not need the clock at all to function. At least for external access. That being said we still need a way to isolate the ram out of the equation.
To drop the current ideas here:
  • Find the Vcc line to the flash chip, cut it, and supply our own power and interface with the chip
  • Assert RESET, keep CPU in reset, cut flash CE, and interface with the chip.
  • Magically find JTAG and hope that I can control the flash from it (I hope I understand the EXTEST and PRELOAD commands right for doing that).
Thanks, AHelper. I am glad to see there is some progress with this - fingers crossed you and geekboy unbrick your Prizms and find a way for others to do the same.

I am keenly looking forward for mapping of the keyboard ribbon - maybe you could update the other post http://www.cemetech.net/forum/viewtopic.php?t=11358 with this to not go off topic here and maybe in the future this combined with some extra hardware could allow a bluetooth keyboard or gaming controller.
With regards to finding JTAG: some time ago, I compared the PCBs of various Casio calculators using the good quality pictures in TeamFX's folder. The idea was to find some pattern of exposed test pads that was common to various boards, and especially the ones with the same CPU as the Prizm (the color fx-CP). I'm obviously no expert, and the photos only have one side of the boards, but the only patterns I could find are pads for soldering crystals and the like, which are not needed in some models.

Now that I look at the picture AHelper took of the back of the PCB, there are lots more test pads to choose from, so everything is possible. But I wouldn't be too surprised if the pins aren't exposed, after all, it seems Casio doesn't particularly care about making it easy to repair damaged calculators, judging by their policy of not protecting the bootloader against writes.

That said, the best way to find the JTAG would be with a probe... ideally we would want to identify all the exposed vias. I see that most of them are identified already, so there's not much to choose from. Perhaps the relevant contacts really exist, but are inside the epoxy blob, as Casio did with the "model selector" on the cheaper scientific calcs...
I packed everything up as my time left with a scope is coming to an end, however I did grab quite a few pictures of my setup as well as the top and bottom of the main PCB and keyboard PCB as well as the back of the keys. Not sure on their use, but I took them regardless.

I'll be putting this on hold as I wasn't able to find a group of pins that met the requirements of being JTAG pins (3 pulled up, 1 pulled down, 1 floating) that were grouped all together. I'll revisit this in a long while to attempt PCB modifications to communicate with the flash.
That mystery about dead Prizms appears to be solved. New hardware revisions should arrive soon and will include an improved circuit design.

The component that was causing these defects is located near the RESTART button:

Yet, I still believe you can extend the lifetime of your calculator by not doing any overclocking - not even once.

Interestingly, only the Prizm seems to be affected. There have been no reports of other calculators breaking. Most of them operate at 29 MHz, the Prizm at 58 MHz and the fx-CP400 at 116 MHz. All of them have the problematic component included on the PCB.
That's an interesting find, TeamFX. Has anyone attempted to replace this component themselves and restore a Prizm?
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 4
» 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