I can look to see if that is possibly an issue on mine. It seems like it could be rather likely. WIll check when I get some time this week!
Wire, solder, and soldering wick ordered, Prizm and BBB in hand. This may be fun. Stay tuned for updates on this as something will happen.
Fingers crossed!
Whoa, at the rate this has been going, a Prizm may finally have been unbricked by 2025! Very Happy

On a more serious note, it's great you haven't forgotten about this, despite probably having many more interesting things to do than reviving a Prizm. The Prizm seems to have fallen to abandonland, that part of collective memory nobody ever goes to, because it's too crowded.
But I still think it is the device with the best hackability-performance ratio, and between exam modes becoming mandatory in certain countries and Casio (and other calculator makers) actively removing support for third-party applications (vs. merely discouraging it passively), it's a remarkably "open" calc with a color screen.
Prizm is still the top choice for A-Level Math and Further Math in England (based on my school experience at least) - shame not enough developers code for this machine with relatively good processor speed, screen and storage capacities. It could be due to the issue of Windows support for SDK setup being incomplete, but probably also due to the fact that Casio is less popular in America.
I shall check my Prizm and see if that chip is scorched too. If it is and people can find a fix people could be happy with the Prizm again!
Just unpacked wire and such, I'll have to get my notes on what vias are what and what the plan was.

Q1: Is there a way to determine if a line is being held high or if it is pulled up?

Q2: Since the BBB is going to do I/O directly with a powered prizm, I am correct in assuming that a common ground is needed for this? I'm thinking power the prizm from, and power the prizm through USB from the BBB.
AHelper wrote:
Q1: Is there a way to determine if a line is being held high or if it is pulled up?
Off the top of my head, power off the device and measure again? Of course, if the pullups are toggleable (like the ones in the Atmega328), that's not going to help you much.

Quote:
Q2: Since the BBB is going to do I/O directly with a powered prizm, I am correct in assuming that a common ground is needed for this? I'm thinking power the prizm from, and power the prizm through USB from the BBB.
Yes, you're correct. But make sure that the Prizm uses 3.3V I/O, like the BBB! If it uses 5V I/O, you stand a serious chance of frying your BBB.
KermMartian wrote:
AHelper wrote:
Q1: Is there a way to determine if a line is being held high or if it is pulled up?
Off the top of my head, power off the device and measure again? Of course, if the pullups are toggleable (like the ones in the Atmega328), that's not going to help you much.

Quote:
Q2: Since the BBB is going to do I/O directly with a powered prizm, I am correct in assuming that a common ground is needed for this? I'm thinking power the prizm from, and power the prizm through USB from the BBB.
Yes, you're correct. But make sure that the Prizm uses 3.3V I/O, like the BBB! If it uses 5V I/O, you stand a serious chance of frying your BBB.


I've seen a trend in similar SuperH MCUs that have those lines pulled up, non-togglable.

And the lines I have measured are 3.3V logic. There are lots of different voltages on the board that I have mapped out, but I should be fine.

Once I manage to solder the wires, I'll probably solder those to thicker wires that I can use with the BBB. Probably on the weekend for any of this.
AHelper wrote:
KermMartian wrote:
AHelper wrote:
Q1: Is there a way to determine if a line is being held high or if it is pulled up?
Off the top of my head, power off the device and measure again? Of course, if the pullups are toggleable (like the ones in the Atmega328), that's not going to help you much.
I've seen a trend in similar SuperH MCUs that have those lines pulled up, non-togglable.
In that case, using a multimeter to measure the resistance between ground and each I/O line should give you some idea of whether they're being pulled up normally. Of course, once you power it on, you wouldn't have much insight into whether they were being held high and pulled up, or just pulled up.
Since the weekend is almost here, and assuming you are going to work on this, could you elucidate me on what is, more or less, the plan of action (i.e. what are you going to do with the BBB once you get that big-mess-o-wires set up)? I assume you're going to try reading more of the flash memory and maybe even flip some bits. Last time you hooked up a scope to your Prizm you managed to read the first few bytes and they did not match with the correct ones. I think the idea for fixing it back then, would be to write the bootloader and then use it to load a OS over USB.

Good luck!

On a more offtopic note, and for people wondering why I hardly post here anymore, I was planning to spend some time this summer doing something with a Prizm plus a ESP8266, and putting more documentation on the Prizm wiki, perhaps even do some OS reverse-engineering, but holidays are almost over and I didn't even start. As expected, my interest on this calculator has pretty much died off. Anyway I doubt there would be many people interested in replicating my ESP8266 setup (plus, it'd annoy Casio et al, not that it bothers me but it may bother others), and hardly any people still develop for the Prizm, so I guess these activities would be a waste of time.
I instead spent the time writing Windows software in the rediscovered joy that is C#, the beginnings of an Android app (ugh I hate Java and I only even started) and a server in Golang for the server side of a cloud service I'm developing. It has a slim chance of actually bringing in money, so I guess it is time well spent Smile
I'll be brief here. First is to check what was needed to stop the CPU clock, either using the reset line or the oscillator. Then, tap into the address and data lines, flash control pins, and reset/oscillator. Those lines will get soldered to cables to go to the BBB. Once that is done, power both and hope no smoke comes out.

Then, ensure bbb can read the pins and write OK. Then, write a flash driver (CFI? Common flash interface?) to request flash manufacturer and model info. Once that is OK, dump the entire chip and write the bootloader.

Just a PC is needed to resend the OS, if it is corrupt.

Piece of cake.
AHelper wrote:
using the reset line or the oscillator


I think we found out the CPU reset line was shared with the flash, so I'd say the oscillator is a better option as then you won't have to cut traces. Let's hope the CPU doesn't mind being powered up without oscillator.

CFI is definitely appropriate for talking to the flash chip - at least, after all these years I'm yet to see any indication on the contrary.

The Macronix part that replaced the Spansion one in the latest hardware revisions is similar enough to the previous one, that operating systems made at a time when only the Spansion part was made, can run without problem on calcs with the Macronix chip.
So, I took a picture of the chip on my fx-CG10 and posted it here
https://www.cemetech.net/forum/viewtopic.php?p=240409#240409
Could it be what killed my casio?
Has there been any progress on restoring Kerm's unfortunate Prizm, post-Maker Faire?
elfprince13 wrote:
Has there been any progress on restoring Kerm's unfortunate Prizm, post-Maker Faire?
has something happened to Kerm's prizm there?
His prizm on the first day of the faire refused to boot? Via battery or other means. None of us had time to open it up and investigate during the faire though.
AHelper, have you managed to replace that component please?

TeamFX, is it true that 2015 onwards prizm hardware has an upgraded component there already please?
I just had a look at the new fx-CG20 AU from late 2015:
The PCB version 001V04 is identical to those models using a Macronix ROM.
The only difference is that they are now using a Spansion (now Cypress) S99-50272 ROM.
These S99 numbers appear to be obfuscated product codes and therefore no datasheet could be found.

I'm a bit disappointed they did not change that component on the PCB which often breaks whereas most other models now seem to get an improved PCB design. I don't believe it, but maybe they changed the PCB in those OS 2.02 models which also have a newer boot code. If there are still no hardware changes, then Casio may be planning to replace the Prizm in early 2017/2018.

There are no signs of an upcoming fx-CG20+ E and the fx-CG20 will most likely be discontinued in France soon. The introduction of the fx-CG20 AU in Australia five years after the fx-CG10 is also very strange. However, a possible more powerful Prizm may have no chance of being approved in Australia.

OS 2.02 and the new boot code (This is the only change!) send a different response value during the initialization phase of the OS update procedure. This change is a bit confusing, it may either stop old Casio updaters from working or it could simplify the update mechanism in the future. It could be used to detect specific device types very early on without the need for any additional checks.
Thanks for the update, could you explain how to detect that new component in case I disassemble my new OS 2.02 hardware which came with the new bootloader...
  
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 3 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

 

Advertisement