16 replies to this topic

[Sal]

I saw some pictures on the Internet of the Printed Circuit Board of a fx-5800P. It showed jumpers P0-P7 P302 P303 and unused 48 Pin IC U201 pads. Only jumper P0 was solder bridged. Does anyone know what chip miight be added at the IC U201 location?

I am wondering if it could have additional Flash Memory or SRAM. Does anyone know? Maybe some of the other solder jumpers might be for this??

Sal

[Sal]

Anybody ever try any hardware mods on this model?

[Sal]

I will look at the PC Board pictures and see how many of the connections that I can sort, using the SRAM and Flash Memory chip pinouts from their datasheets. Data and address lines are probably shared. Chip selects, Read-Write lines are probably separate. Some of the solder bridge jumpers probably tell the CPU about SRAM and Flash chip sizes, how to configure the memory map, and configure system features.

Lots and lots of unknowns.

Edited by Sal, 11 January 2017 - 07:12 PM.

[Sal]

If I have read the chip markings correctly, it looks (I think) like the calculator PCB in the photos have:

Flash - 1 Megabyte (1M x 8)

SRAM - 32 Kilobytes (32K x 8)

Amount of RAM-ROM-Flash on the CPU chip is unknown.
Type and architecture is unknown.
Capability of system to support additional RAM is unknown
Capability of the system to support additional Flash is unknown.

Any information will be very welcome.

[TeamFX]

Photos taken from:
http://manib.bplaced...og/?page_id=421
http://c.tieba.baidu...n=30&pinf=1_2_0

Edited by TeamFX, 12 January 2017 - 12:12 PM.

[Sal]

Thank you, TeamFX! The empty pads for U201 is where (I think) a second Flash memory chip might go. It looks like there is also a place for the necessary surface mount ceramic power de-spiking capacitor, C201.

I will try to get these parts as soon as I can. It will probably be a few weeks as I have a lot of medical bills. The good news is that it looks like the Flash chip is a very inexpensive commodity item.

Thanks again for sharing the wonderfully detailed photos.

I can start out by tracing lines on the photos from the Flash pads and the jumper pads. That will get things moving. You've made my day. :-)

Edited by Sal, 11 January 2017 - 12:52 AM.

[Sal]

Okay TeamFX, here we go! At least the first step of the journey.

The solder bridge jumpers P0-->P7 all have their right hand side tied together. I'm assuming that this common line goes to an input line of the CPU under the grand house of epoxy, the house of mystery. :-)

Each one of the P0--P7 jumpers have their left side going to an individual memory Data line. The Flash chip can be used in either 8 bit or 16 bit I-O mode, and the SRAM (Static RAM) uses 8 bit I-O. Because the solder bridge jumpers P0 through P7 are each connected to a data line, ONLY ONE SOLDER BRIDGE JUMPER CAN BE JUMPED! Otherwise data lines would be shorted together. This means that the system designers allowed for eight different jumper settings with these jumpers. Here is how they appear to be connected from looking at the photos (Thanks again!).

IC U201 is a blank unpopulated space. All this is based on the assumption that the designers left room for a second Flash chip the same as the first (same pinout, hopefully). If installed, I am guessing that the spot labeled C201 was the space for its bypass capacitor, which it would need for reliable operation.

P0 goes to U201 pin 29 which is data line Q0 - Byte val 1
P1 goes to U201 pin 31 which is data line Q1 - Byte val 2
P2 goes to U201 pin 33 which is data line Q2 - Byte val 4
P3 goes to U201 pin 35 which is data line Q3 - Byte val 8
P4 goes to U201 pin 38 which is data line Q4 - Byte val 16
P5 goes to U201 pin 40 which is data line Q5 - Byte val 32
P6 goes to U201 pin 42 which is data line Q6 - Byte val 64
P7 goes to U201 pin 44 which is data line Q7 - Byte val 128

P0 is the factory jumpered one.

It is possible that damage could occur from jumpering two or more of these jumpers at the same time because data lines would be shorted together. I assume that the warranty would be void because it would be easy to see solder coating left on normally unused jumpers. This is all only for educational purposes for curious engineering type minds.

Edited by Sal, 10 January 2017 - 05:30 PM.

[Sal]

A Chinese web site with diagnostic key sequences. I hope that this link works for you

http://c.tieba.baidu...n=30&pinf=1_2_0

[Sal]

Other things that I do not know:

There appears to be a third likely Service/Test related (?) solder bridge jumper: P301

Also there are other unpopulated and labeled component solder pads.

C304 has large pads, so may be for an electrolytic or Tantalum capacitor. It is in an area that appears to possibly be part of the power supply. (?)

There are also two pad sets labeled R305 and R306, probably for resistors of currently unknown purpose. (?)

I sure wish that there was a schematic...

[TeamFX]

A Chinese web site with diagnostic key sequences. I hope that this link works for you
http://c.tieba.baidu...n=30&pinf=1_2_0

Interesting, you can update the OS by receiving it from another calculator?
This would also imply that no calc<->PC communication is possible.






Maybe that contact P0 is for switching between flash chip #1 and #2?
If there is no calc<->PC connection, then the only way to "upload" a new OS is by installing a new flash chip.
Then synchronize this updated calculator OS with all other fx-5800P models you have.

Diagnostic mode can be entered by pressing [MODE] + 7 + AC/on and then pressing the left cursor key followed by 9.
It is also explained here: https://calcwiki.org/Fx-5800P
This website says that it is indeed possible to repair a broken OS via 3-pin cable.
 
You could either dump the ROM content with a device programmer, see: http://community.cas...us-rom-dumping/
Or by using two fx-5800P units and some 3-pin sniffer hardware. I don't think the OS data is encrypted while sending.
Yet, you cannot get the boot code data using this method as it is most likely not transmitted at all.

Edited by TeamFX, 12 January 2017 - 01:03 PM.

[Sal]

Hi TeamFX!

I read it the same way. Looks like we can interchange RAM and transfer an OS from calc to calc. I am guessing there is a permanent bootstrap loader on the CPU chip for upgrades and reloads.

I also am guessing that the factory has "smart cables" to enable connection to a PC for loading, and some proprietary PC software to communicate with the calc. They might cost as much as another calculator because they would probably contain a microcontroller chip. This makes a second calc as a "backup drive" a reasonable consumer solution. Cost might also explain a decision not to sell them to the public.

I'm still hoping that there may be some way to access the I/O port through the built in programming language.

Maybe there are some new statements or functions that could be accessed through keys not present in the stock keyboard matrix - if there are any open keyboard switch matrix posiions.

Can we even enter function names as text instead of through menus ?

Hoping for undocumented functions.

Edited by Sal, 12 January 2017 - 05:35 AM.

[TeamFX]

I am guessing there is a permanent bootstrap loader on the CPU chip for upgrades and reloads.

It's a cheap design, so I don't think the boot code resides inside the CPU. It was in the ClassPad 300, but that CPU is extremely large and this device uses NAND flash which cannot contain boot code data (as you need special program code to read it). A NOR flash (as seen in the fx-5800P), however, can be directly attached to the CPU and the CPU will execute any boot code on that. It is unwise to update the boot code during an OS update, so this part of the flash chip is not erased or programmed.
 

I also am guessing that the factory has "smart cables" to enable connection to a PC for loading, and some proprietary PC software to communicate with the calc.

Maybe they had some for early fx-5800P prototypes.
The problem is this: Why would they include such a strange and difficult calc-to-calc OS updater if they don't have to (e.g., use a PC instead)?

I suppose they used this for the final testing stage. They would collect some bugs, someone would install an updated flash chip and synchronize this calculator software with other development units. The second flash solder pad is also a clear indication to this. And there is no dedicated crystal oscillator on the PCB (as you have noted).
 

Hoping for undocumented functions.

You would need a ROM dump in order to analyze the OS and find hidden/undocumented stuff.

Edited by TeamFX, 12 January 2017 - 06:03 PM.

[Sal]

No doubt the least expensive and easiest way to manage field updates was to issue each service center a "golden" calc to clone from. This would also prevent the developer's "smart cable" (clocked similar to I2C and containing a microctroller protocol converter) and associated comm loader software for the cable from falling into the "wrong" [ie: our :-) ] hands. I'm guessing that an emergency bootstrap loader is built into the CPU chip and only supports the proprietary clocked I/O.

A big yes to the cost effective design, but I think it was a case of what they used to call "worse is better." Although the hidden unimplented capabilities didn't do anything exciting for the general public, I strongly suspect that this model was designed with two roles in mind. The second role may have never come into play as the explosion of super low cost bare bones tablets that can be loaded with a task-specific app exploded onto the market.

Here is my conjecture. A simple and teeny tiny bootstrap loader with barely enough ROM and RAM to make it able to load external flash is small and could easily fit into a typical CPU. Afterward early in normal bootup performs quick checksums on the external Flash and RAM, at least that's how I'd code it. The jumper that is bridged (not counting the diagnostic and service jumpers) tells the blob chip what it has to work with for Flash and SRAM. To keep the bootstrap small and simple, it probably only knows about the proprietary clocked protocol. After verifying a successful load, a non-volatile flag is set so that normal bootup skips the download and diagnostics and jumps to code in the first Flash chip unless it detects special service key presses.

(TeamFX, I used to work in R&D at a large company under NDAs. That's why I look at this with my particular views. Other companies have other ways, and you are absolutely correct about programming by chip removal. In this case it was common to have a short ribbon cable going to a box with a ZIF socket for either a PDIP version of the chip, or a small chip mounted on a board to fit the ZIF socket. Then the chip can be easily removed from the ZIF socket and plugged into a device programmer. It saved time soldering and desoldering and wear and tear on the PCB. So much for this old geezer's experience.)

And now, back to the story :-)

I propose that a second possibly never used role was designed into the hardware. It would have been like how some of the earlier calcs and pocket PCs had ROM modules to customize the device into a specialized device for things like banking, aerospace, surveying, civil - electrical - and electronic engineering. Specialized applications could make full use of the dot matrix display. The standard firmware mostly uses the dot matrix display as text rows.

Here is how it might have been planned:

1 PC Board space and connections are laid out on the board for a second 1 Megabyte Flash chip

2 A jumper setting sets a global flag in the CPU indicating the presence of the second Flash chip

3 An initialization routine in the base OS in the first flash chip, looks for a header signature in the first or last few bytes of the second Flash chip.

4 If the header is found, then the first Flash includes routines in the second which add on to the feature/function set of the device

5 An adhesive transparent keyboard overlay could fit around the 1 -> 9 keys to add gold shift key functions.

6 The menus would change due to the code in the second flash. How they change would be up to the developers

7 The one of eight jumper options could do many things.

8 Although no crystal or ceramic resonator is visible on the PCB, with today's TINY crystals, there could be one, or a factory automation laser trimmed RC network for a clock that *might* be stable for async comm under the CPU epoxy area. The CPU could have an D/A converter to fine tune the clock frequency.

9 So jumpers *might* be some set of selections like:

A - 1 Flash, proprietary I/O, 32K SRAM
B - 2 Flash 2nd used for feature extensions, proprietary I/O, 32K SRAM
C - 1 Flash, async I/O, 32K SRAM
D - 2 Flash 2nd used as user storage drive, async I/O, 32K SRAM
E - 1 Flash proprietary I/O, 8K SRAM
F - 2 Flash, 2nd used for feature extensions, proprietary I/O, 8K SRAM
G - 1 Flash, async I/O, 8K SRAM
H - 2 Flash 2nd used as user storage, async I/O, 8K SRAM

Also, when connected to a PC loaded with service software, it would be possible to run fixed clock cycle routines in the calc, measure the execution time, and store a system clock calibration value into a tiny flash on the CPU chip to enable async I/O clock stability for those cases where async I/O might be an option. This could be a tweak beyond a laser trimmed resistor.

Given the board layout, it could have been released as eight models.

Just some thoughts.

Sal

Edited by Sal, 13 January 2017 - 01:35 AM.

[Sal]

*IF* a similar set of eight jumper options existed, then *MAYBE* one of the options could be to use the existing RAM and Flash, but change the I/O to async. It might still use the clocked mode for cloning, but enable async through normally hidden and disabled from menu comm functions. *MAYBE" :-/ ??

As soon as I feel better, it will be soldering iron time to play with jumpers.

Probable: Likely wrong and none of the jumpers will do anything. I'll still keep hoping for a schematic. :-)

Edited by Sal, 13 January 2017 - 03:07 AM.

[Sal]

This is a very nice but kind of strange I/O system. I wonder if the CPU uses an on board ring oscillator...

I'll tell you, TeamFX, you have a LOT of very keen observations! I had actually sort of forgotten about the old days of "solder in - solder out" and dangling ribbon cables with sockets and stuff. You are dead on. I would also like to thank you for being someone I can bounce ideas around with. I used to be able to do that with my late brother. We each looked at things differently, and it let us piece together a better picture of how something worked. I've really enjoyed our brainstorming. Just wanted to say thanks. :-)

I've got some new (to me) sixteen bit microcontrollers that process at 70 MIPS and cost about the same as a Lthium button cell (Microchip dsPIC33EP256GP502 in a 28 pin narrow DIP). They have all kinds of I/O capabiliies including I2C, SPI, Serial, and a built in Analog to digital converter. Some other people have stated trying to understand the unusual clocked calc-to-calc interface. It would be handy to be able to build a device with a calc I/O jack interface that could act like a second calc for backup and restore. What do you think, TeamFX ?

Sure, I'd like the world:
- Serial I/O under program control
- More onboard Flash
- More RAM
- Access to new undocumented (and probably nonexistent) functions

What I think *might* ACTUALLY be possible:
- Finding out if the system can use two flash chips for a total of 2 Megabytes
- Learning the calc-to-calc comm protocol
- Using the calc-to-calc protocol with a microntroller to either back up and restore to and from some Flash attached to the microcontroller, or to use a microcontroller to provide an interface to a computer, to back up and restore calc <-> microcontroller <-> regular computer.

I currently only have one fx-5800P which will make the protocol work difficult, and a low end (25 MHz BW @ 100 MSPS) dual trace digital oscilloscope that looks bored...

It may be a couple of months before I can get a second '5800 - beginning of year medical deductables and stuff. Ugh.

Sal

Edited by Sal, 18 January 2017 - 03:30 AM.

[zipplet]

Is there still interest in debugging the calc-calc protocol?

 

I currently own an fx-5800P (very nice calculator) and this is a popular programmable model in Japan. It is easy for me to obtain a second fx-5800P next month as they are common here and still sold. I need to find a calculator link cable (I don't know where mine has gone), but once I solve that I can tackle this.

 

I currently have access to a 100MHz Rigol DSO, Atmel ICE development hardware for Atmel microcontrollers and USB interface ICs, so it wouldn't be too hard to build something that can interface the calculator to a PC and sniff the traffic.

 

Thoughts?

[EnderFire09]

The fx-5800P uses a ML610901, the same microcontroller used in the original fx-ES and FC-V calculators.
Recently, a lot of progress has been made with hacking the fx-5800P. This includes running custom nX-U8/100 machine code programs by using the OS Transfer feature to flash custom code onto the flash rom. This has been used to dump the contents of the internal mask rom by writing a custom program.
Since the internal mask rom has been dumped, a few WIP fx-5800P emulators have been developed.

Most of the progress has been made in the discord server:
http://discord.gg/QjGpH6rSQQ